C++/CLI __declspec(appdomain) static variables cause a C++/CLI binary to fail to load.

[davidwrighton]

Description

If a C++/CLI dll has a global variable that is marked with __declspec(appdomain) the binary will fail to load. It will produce an error like the following:

System.IO.FileLoadException: Assembly is still being loaded. (0x80131016 (MSEE_E_ASSEMBLYLOADINPROGRESS))
   at System.Reflection.RuntimeAssembly.InternalLoad(NativeAssemblyNameParts* pAssemblyNameParts, ObjectHandleOnStack requestingAssembly, StackCrawlMarkHandle stackMark, Boolean throwOnFileNotFound, ObjectHandleOnStack assemblyLoadContext, ObjectHandleOnStack retAssembly)
   at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext, RuntimeAssembly requestingAssembly, Boolean throwOnFileNotFound)
   at System.Reflection.Assembly.Load(String assemblyString)
   at NativeCallingManaged.NativeCallingManaged.TestEntryPoint() in runtime\src\tests\Interop\IJW\NativeCallingManaged\NativeCallingManaged.cs:line 25
   at __GeneratedMainWrapper.Main() in runtime\artifacts\tests\coreclr\obj\windows.x64.Debug\Managed\Interop\IJW\NativeCallingManaged\NativeCallingManaged\XUnitWrapperGenerator\XUnitWrapperGenerator.XUnitWrapperGenerator\SimpleRunner.g.cs:line 7

Reproduction Steps

The bug report was provided privately to the CoreCLR team, and a repro will be provided as part of the fix.

Expected behavior

Assembly should be loadable.

Actual behavior

System.IO.FileLoadException: Assembly is still being loaded. (0x80131016 (MSEE_E_ASSEMBLYLOADINPROGRESS))

Regression?

This is a regression in .NET 9 from .NET 8 related to the work to rebuild how static variables are handled.

Known Workarounds

Remove __declspec(appdomain) from the definition of the global variable. On .NET 9 this has very little semantic effect (it can change initialization order relative to other global variables), causes a minor slowdown when using the variable, and triggers this bug.

Configuration

This only reproduces for C++/CLI binaries as they have a unique startup path which causes the <module> type to be loaded before it would normally be permitted.

Other information

No response

[dotnet-policy-service]

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