33

Our project structure is like,

native.dll :- This contains pure native code written in c\c++. This native.dll exposes some functions using *def file.

Wrapper Library(wrapper.dll compiled with .Net framework v4.0) :- In order to use functionality of native.dll, a Wrapper lib(wrapper.dll) is written in C++\CLI using :clr\oldsyntax. This wrapper has all code of Interoperability and Marshalling.

Application(Console App v4.0) directly uses wrapper.dll to use functionality provided by native.dll.

Now this project needs to run in .Net Core. This means we will have an .Net Core application that will reference wrapper.dll that in turn will refer native.dll.

I know this will not directly work. But the issue is whether .Net Core(CoreCLR) supports C++\CLI (clr\oldsyntax) runtime environment ?

If no, what can be the possible solutions to this application work ?

User1234
  • 1,543
  • 4
  • 22
  • 32
  • @HansPassant :- You said "There are few practical platform targets that could execute that native code anyway", can you please elaborate this ? Do really mean there is no way currently to run these type of Projects under .Net Core ? – User1234 Aug 25 '16 at 09:53
  • @HansPassant : thanx for this. Yes you are right, we selected .Net core as we want to run our dotnet code(wrapper.dll which in turn invokes native.dll) in linux. But as you said, as of now CoreCLR does support C++/CLI runtime thus all this does not seems feasible. I had actually gone through lot of msdn blogs for .Net core but none of them hinted me about C++\CLI integeration in .net core. So does .Net core team will really support this in near future or not ? – User1234 Aug 25 '16 at 10:28
  • 2
    There are many scenarios where C++/CLI support for .NET Core would be very useful. For e.g., if you are working with cross-platform C++ code and want to interface it with a .Net business layer for faster development. I'm very surprised that MS hasn't provided this - it seems ideal. – Zesty Aug 29 '16 at 08:13
  • 3
    @hanspassant That’s really a bit simplified. What if that DLL happens to be a cross platform library that you can compile for Linux and macOS also? Such use cases clearly do exist and it would be nice to have C++/CLI to support them. – Per Lundberg Dec 06 '17 at 12:40
  • 1
    I have the same need, too, and is surprised that it's not supported already. – Weipeng Sep 15 '18 at 00:32

5 Answers5

11

whether .Net Core(CoreCLR) supports C++\CLI (clr\oldsyntax) runtime environment ?

As far as I know there is no plan to support C++/CLI with .NET Core.

If no, what can be the possible solutions to this application work ?

You can (should) provide a C API. Mono e. g. supports P/Invoke and .NET Core also supports P/Invoke (see also this Stack overflow question and this DllMap related ticket).

Update (2022-09-02): This answer is from 2016. See the other answers (e.g., this) for what is possible with recent .Net Core versions.

Sonic78
  • 680
  • 5
  • 19
  • 4
    but none of the alternatives can beat the elegance C++/CLI provides. – Weipeng Sep 15 '18 at 00:33
  • 3
    .net core 3.1 will support c++/cli on windows. – markf78 Oct 01 '19 at 22:29
  • 2
    @markf78 do you know if that means we can run existing C++/CLI assemblies in .NET Core apps without recompiling them? – Cocowalla Nov 05 '19 at 15:03
  • 1
    @Cocowalla I only know what was posted here: https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/ – markf78 Nov 05 '19 at 15:30
  • 1
    @markf78 someone from Microsoft just said "no": https://github.com/dotnet/coreclr/issues/18013#issuecomment-549880929 :`( – Cocowalla Nov 05 '19 at 18:51
  • does this change anything?: https://devblogs.microsoft.com/cppblog/an-update-on-cpp-cli-and-dotnet-core/ – knocte Apr 23 '20 at 02:16
9

Officially announced eventually... (next wish... support linux @ .Net 5 ^^)

https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/

C++/CLI will have full IDE support for targeting .NET Core 3.1 and higher. This support will include projects, IntelliSense, and mixed-mode debugging (IJW) on Windows. We don’t currently have plans for C++/CLI for targeting macOS or Linux. Additionally, compiling with “/clr:pure” and “/clr:safe” won’t be supported for .NET Core.

The first public previews for C++/CLI are right around the corner. Visual Studio 2019 16.4 Preview 1 includes an updated compiler with “/clr:netcore”

Updat: From replied of origin url: "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"

(16.4 Preview1 cannot create C++/CLI with .NetCore project.)

191015 16.4 Preview2 Released. I'v tried asp.net core 3.1 with c++/CLI dll, it works. (need set plateform to x64 both asp.net core and c++/CLI dll)

