Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Ubuntu – How can types be both equal and not equal in C#? (.NET 8.0, Linux, custom .NET Host)

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.

enter image description here

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

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.)

Tags:

2

Answers


  1. 0

    You almost discovered what’s going on (double-loaded assemblies), but I can explain it conceptually.

    I’ll answer exactly to your question

    How can types be both equal and not equal…?

    Look at my comment: System.Type.FullName cannot be a type’s identity; it was never designed for this purpose. It is nothing but a fully qualified name. However, different types can have the same namespace and the same name. The types are different, not the same. To see it, consider this example:

    Assembly 1:

    namespace NameMatch {
    public class Demo { }
    public class AssemblyIndicator1 { }
}

    Assembly 2:

    namespace NameMatch {
    public class Demo { }
    public class AssemblyIndicator2 { }
}

    Now, create another assembly and reference both Assembly1 and Assembly2. It is possible. You can even use two seemingly identical but different types NameMatch.Demo, but not directly:

    var demo = new NameMatch.Demo();
// compilation fails:
// The type 'Demo' exists in both 'Assembly1,
// Version=2.1.0.0,
// Culture=neutral, PublicKeyToken=null'
// and 'Assembly2, Version=2.1.0.0, Culture=neutral, 
// PublicKeyToken=null'...

    Here is how you can retrieve the types in an assembly referencing both assemblies using reflection:

     System.Reflection.Assembly assembly1 = 
     typeof(NameMatch.AssemblyIndicator1).Assembly;
 System.Reflection.Assembly assembly2 = 
     typeof(NameMatch.AssemblyIndicator2).Assembly;

 // This is just a demo, not a practically useful technique!

 System.Type Type1 = assembly1.GetType("NameMatch.Demo");
 System.Type Type2 = assembly2.GetType("NameMatch.Demo");

    Obviously, bool theSame = Type1 == Type2 gives you false while Type1.FullName and Type2.FullName both return "NameMatch.Demo".

    You can even instantiate Type1 and Type2 using reflection. But the types are different.
    You don’t need a comparison like stopAtType.FullName == type.FullName — it does not make sense and tells you nothing about type identities.

    Login or Signup to reply.
  2. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search