Closed morganbr closed 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
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 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
😞
@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.
@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?
ijwhost should be along side the C++/CLI assembly
@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!
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.