Support mixed-mode assemblies on Windows

[morganbr]

This issue will track progress toward supporting loading and running mixed-mode assemblies on CoreCLR. The main goal is to provide support for WPF and other existing C++/CLI code on .NET Core. Some of the work will be dependent on updates to the MSVC compiler.

Steps include:

• Documenting how mixed-mode assemblies work in general
• Proposing a .NET Core design
• Loading mixed-mode assemblies into running managed code
• Starting the runtime from native code in mixed-mode assemblies

This is related to #4116, but cross-platform support is outside of the scope of this issue as it's a compiler feature, not a runtime feature.

[rickbrew]

Paint.NET author here ... you've got my attention :D I have 50 KLOCs of C++/CLI code ... let me know if you need a guinea pig :)

[morganbr]

Thanks, @rickbrew. It'll be a while until we're ready for Paint.NET, but we'll keep you in mind.

[mjsabby]

I think we can start by reverting dotnet/coreclr@1aa7d6b to at least allow the ability to load multi module assemblies.

[morganbr]

@mjsabby, multi-module assemblies are orthogonal to mixed-mode. (Multi-module means you linked together netmodules using alink.exe, mixed mode means you have a combination of managed and native code in the same assembly). If you have a requirement for multi-module assemblies, I'd suggest filing a separate issue outlining what you need.

[mjsabby]

@morganbr Thanks. I'm not sure why I concluded that C++/CLI needs netmodule support.

[pongba]

Awesome we're making progress on this ground. C++/CLI is what we use to bridge native service to the awesome .NET world. So far no other alternative achieves the elegance of C++/CLI as a glue language so it's fair to say that we're going to rely on C++/CLI as an integral part of our service.

Some time ago in the spirit of searching for performance gains by migrating from .NET framework to .NET core I sadly found that .NETCore doesn't go together with C++/CLI (even though we don't care about cross-platform yet).

And now this thread lifts my mood 👍 Looking forward to the release (as while I searched for solutions I saw a lot of people had the same need with C++/CLI in their own projects)

[nietras]

@morganbr given that "Loading mixed-mode assemblies into running managed code" is done, should it be possible to use latest .NET Core 3.0 preview together with mixed mode assemblies on Windows? E.g. from a C# application?

We intent to use .NET Core 3.0 with WPF and have quite a lot of C++/CLI dependencies/libraries (a lot third party too), so looking forward to this.

[morganbr]

@nietras, I'm glad to hear you're eager to give this a shot. It's probably a little early to try it with the latest preview though. While the runtime can run mixed-mode assemblies now, the C++ compiler also needs some changes to make everything work smoothly.

In case anyone's interested in details, the main C++ compiler changes are:

1. Be able to build against .NET Core assemblies instead of .NET Framework (this isn't strictly blocking, but can cause issues if the assembly references a type that isn't in Core or wants to use a type that isn't' in Framework)
2. An assembly built with the current release of the C++ compiler will load and call into mscoree.dll on startup, which starts up .NET Framework. As you might imagine, having both runtimes think they loaded the assembly can cause lots of problems.

[pongba]

@morganbr will the changes to C++(CLI) compiler that supports .NETCore be released together with the next version of Visual Studio, or will it be released out-of-band?

[morganbr]

@pongba, I don't think we're ready to say exactly when or how we'll first distribute that version of the compiler, but it will eventually get distributed with Visual Studio.

[batzen]

So should it be possible to load assemblies which have ddlexports (vtfixup etc.) in them with the current preview of .net core 3.0? I am asking this because i just get a BadImageFormat exception when trying to load such assembly which i compiled with .net core 3.0 and used ildasm and ilasm to add the exports. The same code works when compiling with .net 4.6.2. I can provide the il code if required as a repro.

[Berrysoft]

Considering of C++/WinRT, is it possible to write a standard C++ projection for .NET Core?

[batzen]

@morganbr Would be nice to get a response from you. Not being able to at least load assemblies which contain an dll export prevents me from porting https://github.com/cplotts/snoopwpf to .NET core 3.0.

[morganbr]

@batzen, you could be hitting a few different issues. You might be able to narrow them a bit by seeing if directly calling LoadLibrary on your assembly in the .NET Core process works. Some possible issues:

1. Processor architecture mismatch (in particular, .NET Core is x64 by default while .NET Framework is x86 by default)
2. Depending on how exactly your imports/exports are set up, your assembly might be causing mscoree.dll to load. If that happens, it tries to start .NET Framework and all kinds of bad things (including BadImageFormat) can happen. You should be able to spot mscoree.dll loading in a debugger if you have mixed-mode debugging enabled.
3. Something specific to your ildasm/ilasm process. You'd need to debug further into the error to find out if there's something .NET Framework-specific that you're relying on.