Investigate public API changes in templates

[ilonatommy]

Investigating #62851

[ilonatommy]

Findings so far:

• There is a dotnet pack instruction that does not make sense and was added when the script was not running on CI. We could remove it, as packing is supposed to be done by ./eng/build.cmd -all -noBuildJava -pack -c Release command. It's not related to the issue but it's producing a not necessary error:

MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.

• Another not related issue is Test-Template: The property 'Length' cannot be found on this object. Verify that the property exists. on local runs. It's a PowerShell array handling problem that happened intermittently. In PowerShell, Get-ChildItem returns different object types depending on how many items it finds. If it finds 2+ items, it's working fine because it returns array/collection that has Length. If the template created exactly one csproj, then it returns FileInfo that does not have array length.
• Patching is done correctly in the sense that the elements that we extract from the zip really land in the package directory that we expect to be used to run the tests. The copy operation resulted in both: -preview.7.25322.101 and -dev packages to be present in that dir but even if we clean the dir from all the non-dev versions of packages, we still observe the issue.
• Added uploading pack from artifacts/Shipping into azdo artifacts (we are using this pack for what is called "patching" - replacing existing ASP.NET Core packs with the ones that were produced in the process of packing - see the dot above). After decompiling Microsoft.AspDotNet.Diagnostics.dll we can see that it contains the proper version of the API:

    public static IApplicationBuilder UseStatusCodePagesWithReExecute(
      this IApplicationBuilder app,
      string pathFormat,
      string? queryFormat = null,
      bool createScopeForStatusCodePages = false)

There is no visible reason for the error. Along with that "patching" zip, I decompiled the packs before and after the "patching". They all have the same, correct parameter name in UseStatusCodePagesWithReExecute.

• Running the publish command with binlog and uploading it to artifacts. Checking ResolveAssemblyReference, we see that Microsoft.AspNetCore.Diagnostics.dll is referenced in location D:\a\_work\1\s\src\ProjectTemplates\scripts\.dotnet\packs\Microsoft.AspNetCore.App.Ref\10.0.0-preview.7.25322.101\ref\net10.0\Microsoft.AspNetCore.Diagnostics.dll, not in D:\a\_work\1\s\src\ProjectTemplates\scripts\.dotnet\shared/Microsoft.AspNetCore.App/10.0.0-dev/Microsoft.AspNetCore.Diagnostics.dll where we are "patching" it to. This might be the fix, trying to change the patch logic to replace packages in packs instead of shared. No Microsoft.AspNetCore.* assemblies from shared dir are referenced.
  edit: That's not the fix. Trying to remove existing packs before patching and re-try.

[ilonatommy]

The error is now not in the log, even though a parallel change in #63005 did have it.