Fix loading of NuGet.Frameworks.dll on .NET Framework. (#6301)
Fix loading of NuGet.Frameworks.dll on .NET Framework. (#6301)

Fixes #6289

Context
#6126 changes the way that NuGet.Frameworks.dll is loaded to be used by NuGetFrameworkWrapper from a call to LoadFile to a call to LoadFrom. The path passed in to the Load*` call is the same in both cases, but the behavior is different when running on .NET Framework.

On .NET Framework, calling LoadFile results in IJW loading rules being followed, and a different copy of NuGet.Frameworks.dll
than the one requested being loaded. It also appears to match the one loaded into the LOAD context. Calling LoadFrom results in the specified assembly being loaded, but it doesn't match the copy of the assembly loaded into the LOAD context. Thus, it remains in the LOADFROM context instead of being promoted to the LOAD context.

Later on, there is a collision between code from the two instances of NuGet.Frameworks.dll that are loaded into the LOAD context and the LOADFROM context, and this is where the MissingMethodException is thrown.

Note, this does not happen on the .NET Core bootstrap build because the loader behavior is significantly simpler.

Changes Made
Choose the Load* API based on the target framework at build time. On .NET Core, use LoadFrom and on .NET Framework, use LoadFile. This type of precedent already exists in MSBuild where there is different load behavior for .NET Framework and .NET Core.
AndyGerlicher/msbuild,mono/msbuild,sean-gilliam/msbuild,mono/msbuild,sean-gilliam/msbuild,sean-gilliam/msbuild,AndyGerlicher/msbuild,AndyGerlicher/msbuild,mono/msbuild,sean-gilliam/msbuild,rainersigwald/msbuild,AndyGerlicher/msbuild,rainersigwald/msbuild,mono/msbuild,rainersigwald/msbuild,rainersigwald/msbuild