Loading this assembly would produce a different grant set from other instances

[iskiselev]

Bug Report

Use Asp.NET web appliction without setting LoaderOptimization.SingleDomain results in site error 500 with "Loading this assembly would produce a different grant set from other instances"

Symptom

Describe the bug
Most IIS web-applications for .Net Framework using Otel.AutoInstrumentation are non-functional without applying
LoaderOptimization.SingleDomain through registry settings.

Expected behavior
Web applications should continue to work without registry modifications

Additional context
Origanally reported in #3839, workaround (with registry change) suggested in #3996.

[iskiselev]

First attempts to fix was in #4165, but it was not enough.
Current plan to fix it in stages:

1. Patch appDomainSetup.LoaderOptimization = LoaderOptimization.SingleDomain in AppDomain.CreateDomain and AppDomainManager.CreateDomainHelper.
   Patch functions would be implemented in OpenTelemetry.AutoInstrumentation.Loader (it will help in next phase). For it, move __DDVoidMethodType__ into mscorlib, split OpenTelemetry.AutoInstrumentation initialization call into separate method (loading assembly and resolving reflection in .cctor of __DDVoidMethodType__) and adding method that will call AppDomainSetup modification through delegate resolved with reflection in static ctor.
   On that stage, it would not be required to do registry modification with the cost that all non-default AppDomains would be loaded with LoaderOptimization.SingleDomain.

2. If OpenTelemetry.AutoInstrumentation is loaded from GAC, we have better approach. We will patch app/web.config for new app-domains, configuring assembly references for us and dependencies and codebases. It will allow to not change LoaderOptimization. If assemblies are not in GAC, it will effectively work as SingleDomain even when default IIS mode MultiDomainHostis used (as we are added as dependencies to all assemblies). .Some Net Framework assemblies may still be loaded in neutral app-domain multiple times, assembly redirection in default domain and other domains will be different.
   After step (2), per my tests no issues with both cases: when assemblies are in GAC or just in OTEL folder.

[iskiselev]

If we want to be able load without switching to LoaderOptimization.SingleDomain, we need generate proper assembly bindings.

.Net Framework has list of assemblies which it automatically redirect to some hardcoded version, unless application does not override it by providing binding redirects. With that redirects both older or newer assembly version will be replaced with version provided by .Net Framework. With that mechanics NetStandard support was implemented. I have not found any documentation about it, I suspect all Facade Assemblies would work that way.
List of assemblies can be looked in RedistList/FrameworkList.xml, for example:

• https://nuget.info/packages/Microsoft.NETFramework.ReferenceAssemblies.net472/1.0.3
• https://nuget.info/packages/Microsoft.NETFramework.ReferenceAssemblies.net462/1.0.3 (does ot have Facade assemblies).

So, we can't just generate binding redirects for all assemblies that comes with OTEL AutoIntrumentation, as it will break facade assemblies - our assemblies would be loaded instead of proper version that was provided with .Net Framework.

There are multiple ways to solve it:

• do run-time test. Create fresh app-domain (per assembly) without any bindnig redirects and try to load tested assembly. If version is not much, it is assembly with .Net Framework redirections, no redirections should be created for it
• do install-time test and create some manifest file. Manifest file should be upgrated if customer installs newer .NET Framework
• do multi-targeting build (for net462, net47, net471, net472, probably newer) - assemblies that should be redirected by net framework should not be included in output by build - it may also solve other issues, as netfx assembly System.Net.Http.dll is not redirected to version 4.2.0.0 #2400, Installation breaks OktaVerify.exe due to DLLs being copied to the GAC #3792
• do manual processing of RedistList/FrameworkList.xml for each framework at build time to prepare manifest at compile time and hope we done it correctly despite no documentation. Reference for it would SDK conflict resolution logic: https://github.com/dotnet/sdk/blob/509db15c03be1dd3e3110a4768c5affef3e7a3f4/src/Tasks/Common/ConflictResolution/ResolvePackageFileConflicts.cs

Any of this option still not solve situations when customer application has newer version of assembly than OTEL AutoInstrumentation. It may still result in problems like #3714. We may try to scan all assemblies in bin folder when app domain is created to improve redirection map.