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

admin管理员组

文章数量:1026989

• 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:

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:
• 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:

Gist with the runtime config used:

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

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

• c#
• .net
• linux

Share Improve this question Follow edited Dec 5, 2024 at 15:55 fviktor asked Dec 5, 2024 at 0:05 fviktorfviktor 2,9582121 silver badges2525 bronze badges 19

• 1 Hi. Please see how to ask and how to create an MRE. In particular, paste code that reproduces the problem. In isolation, pictures of code are not very helpful. – Matt Johnson-Pint Commented Dec 5, 2024 at 0:16
• 2 ... though as a wild guess without being able to fully repro your issue, I'd try type.Equals(stopAtType) on line 49. See stackoverflow.com/questions/814878/… – Matt Johnson-Pint Commented Dec 5, 2024 at 0:17
• System.Type overloads the equality and inequality operators. Maybe that's what you are seeing? If you could share a minimal reproducible example as code rather than a screen shot I could be sure. – dbc Commented Dec 5, 2024 at 0:25
• I've tried type.Equals(stopAtType) in the code and it gives the same result (false) as type == stopAtType. I've tried to add type.Equals(stopAtType) in the debugger as a watch and it produces the same contradictory true there. – fviktor Commented Dec 5, 2024 at 0:25
• 1 Confirmed that the affected assembly is double loaded into the same application domain somehow. – fviktor Commented Dec 5, 2024 at 1:00

 |  Show 14 more comments

2 Answers 2

Sorted by: Reset to default 0

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.

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.

• 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:

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:
• 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:

Gist with the runtime config used:

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

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

• c#
• .net
• linux

Share Improve this question Follow edited Dec 5, 2024 at 15:55 fviktor asked Dec 5, 2024 at 0:05 fviktorfviktor 2,9582121 silver badges2525 bronze badges 19

• 1 Hi. Please see how to ask and how to create an MRE. In particular, paste code that reproduces the problem. In isolation, pictures of code are not very helpful. – Matt Johnson-Pint Commented Dec 5, 2024 at 0:16
• 2 ... though as a wild guess without being able to fully repro your issue, I'd try type.Equals(stopAtType) on line 49. See stackoverflow.com/questions/814878/… – Matt Johnson-Pint Commented Dec 5, 2024 at 0:17
• System.Type overloads the equality and inequality operators. Maybe that's what you are seeing? If you could share a minimal reproducible example as code rather than a screen shot I could be sure. – dbc Commented Dec 5, 2024 at 0:25
• I've tried type.Equals(stopAtType) in the code and it gives the same result (false) as type == stopAtType. I've tried to add type.Equals(stopAtType) in the debugger as a watch and it produces the same contradictory true there. – fviktor Commented Dec 5, 2024 at 0:25
• 1 Confirmed that the affected assembly is double loaded into the same application domain somehow. – fviktor Commented Dec 5, 2024 at 1:00

 |  Show 14 more comments

2 Answers 2

Sorted by: Reset to default 0

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.

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.

本文标签：