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.

shmuelie commented 4 years ago

this basically ties us to a dead platform in the form of .NET Framework 4.8 and we are left (again) with stagnant technology

Stagnant fine but dead?

".NET Framework 4.8 will be the last major version of .NET Framework. If you have existing .NET Framework applications that you are maintaining, there is no need to move these applications to .NET Core. We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes. It will continue to ship with Windows (much of Windows depends on .NET Framework) and we will continue to improve the tooling support for .NET in Visual Studio (Visual Studio is written on .NET Framework). " - .NET Core is the Future of .NET

weltkante commented 4 years ago

Any ideas what could be the problem?

@cocowalla Mismatch between 32/64 bit? Are you sure you are running the .NET Core application in the same bitness as the C++/CLI library was compiled?

cocowalla commented 4 years ago

@cocowalla Mismatch between 32/64 bit? Are you sure you are running the .NET Core application in the same bitness as the C++/CLI library was compiled?

Nope, as I mentioned, both the managed assembly and test app target X64. I even confirmed with dumpbin /headers 😞

jeffschwMSFT commented 4 years ago

@cocowalla for new issues it likely makes sense to open new issues. In this case can you ensure that ijwhost.dll is present? For .NET Core to successfully activate C++/CLI this component is necessary. We are aware that the error message is not helpful, and are looking to improve that experience. By default if you build with VS 16.4+ with a C++/CLI project this file is added automatically.

cocowalla commented 4 years ago

@jeffschwMSFT fair point, will open a new issue. Regarding ijwhost.dll tho, is this meant to be in the same dir as the app running the managed C++/CLI assembly?

jeffschwMSFT commented 4 years ago

ijwhost should be along side the C++/CLI assembly

cocowalla commented 4 years ago

@jeffschwMSFT brilliant, thanks!

The ijwhost.dll was indeed missing - it was output by the C++/CLI project, but wasn't in the output of the test app. Now it's there, it seems to work!