wade.ec
  • 181
  • 2
  • 3
  • +VS2019 16.4 preview2, .NetCore 3.1 Preview 1 Released -- https://github.com/dotnet/coreclr/issues/18013#issuecomment-542521040 (new "CLR Class Library (.NetCore)", "c++ library target the .net Core") -- https://github.com/dotnet/coreclr/issues/18013#issuecomment-542570482 (There are a few known issues in the preview.) – wade.ec Oct 16 '19 at 15:27
  • 1
    You can get this working without the VS preview. Right-click the class you want to make managed and go to "Properties" - "C/C++" - "Code Generation". Disable "Minimal Rebuild", disable C++ Exceptions, set Basic Runtime Checks to Default. Go to "Precompiled Headers" and set it to 'Not Using...' Go to "Command Line", add "/clr /fu*pathtomscorlib*. e.g. "/clr /FU "C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\3.1.0-preview1.19506.1\mscorlib.dll"" – mitchellJ Oct 17 '19 at 14:41
  • I still need to instal .net core 3.1-preivew1, and I can work with VS 2019 16.3.x w/o preview, right? for need "3.1.0-preview1.19506.1\mscorlib.dll" – wade.ec Oct 18 '19 at 09:01
  • 1
    Yep. You need the .net core preview but not the VS preview. https://dotnet.microsoft.com/download/dotnet-core/3.1 – mitchellJ Oct 18 '19 at 14:20
  • @wade.ec do you know if we can run older, existing C++/CLI assemblies in .NET Core apps without recompiling them? – Cocowalla Nov 05 '19 at 15:07
  • @Cocowalla I don't know. There will be a document about c++/cli net core, but still not update since 06/28 https://github.com/dotnet/docs/issues/13152 – wade.ec Nov 07 '19 at 04:37
8

.net Core team will only commit (now?) to supporting C++/CLI for Windows only.

The intention was to deliver it for .net Core 3.0. While I haven't found explicit mention of it yet in the release notes, C++/CLI support was a prerequisite for delivering WPF (windows-only), which is now supported in .net Core 3.0.

Support mixed-mode assemblies on Windows - #18013

This issue (#18013) 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.

The github issue (#659) mentioned above by @Tomas-Kubes, Will CoreCLR support C++/CLI crossplat? - #659, is about cross-platform C++/CLI.

BTW, I am getting compiler warnings on "clr\oldsyntax" with VS2017/.net-4.7. So this compiler flag is already deprecated.

UPDATE: This isn't coming till .Net Core 3.1

Hezi
  • 496
  • 6
  • 15
  • wrt your update, in fact: https://devblogs.microsoft.com/cppblog/an-update-on-cpp-cli-and-dotnet-core/ but is it cross platform? – knocte Apr 23 '20 at 02:16
4

Another potential solution (though obviously quite a difficult task) if you want to stick with C++ (i.e. expose an OO interface to .NET) might be to have a look at CppSharp from the mono project. It is able to expose native C++ code through an automatically generated C# wrapper. It supports Windows, Linux as well as OSX. However, I don't know if the generated code can be compiled to a .NET standard target (didn't try to). I can only suppose it would because the generated code does not use any fancy API (it is basically interop and marshalling code); and, by the way, it is also possible to customize the generation process (although, once again, probably not an easy task).

odalet
  • 1,389
  • 10
  • 18
  • 5
    Or try SWIG (http://www.swig.org/). SWIG is tool that connects programs written in C and C++ with a variety of high-level programming languages (including C#). – Sonic78 May 16 '17 at 09:14
4

For those who are looking at this for general .Net Core stuff without specific clr parameters (as this is a high result on google) Microsoft have written a guide on how to port C++/CLI to .Net Core:

https://learn.microsoft.com/en-us/dotnet/core/porting/cpp-cli

Port a C++/CLI project

To port a C++/CLI project to .NET Core, make the following changes to the .vcxproj file. These migration steps differ from the steps needed for other project types because C++/CLI projects don't use SDK-style project files.

  1. Replace <CLRSupport>true</CLRSupport> properties with <CLRSupport>NetCore</CLRSupport>. This property is often in configuration-specific property groups, so you may need to replace it in multiple places.
  2. Replace <TargetFrameworkVersion> properties with <TargetFramework>netcoreapp3.1</TargetFramework>.
  3. Remove any .NET Framework references (like <Reference Include="System" />). .NET Core SDK assemblies are automatically referenced when using <CLRSupport>NetCore</CLRSupport>.
  4. Update API usage in .cpp files, as necessary, to remove APIs unavailable to .NET Core. Because C++/CLI projects tend to be fairly thin interop layers, there are often not many changes needed. You can use the .NET Portability Analyzer to identify unsupported .NET APIs used by C++/CLI binaries just as with purely managed binaries.

Build without MSBuild

It's also possible to build C++/CLI projects without using MSBuild. Follow these steps to build a C++/CLI project for .NET Core directly with cl.exe and link.exe:

  1. When compiling, pass -clr:netcore to cl.exe.
  2. Reference necessary .NET Core reference assemblies. When linking, provide the .NET Core app host directory as a LibPath (so that ijwhost.lib can be found).
  3. Copy ijwhost.dll (from the .NET Core app host directory) to the project's output directory.
  4. Make sure a runtimeconfig.json file exists for the first component of the application that will run managed code. If the application has a managed entry point, a runtime.config file will be created and copied automatically. If the application has a native entry point, though, you need to create a runtimeconfig.json file for the first C++/CLI library to use the .NET Core runtime.

There are some more nuances but these are the actual steps to port

user3797758
  • 829
  • 1
  • 14
  • 28