Fix various "Type or namespace not found" errors

[wtgodbe]

Fixes #20687

So, this works for me locally, but I'm not 100% sure why.

Here's my understanding of what's happening: For non-packable projects that are in the shared framework, when they are at the end of a chain of projectReferences from a (test?) project, their References which SHOULD get converted to PackageReferences by our build system, don't wind up getting passed as references to the compiler. Note that the same projects build fine when they are being built directly during build.cmd.

This only repros so far on machines running VS16.5.0 or VS16.5.1, which made me think it was related to #19133, since VS16.5.0 and 16.5.1 both have the 3.1.200 SDK, which has the 3.1.2 runtime, which has the bug - but that may be a red herring, as the symptoms don't actually line up (the 3.1.2 bug affected only projects with indirect references to certain CoreFx types - the current bug affects every packageReference in the affected projects). Below are examples of projects that had the failure:

FormPipeReader.cs(9,17): error CS0234: The type or namespace name 'Pipelines' does not exist in the namespace 'System.IO' (are you missing an assembly reference?) [F:\workspace_work\1\s\src\Http\WebUtilities\src\Microsoft.AspNetCore.WebUtilities.csproj]

IIS.NewHandler.FunctionalTests references InProcessWebSite references Microsoft.AspNetCore.ResponseCompression References Microsoft.AspNetCore.WebUtilities, which fails to build. The binlog tells me nothing about the PackageReferences here, but confirms that System.IO.Pipelines.dll doesn't get passed as a reference to the compiler

SendFileResponseExtensions.cs(25,70): error CS0246: The type or namespace name 'IFileInfo' could not be found (are you missing a using directive or an assembly reference?) [F:\workspace_work\1\s\src\Http\Http.Extensions\src\Microsoft.AspNetCore.Http.Extensions.csproj]

IIS.NewHandler.FunctionalTests references InProcessWebSite references Microsoft.AspNetCore.Hosting references Microsoft.AspNetCore.Http.Extensions, which fails to build. Here, the binlog tells me that Microsoft.Extensions.FileProviders.Abstractions version 3.1.4 was resolved as a PackageReference, but the .dll wasn't passed to the compiler.

I haven't been able to repro this locally from the command line with either dotnet build or dotnet msbuild - only with build.cmd from the root.

So, the solution I have here is to just manually convert all of the affected References to PackageReferences. There are still some warnings that I'm investigating, and I'm still in process of confirming all of the references & assemblyVersions look good in ILSpy, but so far it looks to be working. We definitely need to figure out exactly what caused this though, and revert this change in favor of a better one once we do - but this should at least unblock 3.1.4 if we can't solve that by Tuesday. This shouldn't get merged into master.

Some more notes:

• I don't know if I needed to do this for every "affected" reference in every "affected" file - after a few iterations of peeling the onion, I noticed the pattern that these were the class of References that needed to be fixed up, so I just converted all of the matching ones wholesale.

[dougbu]

I'm still in process of confirming all of the references & assemblyVersions look good in ILSpy, but so far it looks to be working

It's likely working better than before because ResolveCustomReferences wasn't run enough; see #20760. And, it shouldn't introduce new problems with assembly versioning (especially building against ref/ assemblies from Extensions) because that part of the logic (the AddReferencePackageMetadata target) updates @(ReferencePath) items fairly far downstream of the @(Reference) to @(PackageReference) and @(ProjectReference) conversions.

[dougbu]

That said, something must be changing or ref/Microsoft.AspNetCore.Antiforgery/ wouldn't need to be regenerated. This is probably because ReferenceAssembly.targets copies over @(Reference) items but not @(PackageReference) or @(ProjectReference) items. As things stand in this PR, regenerated ref/ projects are unlikely to compile.

[wtgodbe]

This is probably because ReferenceAssembly.targets copies over @(Reference) items but not @(PackageReference) or @(ProjectReference) items. As things stand in this PR, regenerated ref/ projects are unlikely to compile.

Yeah, that's why. Re-genning strips out the PackageReferences from the ref project files. Will look into changing that now.

[wtgodbe]

Even more motivation to get a better fix than this - the re-gen'd ref projects have hard-coded PackageReference versions, which isn't ideal

[wtgodbe]

This is getting unwieldy/ugly with generated PackageRefs - some projects declare additional metadata on PackageRefs (e.g. PrivateAssets, etc.) which break the build if not re-gen'd into the ref assembly, and even in the current state code gen is still failing. I'm going to reset to before I re-gen'd the ref assemblies, where only codeCheck was failing, and suggest we merge the PR there if we can't get the other one in today - CodeCheck is off in internal builds, so it won't block us while we work on @dougbu's PR. Any objections @dougbu?