C++/CLI net core doesnt work if calling via pinvoke nor via direct c++ call

[jmecosta]

Description

Hi,

Im migrating some c++cli to .net core, and we are faced with a crash when pinvoke from managed side or calling the function directly from a native side.

From manage side we could make it work by force load the c++cli dll with Assembly.Load, however in the c++ i dont have a workound... Another interesting workaround is to call a managed assembly from the c++c/li, in that case pinvoke also works.

Ive attached a sample example, where both exe native and manage fail in same way, and some comments to make the managed side work.

Example.zip

Thank you

Reproduction Steps

build and run the example

Expected behavior

no crash

Actual behavior

crash

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

https://github.com/dotnet/runtime/blob/main/docs/design/features/IJW-activation.md#ijw-executables

It looks like this step is failing:

Using the existing hostfxr library, attempt to discover the desired CLR and target framework.

If a CLR is active with the process, the requested CLR version will be validated against that CLR. If version satisfiability fails, activation will fail.

What's about your deployment model, and the runtimeconfig/hostfxr existance?

[elinor-fung]

@jmecosta I see your project explicitly links against MSCOREE.lib. That's going to result in some weird state of targeting non-Framework, but linking for .NET Framework, which means it is loading .NET Framework at runtime.

I switched your example to ijwhost.lib instead (which is what .NET Core/5+ uses) and it started working. This is normally added as a default lib, but since you have IgnoreAllDefaultLibraries=true, you'll need to explicitly specify ijwhost.lib.

[jmecosta]

ah thats interesting, that must be the reason. i did check that the ijwhost.dll was there so i was assuming this would be the only requirement to ensure the thing works and .net core runtime would be loaded.

i think the main quesiton problably here is that maybe the compiler should break if you try to use MSCOREE.lib ad target .net core. this probably could be already caught at compile time.

IgnoreAllDefaultLibraries has been there for ages in our build system, likely needed because of upgrades from different compilers and so on.

I will confirm if in our main product thank you

[jmecosta]

how did you make it work again?

[huoyaoyuan]

I believe the mscoree.lib should be removed? It's a .NET Framework-only component.

[jmecosta]

so, yeah that fixes the c++ one. but the c# one it needs
Assembly.Load("MsgLibCLI");

but maybe this is expected and some we need to always.

it would be really great if this validation would happen already at compile time

[elinor-fung]

i think the main quesiton problably here is that maybe the compiler should break if you try to use MSCOREE.lib ad target .net core. this probably could be already caught at compile time.

@tgani-msft Thoughts on this validation for building a C++/CLI library?

but the c# one it needs
Assembly.Load("MsgLibCLI");

For the C# application, the issue is that the .runtimeconfig.json missing in the app's output. If running under a debugger in VS, there should be a message in the debug output along the lines of The specified runtimeconfig.json [<path>\MsgLibCLI.runtimeconfig.json] does not exist. The project reference from a C# project to the C++/CLI project only copies the library, not the config file.

In .NET 8 and below, even if the runtime was already loaded, if the initial load of a C++/CLI library is as a native library (the p/invoke) rather than as a managed assembly (Assembly.Load), it still required a .runtimeconfig.json. This was relaxed in .NET 9 with #92037, such that the config file is no longer needed if the runtime is already loaded.

[jmecosta]

Ah nice I will try .net 9. Thanks for the clarification

…

On Thu, May 15, 2025, 20:27 Elinor Fung ***@***.***> wrote: *elinor-fung* left a comment (dotnet/runtime#114965) <#114965 (comment)> i think the main quesiton problably here is that maybe the compiler should break if you try to use MSCOREE.lib ad target .net core. this probably could be already caught at compile time. @tgani-msft <https://github.com/tgani-msft> Thoughts on this validation for building a C++/CLI library? but the c# one it needs Assembly.Load("MsgLibCLI"); For the C# application, the issue is that the .runtimeconfig.json missing in the app's output. If running under a debugger in VS, there should be a message in the debug output along the lines of The specified runtimeconfig.json [<path>\MsgLibCLI.runtimeconfig.json] does not exist. The project reference from a C# project to the C++/CLI project only copies the library, not the config file. In .NET 8 and below, even if the runtime was already loaded, if the initial load of a C++/CLI library is as a native library (the p/invoke) rather than as a managed assembly (Assembly.Load), it still required a .runtimeconfig.json. This was relaxed in .NET 9 with #92037 <#92037>, such that the config file is no longer needed if the runtime is already loaded. — Reply to this email directly, view it on GitHub <#114965 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6HSB726QTYXL3HNGLIDL26TFBJAVCNFSM6AAAAAB3W24DI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBUGU3DINRTGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jmecosta]

and confirmed, works as expected with and without runtime.config in .net 9. thanks again