.Net 8.0 fails to resolve method in embedded DLL

[MandiMan]

.NET version

.NET SDK 8.0.100-preview.3.23165.21

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No

Issue description

A .Net8.0 project failing with “System.MissingMethodException: 'Method not found” trying to access a DLL that is included as an embedded resource in a 3rd DLL.

Steps to reproduce

Repro Steps:

1. Unzip and copy the files in Common.zip to VSError.zip
2. Then build and run attached project “VSError”
3. Click "button1" to have a pop-up box pop-up, then click the “OK” of the pop-up box

Actual result:
project failing with “System.MissingMethodException: 'Method not found” trying to access a DLL

Expected result:
Run successfully without error shows.

More info:

1. Feedback source:https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1775813
2. This issue does not repro on .NET Framework.
3. This issue repro in .NET 8.0, .NET 7.0, .NET 6.0.
4. “WinFormsApp1” is the .Net 6.0 project that has the issue (2nd MessageBox fails).
   “WindowsFormApp1” is the .Net Framework 4.7.2 program that works correctly.
   “ClassLibrary1” is the DLL with the embedded MySqlConnector that works in both programs
   “ClassLibrary2” is the DLL which inherits from Class1 and fails in .Net 6.0 (but works in Framwork 4.7.2)

[merriemcgaw]

@JeremyKuhne will take a look at what they're doing and see if we can find the root cause to help them.

[JeremyKuhne]

This is an issue better addressed by the runtime.

In Library1 they're embedding (as a resource) the .NET Standard 2.0 version of MySqlConnector, then using Assembly.Load on the resource stream when the assembly comes up via AppDomain.CurrentDomain.AssemblyResove.

Library2 does no special handling of AssemblyResolve, but calls the same MySqlConnector code.

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

.NET version

.NET SDK 8.0.100-preview.3.23165.21

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No

Issue description

A .Net8.0 project failing with “System.MissingMethodException: 'Method not found” trying to access a DLL that is included as an embedded resource in a 3rd DLL.

Steps to reproduce

Repro Steps:

1. Unzip and copy the files in Common.zip to VSError.zip
2. Then build and run attached project “VSError”
3. Click "button1" to have a pop-up box pop-up, then click the “OK” of the pop-up box

Actual result:
project failing with “System.MissingMethodException: 'Method not found” trying to access a DLL

Expected result:
Run successfully without error shows.

More info:

1. Feedback source:https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1775813
2. This issue does not repro on .NET Framework.
3. This issue repro in .NET 8.0, .NET 7.0, .NET 6.0.
4. “WinFormsApp1” is the .Net 6.0 project that has the issue (2nd MessageBox fails).
   “WindowsFormApp1” is the .Net Framework 4.7.2 program that works correctly.
   “ClassLibrary1” is the DLL with the embedded MySqlConnector that works in both programs
   “ClassLibrary2” is the DLL which inherits from Class1 and fails in .Net 6.0 (but works in Framwork 4.7.2)

Author:	MandiMan
Assignees:	-
Labels:	area-AssemblyLoader-coreclr, untriaged
Milestone:	-

[vitek-karas]

The reason for this behavior difference is how AssemblyLoadContext (ALC) and assembly resolution works in .NET 6.

The implementation of Assembly.Load(byte[], ...) will create a new ALC every time it's called (it doesn't compare that the bytes passed to it are exactly the same as on previous calls) and thus will end up loading the assembly every time creating effectively duplicates in the runtime.

The assembly resolution invoked by direct calls to types/methods from the MySqlConnector assemblies are invoked on the Default ALC (since all of the code in the Main and ClassLibrary* runs in Default).
Every time such resolution happens the immediate lookup on Default will fail, because there's no MySqlConnector assembly loaded into the Default ALC. Eventually the AppDomain even handler will be invoked which will call Assembly.Load(byte[], ...) which will load a new copy of the assembly and return it.

The resolution is invoked twice, once from the code in ClassLibrary1 and then again for code in ClassLibrary2, each will get its own copy of the MySqlConnector assembly. When the code in ClassLibrary2 is invoked, it will end up with copy 2 of MySqlConnector, but the method on ClassLibrary1 it calls uses copy 1 - so they don't match, and it effectively can't resolve the method call.

So the main difference which causes this is:

• On .NET Frameowrk Assembly.Load(byte[], ...) loads into the "default context" (although there's no real ALC in .NET Framework, but the assembly is loaded into the effective "default" scope and thus subsequent attempts to resolve it will hit the cache and won't try to load it again). So in this case the event handler is actually only called once for MySqlConnector.
• On .NET 6 `Assembly.Load(byte[], ...) loads into a new separate ALC and even if the resolution event originates in default ALC, the result of such lookup is not cached there. So subsequent attempts to resolve the assembly (like resolving another assembly reference from another assembly) in default ALC will end up calling the event handler repeatedly. And due to this behavior the handle will load multiple copies of the assembly, eventually leading to type identity mismatches.

As far as I can tell there's no way to write this code once for both .NET Framework and .NET 6. In this case the better API to call on .NET 6 is AssemblyLoadContext.Default.LoadFromStream which will load into the default ALC, and thus subsequent resolution attempts will be done from the cache - the event handler will only be invoked once.

So the code in Class1.cs can look something like:

                if (stream != null) {
#if NETCOREAPP
                    return System.Runtime.Loader.AssemblyLoadContext.Default.LoadFromStream(stream);
#else
                    byte[] assemblyData = new byte[stream.Length];
                    stream.Read(assemblyData, 0, assemblyData.Length);
                    return Assembly.Load(assemblyData);
#endif
                }

I tested that version in both .NET 6 and .NET Framework and it works.

[vitek-karas]

@elinor-fung what do you think about potential improvements to avoid this confusion in the future?

We have basically two competing requirements, in .NET Framework Assembly.Load(byte[], ...) behaves like:

• It loads a new copy of the assembly every time
• It loads the assembly into the "default" load context scope every time (because .NET Framework allows loading multiple versions of the same assembly into the same context).

In .NET 6 we can't do both at the same time, because .NET 6 doesn't allow loading multiple versions of the same assembly into the same ALC. So apparently the current implementation chose to implement the first behavior (loading new copy every time) while sacrificing the second.

I don't see us changing the behavior to favor the second over the first (breaking change). So I guess we can only improve the docs in this case.

[jkotas]

It loads the assembly into the "default" load context scope every time (because .NET Framework allows loading multiple versions of the same assembly into the same context).

Nit: In .NET Framework, Assembly.Load(byte[], ...) typically (but not always) loads the assembly into "Neither" context that is not the same as the default context.