An Update on C++/CLI and .NET Core
Will
The first public release of our C++/CLI support for .NET Core 3.1 is now available for public preview! It is included in Visual Studio 2019 update 16.4 Preview 2. We would love it if you could try it out and send us any feedback you have. For more info about what this is and the roadmap going forward, check out my last post on the future of C++/CLI and .NET Core.
To get started make sure you have all the necessary components installed. C++/CLI support for desktop development is an optional component, so you will need to select it on the installer’s right pane:
You will also need the .NET Core cross-platform development workload. It installs everything you need including the .NET Core 3.1 SDK:
Creating a C++/CLI .NET Core Project
First, you will want to create a “CLR Class Library (.NET Core)” or “CLR Empty Project (.NET Code)”. The Class library template includes some additional boiler plate to set up an example class and precompiled header that may make it easier to get started. The empty project is ideal for bringing in existing C++/CLI code. Retargeting existing C++/CLI projects to .NET Core isn’t recommended.
There isn’t currently a template for C++/CLI console or Windows applications that can be used with .NET Core. Instead you must put application entry point outside of the C++/CLI code. In general, we strongly recommend keeping the C++/CLI projects as narrow in scope as possible to handle just the interoperability between .NET Core and other C++ code.
Once you create one of these projects, you can reference it from other .NET Core projects like any other class library – with one important caveat. .NET Core projects are typically architecture agnostic. You see this as the architecture “Any CPU” in the Configuration Manager and “MSIL” in the build logs. This is the default for all .NET Core projects. If you reference any C++/CLI class libraries, you must specify an explicit architecture for the non-C++ projects instead of “Any CPU”.
You can set a project’s architecture by using the Configuration Manager.
If the architectures don’t match, you will see this warning and attempting to load the C++/CLI class library will fail at runtime:
To resolve this, make sure all projects in the solution are using the same architecture of “x86” and “Win32” or “x64”. If you are using ASP.NET Core, there is an additional consideration. Your projects also need to match the architecture of IIS Express. This is typically “x64”. If you see a “500 server error” due to the loader failing, this may be what the problem is.
Send us Feedback
Please try this out. We’d love to hear your feedback to help us prioritize and build the right features. We can be reached via the comments below or email (visualcpp@microsoft.com). You also can always send us general feedback via Developer Community.
![Marian Luparu [MSFT]](/p/aHR0cHM6Ly93ZWIuYXJjaGl2ZS5vcmc/web/20191227184530im_/https://devblogs.microsoft.com/cppblog/wp-content/uploads/sites/9/2019/10/JTP_0213-150x150.jpg){kind=avatar}
23 comments
Isn’t C++/CLI dead? It’s not been a vibrant project recently.
Not quite. It’s used in a LOT of code which are layers between native c++ legacy or high-performance code and, say, C# UI. I look forward to it being supported with .NET Core for exactly this need. If .NET Framework is essentially dead (no new features), our C# could be migrated to .NET Core WPF and still interop via C++/CLI with an existing backend which is a *large* body of C++ code.
A whole lot of applications use them. Thanks for adding support! I have worked on a ~$200M Class II medical device product that has a TON of C++/CLI to access legacy code and it also works great for near real-time applications (until you stumble upon / inject a memory leak and then your life is a misery).
Awesome will try it immediately. This may be a bit orthogonal but does this release make it easier to use .NET nuget packages in a C++/CLI solution? In an ideal world this would mean being able to use PackageReference in the project file.
The main changes in the project file I saw were
<Keyword>ManagedCProj</Keyword> -> <Keyword>NetCoreCProj</Keyword>
<TargetFramework>v4.7</TargetFramework> -> <TargetFramework>netcoreapp3.1</TargetFramework>
<CLRSupport>true</CLRSupport> -> <CLRSupport>NetCore/CLRSupport>
Is that it or are there others I missed?
This is a pretty big deal for me. If I’m going to write in .net core I will want to use nuget references. Is this coming? Is there at least be a reasonable workaround?
I have been trying it to test a project where we have a CLR Class Library project that outputs a dll and calls some functions developed in an unmanaged C++ project (static library) that calls some functions of the CGAL library. I have tested the calls of the CLR Class library (named CGALWrapper) from a new demo Console App C# .Net Core project. Everything goes fine until the code reaches the section where the call to the CLR Class library dll is made where I get
System.BadImageFormatException: ‘Could not load file or assembly ‘CGALWrapper, Version=1.0.7248.23049, Culture=neutral, PublicKeyToken=null An attempt was made to load a program with an incorrect format.’
I am using:
*Microsoft Visual Studio Community 2019 Preview Version 16.4.0 Preview 3.0
For the CLR CLass library project I have created a new CLR Class library (.NET Core) project as commented on this post and also a new .Net Core Console App C# for the project that tests the calls. Only the unmanaged C++ project has not been modified. Everything has been compiled for Debug-x64 (I have removed any other configurations to avoid any possible problems).
What I would like to ask is if the new C++/CLI support for .NET Core 3.1 supports C++/CLI projects that include code from unmanaged C++ projects
Thanks
hey will buik! alles goed/
Does anyone have advise on how to get the code package downloaded on visual studios professional 2017?
Hi Gregory,
AFAIK, support for c++ /CLI is only in VS2019 16.4 (still in preview).
Jean
Is there a particular reason why this couldn’t be cross platform? Without the UI piece it isn’t as critical but if .NET does get a completely cross platform UI I would hate to figure out how to use PInvoke (assume that can be used?) to call a large C++ calculation library.
If we build a simple C++/CLI project (NET Core 3.1) referencing a C# project (Net Standard 2.0/2.1) then we get warnings like:
>source\repos\ClassLibrary8\CLR\CLR.cpp(9,56): warning C4691: ‘System::Object’: type referenced was expected in unreferenced assembly ‘netstandard’, type defined in current translation unit used instead
>source\repos\ClassLibrary8\CLR\CLR.cpp(9,56): message : This diagnostic occurred while importing type ‘ClassLibrary8::Class1 ‘ from assembly ‘ClassLibrary8, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.
Changing the C# project to .Net Core 3.1 makes the code compile cleanly, but we’d prefer to keep most of our projects Net Standard 2.x
Thanks.
Hi David,
At some point, don’t you need to choose your underlying runtime (be it .Net “standard” or .Net “Core”)?
What kind of scenario do you see here?
Jean
Hi VC team,
Thank you very much for this great and long awaited feature!
This has been a long time in the making but it finally arrived!
We (native devs) now have a way to support the .Net “Core” runtime :-)!
I see great vcprojx support in both compiler _and_ IDE. Thanks!
How about CMake support? Is it too much to ask for?
Any guidance from Microsoft on how to have the best of both worlds (CMake & /clr:netcore)?
Thank you anyway! Awesome work on this!
Jean
I have a c++ /clr project that use winForm and these libs:
legacy_stdio_definitions.lib, Ws2_32.lib, Kernel32.lib, Iphlpapi.lib, User32.lib, Synchronization.lib, .., Winmm.lib, Userenv.lib.
My big question is .. do you think that I can Port it to .NET Core ?
Thank You.
CAP
Can we use donet publish for C++ CLI project?
I am using the new .NET Core support for C++/CLI in an Apache project. Using Microsoft Visual Studio Professional 2019 Preview
Version 16.5.0 Preview 1.0.
I’m getting an EETypeLoadException. Any assistance would be greatly appreciated.
When I enable loading of system symbols, I get prompted for location of: f:\workspace\_work\1\s\src\jit\lclvars.cpp
So the EETypeLoadException is thrown in clrjit.dll, from lclvars.cpp
Here’s the exact exeption and call stack:
Exception thrown at 0x00007FFC0BFB9129 in PutGetRemoveCore.exe: Microsoft C++ exception: EETypeLoadException at memory location 0x0000004066178CF0. occurred
Call stack is:
[External Code]
clrjit.dll!Compiler::lvaInitTypeRef() Line 275 C++
clrjit.dll!Compiler::compCompileHelper(CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags, CorInfoInstantiationVerification) Line 5871 C++
clrjit.dll!Compiler::compCompile(CORINFO_METHOD_STRUCT_ * methodHnd, CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags) Line 5367 C++
clrjit.dll!jitNativeCode(CORINFO_METHOD_STRUCT_ * methodHnd, CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags, void * inlineInfoPtr) Line 6663 C++
clrjit.dll!CILJit::compileMethod(ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, unsigned int flags, unsigned char * * entryAddress, unsigned long * nativeSizeOfCode) Line 319 C++
hostpolicy.dll!coreclr_t::execute_assembly(int argc, const char * * argv, const char * managed_assembly_path, unsigned int * exit_code) Line 152 C++
hostpolicy.dll!run_app_for_context(const hostpolicy_context_t & context, int argc, const wchar_t * * argv) Line 247 C++
hostpolicy.dll!run_app(const int argc, const wchar_t * * argv) Line 276 C++
hostpolicy.dll!corehost_main(const int argc, const wchar_t * * argv) Line 390 C++
hostfxr.dll!execute_app(const std::wstring & impl_dll_dir, corehost_init_t * init, const int argc, const wchar_t * * argv) Line 146 C++
hostfxr.dll!`anonymous namespace’::read_config_and_execute(const std::wstring & host_command, const host_startup_info_t & host_info, const std::wstring & app_candidate, const std::unordered_map<enum known_options,std::vector<std::wstring,std::allocator>,known_options_hash,std::equal_to,std::allocator<std::pair<enum known_options const ,std::vector<std::wstring,std::allocator>>>> & opts, int new_argc, const wchar_t * * new_argv, host_mode_t mode, wchar_t * out_buffer, int buffer_size, int * required_buffer_size) Line 502 C++
hostfxr.dll!fx_muxer_t::handle_exec_host_command(const std::wstring & host_command, const host_startup_info_t & host_info, const std::wstring & app_candidate, const std::unordered_map<enum known_options,std::vector<std::wstring,std::allocator>,known_options_hash,std::equal_to,std::allocator<std::pair<enum known_options const ,std::vector<std::wstring,std::allocator>>>> & opts, int argc, const wchar_t * * argv, int argoff, host_mode_t mode, wchar_t * result_buffer, int buffer_size, int * required_buffer_size) Line 952 C++
hostfxr.dll!fx_muxer_t::execute(const std::wstring host_command, const int argc, const wchar_t * * argv, const host_startup_info_t & host_info, wchar_t * result_buffer, int buffer_size, int * required_buffer_size) Line 541 C++
hostfxr.dll!hostfxr_main_startupinfo(const int argc, const wchar_t * * argv, const wchar_t * host_path, const wchar_t * dotnet_root, const wchar_t * app_path) Line 33 C++
PutGetRemoveCore.exe!exe_start(const int argc, const wchar_t * * argv) Line 220 C++
PutGetRemoveCore.exe!wmain(const int argc, const wchar_t * * argv) Line 279 C++
[External Code]
From what I’ve read, Mixed Mode assemblies are supported, but an additional piece of info I forgot to mention is that our C++/CLI assembly links statically to our native C++ library. Could that be part of the problem. I will try a dynamic link and report back.
What about ARM64 support?
If I try I’m told this is missing: “msvcmrtd_netcore.lib” when compiling. I see this lib is provided for ARM32, x64 and x86, but ARM64 appears to be missing. Oddly enough there are other ARM64 netcore native libs.
I just upgrade to VS16.4 and try to migrate my project.
But I can’t find any “Framework” for target .net core 3.1 when I try to add reference of WPF.
I need it to convert my custom structure to WPF’s structure like System::Windows::Media::Color…
I have the same trouble as you had.
I want to use System.Windows.Threading.Dispatcher.
But I can’t find any Framework to add reference.
I have the same issue. Not able to write Wpf controls in cli/c++ for best support of native c++ libraries.
this comment has been deleted.
I am currently trying to migrate a Windows project to NetCore 3.1.
It is an MFC application that calls modules in a C # library through a CLR wrapper.
[App.exe (C ++)] —> [CRL Wrapper (C ++ / CLI)] —> [.NET Core 3.1 Library (C #)]
So far, I have not been able to get even a small test application to work. Everything is ok for the compiler. But instantiating the wrapper class in the application produces the following exception:
Unhandled exception at 0x770035D2 in MFCApplication.exe:
Microsoft C ++ exception: long at memory location 0x0059FB5C. occurred
stack:
[External code]
Ijwhost.dll! Start_runtime_and_get_target_address (unsigned int cookie) Line 145 C ++
Ijwhost.dll!_start_runtime_thunk_stub@0 () Line 37 Unknown
MFCApplication.exe! CMFCApplicationApp :: InitInstance () Line 58 C ++
[External code]
MFCApplication.exe! WWinMain (HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26 C ++
[External code]
Is this scenario currently possible with NetCore 3.1?
I use VS 2019 (16.4.1)