search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.22k stars 4.72k forks source link

Support mixed-mode assemblies on Windows #10333

Closed morganbr closed 4 years ago

morganbr commented 6 years ago

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:

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

AaronRobinsonMSFT commented 5 years ago

@GeorgeS2019 The support represented by this issue is related to Windows only. There is presently no plan to support mixed mode on any non-Windows platform. Issues related to non-Windows support is at https://github.com/dotnet/coreclr/issues/659.

C++/CLI compiled on Windows for .NET works on Mono just fine, even on Linux, provided you use /clr:safe

@SwooshyCueb Definitely worth mentioning and requesting that clarity. The various flags that can be provided with the /clr flag make talking about this scenario require an increased level of precision in our communication. As @weltkante mentioned, this issue is specifically for mixed mode which by definition implies both managed and native code within the same assembly.

@jkoritzinsky For .NET Core 3.0, we should specifically call out which arguments to the /clr flag are supported.

GeorgeS2019 commented 5 years ago

@AaronRobinsonMSFT If I understand correctly, one key difference between .NETCore 3.0 and .NET5 is that the support for mixed-mode assemblies for non-windows will happen in .NET 5, unless MS decide to abandon C++/CLI for non-windows.

It is important for the community to know that the mixed-mode assemblies for non-Windows IS CONFIRMED for .NET 5 with an estimated timeline for the preview version.

AaronRobinsonMSFT commented 5 years ago

one key difference between .NETCore 3.0 and .NET5 is that the support for mixed-mode assemblies for non-windows will happen in .NET 5, unless MS decide to abandon C++/CLI for non-windows.

@GeorgeS2019 I don't think that has been implied at all. The official .NET5 plan was announced here and C++/CLI isn't mentioned all, was there another post that mentioned this? At present, there is no plan to support C++/CLI on non-Windows. One of the biggest reasons is compiler support off Windows. We are tracking this request in issue https://github.com/dotnet/coreclr/issues/659 and will update that if official plans change.

MathiasMagnus commented 5 years ago

I'm following this thread because I was/am interested in being able to wrap native code with .Net to be consumed in PowerShell. I think it is far more likely to get a C++/WinRT-ish auxiliary compiler, which is able to generate ISO C++ header files from .Net assemblies, and a matching template library that is able to generate code for consuming native types from .Net code. This approach could be pursued with Clang and GCC as well.

Kenny Kerr was asked about this once, and he said that the ABI of .Net is a lot more trickier than the COM-inspired WinRT is. To be honest, C++/CLI does start to show its age compared to C++17/20, and a helper compiler does seem to make more sense. (With reflection and std::embed on the way, all of the extra machinery could even be done inside an ISO C++ compiler as well, but that's just wishful thinking.)

shmuelie commented 5 years ago

As a rule: Most of what C++/CLI does can be done with just P/Invoke. The biggest that cannot is merging the two assemblies into one.

If you want a tool to help you:

rickbrew commented 5 years ago

@SamuelEnglard Sure but a great thing about C++/CLI is that you can stack the dependencies. I have a C# "base" DLL that my C++/CLI DLL uses, and then more C# DLLs on top of the native one. This allows me to have common primitives (e.g. Point2Int32, RectInt32, whatever) and utility classes shared across the whole system, instead of having to duplicate and mix things around.

shmuelie commented 5 years ago

@rickbrew C++/CLI is great, the key is that what it's doing can be done without it, doing so is just a major pain. As you note you'd have to manually create types in both C++ and C#.

jeffschwMSFT commented 5 years ago

The work necessary to complete this issue is now tracked internally on the Microsoft C++ compiler. I am going to close this issue for now as all known work has been completed in dotnet/coreclr.

jazzdelightsme commented 5 years ago

@jeffschwMSFT : Is there any publicly-trackable issue from the C++ compiler? If not, how will we know when we can / should try this out?

jeffschwMSFT commented 5 years ago

The C++/CLI compiler and project system work is aligning with the Visual Studio 2019 schedule. Adding @tgani-msft to help with timing questions.

jcapellman commented 5 years ago

@jeffschwMSFT thanks! Timing would be great to time a future release.

jeffschwMSFT commented 5 years ago

Our stated goal has been to release along with .NET Core 3 (likely runtime and compiler support). I will chat with @tgani-msft to see if that has changed.

chriss2401 commented 5 years ago

Will C++/CLI code also be compatible with Linux in .NET Core 3 ?

SwooshyCueb commented 5 years ago

@chriss2401 There's a branch of gcc that can do this, I think

chriss2401 commented 5 years ago

@chriss2401 There's a branch of gcc that can do this, I think

Thanks for the reply. So theoretically it should be possible to run on Linux just by adding "netcoreapp30" (when it is released) to the target framework(s) ? Maybe @jeffschwMSFT has an idea about this ?

weltkante commented 5 years ago

@SwooshyCueb you might be mixing up C++/CLI vs. mixed mode assemblies. They are not the same, mixed mode assemblies are a technology while C++/CLI is a language (though currently the only one which can output mixed mode assemblies). While gcc once had an experimental branch for C++/CLI it probably doesn't support mixed mode, which is tightly bound to the runtime it is compiled against.

@chriss2401 no it won't just work, there was no work done to support loading mixed mode assemblies on Linux. (There's not much point to implement a loader if there is no language which can generate code for it. Which means the language and runtime need to be kinda co-developed in order for mixed mode to ever arrive on Linux.)

