AssemblyLoadContext incorrectly validates name of dynamic assembly when returned from Load

[vitek-karas]

AssemblyLoadContext validates that the assembly returned from Load has the same name as the name which was asked for. This validation incorrectly handles dynamic assemblies and will always fail for them.

This is the cause because ValidateAssemblyNameWithSimpleName simply casts the returned assembly to RuntimeAssembly:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs

Line 660 in 01c9cf6

RuntimeAssembly? rtLoadedAssembly = assembly as RuntimeAssembly;

But this doesn't work for assemblies created by AssemblyBuilder.

The code should call GetRuntimeAssembly instead, which handles this case correctly.

Full repro for both affected public APIs (Load and Resolving) is here:
https://gist.github.com/vitek-karas/3c8f938dc15730ad00a375d8d745f36a

This is basically a derivative issue from the bug fix in #49387.

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

Issue Details

---

AssemblyLoadContext validates that the assembly returned from Load has the same name as the name which was asked for. This validation incorrectly handles dynamic assemblies and will always fail for them.

This is the cause because ValidateAssemblyNameWithSimpleName simply casts the returned assembly to RuntimeAssembly:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs

Line 660 in 01c9cf6

RuntimeAssembly? rtLoadedAssembly = assembly as RuntimeAssembly;

But this doesn't work for assemblies created by AssemblyBuilder.

The code should call GetRuntimeAssembly instead, which handles this case correctly.

Full repro for both affected public APIs (Load and Resolving) is here:
https://gist.github.com/vitek-karas/3c8f938dc15730ad00a375d8d745f36a

This is basically a derivative issue from the bug fix in #49387.

Author:	vitek-karas
Assignees:	-
Labels:	area-AssemblyLoader-coreclr
Milestone:	-

[Ap0k]

@vitek-karas
This error can be easily treated. But in the process of fixing it, I found the following case.

runtime/src/coreclr/vm/appdomain.cpp

Line 5416 in cc8d9b3

// Reflection emitted assemblies will not have a domain assembly.

If I understood everything correctly, then the dynamic assembly is not domain-specific and the code execution goes along the specified branch with the subsequent generation of an exception.

If fixing the definition of ALC for a dynamic assembly is not urgent, then I can investigate the above problem in more detail within the framework of this task. Otherwise, I propose to create a separate ticket for the error in the definition of ALC, merge it, merge the fixes of the tests (#48579) and then tackle the problem of this ticket tightly.

[vitek-karas]

Honestly I was expecting this - that dynamic assemblies will be prevented from actually succeeding in Load. I still think it's worth fixing the name validation logic, mainly because it's inconsistent and fails with really bad error.

The potential support for dynamic assemblies in load resolution is probably a much larger work item (I'm not even sure what are all the potential problems with it for example), so I would definitely track that separately. There's also the question if it's actually worth going after at all.

[Ap0k]

Okay, I fill in both fixes, but without the ValidateAssemblyNameWithSimpleName tests