CODEWITHSUNDEEP
c++-cliunmanaged.net-coremanaged-c++coreclr
User1234
User1234

Reputation: 1623

C++/CLI Support in .Net Core

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 ?

Upvotes: 34

Views: 27540

Answers (5)

Sonic78
Sonic78

Reputation: 798

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.

Upvotes: 12

user3797758
user3797758

Reputation: 1043

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

Upvotes: 6

wade.ec
wade.ec

Reputation: 311

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)

Upvotes: 10

Hezi
Hezi

Reputation: 518

.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

Upvotes: 8

odalet
odalet

Reputation: 1419

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).

Upvotes: 4

Related Questions