Support for C++/CLI on Linux is discussed in dotnet/runtime#4116

SwooshyCueb commented 5 years ago

@weltkante My bad, I misread "compatible" as "compilable" in @chriss2401's comment. And I think you're right about the gcc branch not supporting mixed mode.

jgoyvaerts commented 5 years ago

Our stated goal has been to release along with .NET Core 3 (likely runtime and compiler support). I will chat with @tgani-msft to see if that has changed.

@jeffschwMSFT Any update on this?

jcapellman commented 5 years ago

@jeffschwMSFT also still waiting on this feature to complete my porting efforts to .NET Core 3. Any date other than the September release?

AaronRobinsonMSFT commented 5 years ago

@jgoyvaerts @jcapellman Sorry for the delay on the response. An official blog about this issue is in the works and once published with be linked here.

jcapellman commented 5 years ago

Great thanks @AaronRobinsonMSFT!

jgoyvaerts commented 5 years ago

@AaronRobinsonMSFT Any update on this?

jeffschwMSFT commented 5 years ago

Adding @tgani-msft. @AaronRobinsonMSFT and our team have completed the runtime/libraries portion of this work. @tgani-msft and the C++ compiler/tooling team are working through the scheduling details of when they will ship this scenario.

jcapellman commented 5 years ago

@jeffschwMSFT thank you for the update - crossing my fingers it can come next month.

eightcloud83 commented 5 years ago

continue waiting .net core 3.1(/VS16.4) at november 2019

https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-9/

Livar Cunha 2019-09-06 18:50:23

Tadeas Lejsek: Can you please include details about C++/CLI suppo...

That's coming in .NET Core 3.1 and VS 16.4

FYI: releated document updating plan. https://github.com/dotnet/docs/issues/13152

jcapellman commented 5 years ago

@eightcloud83 - Q1 update of my product will have it then. Thanks for posting the response here.

WillBuik commented 5 years ago

I want to share a quick update on this. The latest on the C++/CLI roadmap can be found on our C++ blog here: https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/

.NET Core support for C++/CLI is coming in .NET Core 3.1 which is shipping with Visual Studio 2019 16.4.

jcapellman commented 5 years ago

I want to share a quick update on this. The latest on the C++/CLI roadmap can be found on our C++ blog here: https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/

.NET Core support for C++/CLI is coming in .NET Core 3.1 which is shipping with Visual Studio 2019 16.4.

Awesome news! I have to admit the minute I saw the 16.4 Preview 1 become available I downloaded to recompile my C++/CLI component that has been keeping me in .NET 4.8.

