- OS: Ubuntu 24.04 Linux
- Framework: .NET 8.0.10
- IDE: Rider (latest)
I’m creating a custom .NET Host from a native Linux project to run the managed code.
Problem is that I get a logical contradiction on comparing types in about 50% of the cases. The issue is 100% reproducible and happens only on Linux and with the custom .NET Host used.
It also affects the execution of the GetCustomAttributes method, which cannot find the attributes in such cases. Debugging led me to the situation visible on the screenshot, where types do not match, but when I compare them in the debugger (see the watch variable) they do match.
The exact same code works well (can match all types) if I run the managed code directly as a console executable, without the custom .NET Host.
I followed Microsoft’s instructions to write a custom .NET Host:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting
Aside of the above issue the .NET Host works well, can load all assemblies and all other code appears to run well.
- It is not a debugger issue, since the issue affects GetCustomAttributes (a standard library method) as well.
- I’ve checked all projects and dependencies, they are good. Nullable is turned OFF on all projects and C# 11 is selected. I have only Library projects.
- The IL code generated looks what one would expect.
- UPDATE: It turned out to be false: No assembly is loaded twice.
What do I miss here? Misconfigured .NET Host? Having the Typo object loaded twice somehow? CLR or JIT bug?
Updates:
-
I’ve checked the assembly location on both type objects, they are the exact same.
-
This is a hint that the types indeed differ:
type.GetHashCode() = {int} 18014707
stopAtType.GetHashCode() = {int} 59387592
- Related: https://github.com/dotnet/runtime/issues/39783
- Confirmed that the affected assembly is double loaded (Rider’s Debug Output pane):
Loaded Assembly '/home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll'
Loading module /home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll in application domain 1:clr_libhost
Symbols for module /home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll loaded
...
Loaded Assembly '/home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll'
Loading module /home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll in application domain 1:clr_libhost
Symbols for module /home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/Sandbox.Game.dll loaded
Printed the AssemblyLoadContext instances at the top of Main:
foreach (var assemblyLoadContext in AssemblyLoadContext.All)
{
Console.WriteLine($"AssemblyLoadContext: {assemblyLoadContext.Name}");
}
Console.WriteLine($"AssemblyLoadContext.Default: {AssemblyLoadContext.Default.Name}");
Running directly (without the custom .NET Host):
AssemblyLoadContext: Default
AssemblyLoadContext.Default: Default
Running via the custom .NET Host:
AssemblyLoadContext: IsolatedComponentLoadContext(/home/viktor/se-dotnet-server-local/SpaceEngineersDedicated/bin/Debug/net8.0/SpaceEngineersDedicated.dll)
AssemblyLoadContext: Default
AssemblyLoadContext.Default: Default
It should explain the problem.
Code
Gist with the relevant .NET Host C++ code: https://gist.github.com/viktor-ferenczi/feff098dfe27bba0f03929a89e2994a4
Gist with the runtime config used: https://gist.github.com/viktor-ferenczi/9ba57aa40510ccd928e80570ddd54983
The RunManagedCode function is called with appropriate values. The managed code starts, so the strings passed are good.
(The rest of the project is a big mess now and very complex to compile, so it is not public, but will eventually be, should I succeed.)
19
The solution was to use the hostfxr_initialize_for_dotnet_command_line initialization method to create the .NET Host in the native Linux process.
The right code is in the documentation:
https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md#running-app-with-additional-runtime-properties
Verified that we have only a single AssemblyLoadContext and that’s the Default one. Also verified that all type comparisons work as expected.
2
It appears this is a known limitation of using a native host in .NET Core, in that any DLL called directly from native code will be loaded into an isolated AssemblyContext.
See this GitHub issue for a similar problem. It’s not clear there what the workaround should be, but it seems one option would be to create a separate DLL to bootstrap the rest of the application from. So that DLL would be loaded into the isolated context, but everything else would be loaded into the default context.
You have also found some docs (more of a design proposal than a guide) that imply it’s possible to load directly into the default context. It’s not made clear in that doc how to do so though.
1