Improve maintainability of dotnet-new.IntegrationTests template package version lists

[MichaelSimons]

Improve maintainability of dotnet-new.IntegrationTests template package version lists

Problem

The dotnet-new.IntegrationTests project requires manual updates every time a new .NET version is added or an old version reaches end-of-life. There are three tightly-coupled locations that must be kept in sync:

1. PackageReference items in the .csproj — each supported version of Microsoft.DotNet.Common.ProjectTemplates and Microsoft.DotNet.Web.ProjectTemplates is listed individually (currently 6.0 through 10.0).
2. Generated TemplatePackagesPaths class — a code-gen block in the .csproj that emits a const string for each package's resolved path, also listed individually.
3. Test code in SharedHomeDirectory.cs and WebProjectsTests.cs — each version is installed/referenced by its specific const, requiring a new block of code per version.

When .NET 11.0 ships, at least 10 lines across these three locations need to be added. When a version goes out of support (e.g., 6.0), lines need to be removed. This is error-prone and easy to forget.

Proposal

Explore using MSBuild wildcards and item-driven code generation to eliminate the per-version enumeration:

• Use wildcard PackageReference patterns (or an MSBuild item group with a version range) so that adding a new version doesn't require editing the .csproj. For example, a single parameterized item group that iterates over a list of supported versions defined in one place (e.g., a property like SupportedTemplateVersions=6.0;7.0;8.0;9.0;10.0).
• Generate TemplatePackagesPaths dynamically from the resolved PackageReference items using an MSBuild target, rather than hardcoding each const.
• Replace per-version install calls in test code (SharedHomeDirectory.cs, WebProjectsTests.cs) with a loop over an array or collection of paths, so adding a version only requires updating the single source-of-truth property/list.

Benefits

• Adding or removing a supported .NET version becomes a single-line change in one location.
• Reduces risk of forgetting to update one of the three coupled locations.
• Prevents test compilation/runtime failures from stale version lists.

Relevant files

• test/dotnet-new.IntegrationTests/dotnet-new.IntegrationTests.csproj (lines 24–57)
• test/dotnet-new.IntegrationTests/SharedHomeDirectory.cs
• test/dotnet-new.IntegrationTests/WebProjectsTests.cs