eightcloud83 commented 5 years ago

I cannot find options to create project using C++/CLI with .net Core with 16.4 Preview 1.. Seems need to wait 16.4 Preview 2,3...

Replied @ https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/ Will Buik September 25, 2019 9:57 pm We are still working on the IDE and MSBuild integration, so I can’t share a sample project quite yet. Once it’s available, likely with 16.4 Preview 2 or 3, we will post an update on the blog.

16.4 Preview 2 released.

10/15/2019 https://docs.microsoft.com/en-US/visualstudio/releases/2019/release-notes-preview#16.4.0-pre.2.0

eightcloud83 commented 5 years ago

16.4 Preview 2 released.

10/15/2019 https://docs.microsoft.com/en-US/visualstudio/releases/2019/release-notes-preview#16.4.0-pre.2.0

16.4 Preview.2, I'v tried to new "CLR Class Library (.NetCore)", "c++ library target the .net Core", and new ASP.Net Core 3 project, try to call c++/cli function from asp.net core web, Build succeeds with warning..

Yes!!! It works if platform target set to "x64" when useing iis expess (@x64 windows). ( asp.net core, c++/cli dll, iis express need to be same plateform)

( (VS debug setting can set IIS Express Bitness, default @x64 windows should be 64, so if asp.net core plateform, c++/cli dll set x86 will...) If platform target set to "x86",
" HTTP Error 500.0 - ANCM In-Process Handler Load Failure " )

WillBuik commented 5 years ago

There are a few known issues in the preview. One is that you need to make sure the projects' architectures all match up between the C++/CLI class library and the .NET or ASP.NET Core application that consumes it. So all projects must be Win32/x86 or all x64. Make sure none of the .NET Core projects are set to use "Any CPU" in the Configuration Manager.

For ASP.NET Core there is an additional requirement that they must also match the architecture of IIS Express - which is usually x64. Otherwise the entire website fails to load with "500.0 - ANCM In-Process Handler Load Failure."

We are looking into ways to make this smoother, but hopefully this can work around the issue.

weltkante commented 5 years ago

I want to try this out but I'm getting

1>C:\Program Files\dotnet\sdk\5.0.100-alpha1-014915\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(282,5): error NETSDK1073: The FrameworkReference 'Microsoft.NETCore.App' was not recognized

any way to prevent VS picking up the wrong SDK?

nguerrera commented 5 years ago

That is an issue with the 5.0 SDK builds at this point. They don't support targeting netcoreapp3.1. I suggest uninstalling that and using the 3.1.100-preview SDK that comes with VS.

5.0 is in very early days and the branches are not in great shape right now.

weltkante commented 5 years ago

Hu, there's no way to tell VS which SDK to use? Oh well, thanks for the info. I start seeing a pattern now, there was another issue where I was getting bits from the wrong 3.0 preview when I had the 5.0 SDK installed. Makes me wonder why it bothers installing side-by-side if it doesn't work side-by-side. I hope the experience can be improved in the future, downtimes of several months during releases are annoying. I'll have to live with regular uninstall/reinstall cycles for now I guess (I'm sometimes testing fixes which only go into 5.0 branches)

nguerrera commented 5 years ago

Sorry, you can tell VS to use a specific SDK using global.json.

nguerrera commented 5 years ago

https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

weltkante commented 5 years ago

oh, thanks, I'll try that out then!

eightcloud83 commented 5 years ago

.net core 3.1(/VS16.4) at november 2019

.net core 3.1 has been set to december 2019. (so as VS16.4?) (c++/cli .net core works on .net core 3.1 preview1 and VS16.4 preview2 (or VS16.3 with modifed proj setting ) )

cocowalla commented 4 years ago

Does this mean we can run existing C++/CLI assemblies in .NET Core apps without recompiling them?

jeffschwMSFT commented 4 years ago

Does this mean we can run existing C++/CLI assemblies in .NET Core apps without recompiling them?

Existing C++/CLI assemblies are hardcoded to initialize .NET Framework, as such they need to be recompiled against .NET Core to function properly.

Berrysoft commented 4 years ago

Does this mean we can run existing C++/CLI assemblies in .NET Core apps without recompiling them?

Well, I've tried a few existing C++/CLI assemblies compiled with .NET Framework, and they run successfully even on .NET Core 3.0, but I strongly suggest recompiling them. I think they could run on .NET Core because of the compatible mode of .NET Core, but it doesn't ensure the success.

cocowalla commented 4 years ago

Existing C++/CLI assemblies are hardcoded to initialize .NET Framework, as such they need to be recompiled against .NET Core to function properly.

Ach, that's really disappointing :cry:

We use some 3rd party mixed-mode assemblies which are the only thing tying us to the .NET Framework, and the chance of the vendor recompiling is close to zero.

No chance of some kind of compatibility layer then?

jeffschwMSFT commented 4 years ago

No chance of some kind of compatibility layer then?

API wise they are likely close to compatible. The challenge is around activation. If the assembly believes it needs to activate .NET Framework there is very little we can do.

shmuelie commented 4 years ago

@jeffschwMSFT what if .NET Core is initialized by the caller? Would the mixed assembly just use what's already loaded?

jeffschwMSFT commented 4 years ago

what if .NET Core is initialized by the caller? Would the mixed assembly just use what's already loaded?

The C++/CLI activation rules are complicated. Having .NET Core initialized is not sufficient. The rules can generally be distilled down to - if assembly's dllmain determines that the runtime needs to be activated, it will activate .NET Framework. There is not a reliable way to ensure that.

For testing purposes we have provided a shim for mscoree to intercept these calls, but that is not something that we would recommend as a durable solution.

ericwj commented 4 years ago

Is this only a problem if unmanaged exports are being used, or will DllMain be hit during managed load? In other words if I understand the process correctly will the native import which causes mscoree to load chain back to the native entry point?

Second question if this is a WPF or desktop app will someone start calling the DLL from native code?

My thought is that if C++/CLI is being used for native needs internal to the app and native pinvokeimpl methods are only called from IL then DllMain might never run?

jeffschwMSFT commented 4 years ago

It is a combination of the OS and binary making these decisions. It is likely possible to model these and narrowly avoid the unintended loading of .NET Framework, but I would advise against it. Our recommendation is to rebuild with .NET Core - which avoids all of these issues. You have the right direction on when it is possible for .NET Framework to be loaded (both in dllmain and the first time that p/invokes are executed).

ericwj commented 4 years ago

Well if you don't have source code it'd be worth a try - first check would be to see if there are any native exports beyond what an empty project would create (a staggering lot, I warn you). Also if the time is still that men are made of steel and ships from wood as opposed to the other way around then you could figure out everything with dumpbin /DISASM and ildasm and/or IL Spy.

cocowalla commented 4 years ago

I just tried porting an old managed C++/CLI project, but I'm getting a BadImageFormat exception when I try to use it:

Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'
   at TestApp.Program.Main(String[] args)

Both the managed assembly and test app target X64, and I'm using Visual Studio Preview 16.4.0 Preview 4 with .NET Core 3.1 preview 2. The built assembly looks to be the correct size, and decompilers such as JustCompile or ildasm work with it just fine. I can see it has a TargetFrameworkAttribute set pointing to NETCoreApp,Version=v3.1.

Any ideas what could be the problem?

nietras commented 4 years ago

We use some 3rd party mixed-mode assemblies which are the only thing tying us to the .NET Framework, and the chance of the vendor recompiling is close to zero.

Just wanted to acknowledge that as with @cocowalla we are in the exact same position, we have mixed-mode assemblies from third parties that have no intention of updating to .NET Core, this basically ties us to a dead platform in the form of .NET Framework 4.8 and we are left (again) with stagnant technology. This is a problem. I love .NET Core and all the great things in it, but what use is it if we can't use it in key projects?