What's the story going to be (if any) around interop with unmanaged code for ASP.net vNext / Core CLR?
The key bits (DllImport and friends) appear to be present to allow for unmanaged code interop, but how would things such as packaging and deployment work in this context? The basic build artifact in vNext / CoreFX no longer appears to be an assembly, but a NuGet package. So in that case, how would we make the new project.json system work so that unmanaged dlls that we're P/Invoking into are also included in the resulting NuGet package?
Or am I talking about scenarios that have not been considered yet (or more disappointingly, not going to happen)?
The story is yet to be fully fleshed out, but there are already examples of how to do this. Ultimately we (the Microsoft teams working on this) are working on some scenarios to enable NuGet packages to better support native content in packages.
To see one example of this, the Kestrel web server has some of its own managed code, plus it includes libuv in its NuGet package for an efficient async IO implementation that is cross-platform.
Because there isn't yet a built-in general solution in NuGet, the build scripts for Kestrel use some custom actions to include the native content in the NuGet package. Then to load libuv there's some code that dynamically figures out which native libuv to load based on the environment in which it is running.
So, yeah, it's a bit messy, but it does work, and this is definitely high on the team's priority list to improve.
Related
Setup:
single offline (blocked from inet) server
multiple applications
apps load .net core assemblies (plugins with their own assembly or nuget deps) at runtime through reflection
Problem: What is the most efficient way to deploy the application set?
Currently I publish application per application, so that all required nuget packages and assemblies are available. However, this means the complete .net core and asp.net assembly set is copied over multiple times.
To have a shared deployment with an installed .net core runtime or sdk, there does not seem to be an easy way to make the required nuget packages available on an offline machine?
Any suggestions on the best-practices setup for these kind of deployments?
Cheers.
Sounds like you could use the global packages folder.
If your projects use PackageReference they consume their dependencies directly out of that folder instead of copying them locally, so if you're worried about disk space that would be a way to avoid duplication if that's what you're really worried about.
I have recently started learning ASP.NET Core with the help of an ebook. There are few statements mentioned in the initial chapters, which I am unable to understand clearly.
For eg. following statements are mentioned under Foundational improvements in ASP.NET Core section
Lightweight and modular HTTP request pipeline
Ships entirely as NuGet packages including the runtime
Runtime can be installed Side-by-side- allows you to version application along with runime
The above statements are not clear to me probably because of the term "modular HTTP request pipeline" from Point 1 and terms "runtime" and "version application" from Point 2.
Any short explanation or reference to the suitable doc will be appreciated.
Thanks
http request pipeline
They totally rebuild the HttpListener which is also called the http server. Normally you would host your application in iis which would give you tons of functions but is 1 very old, massive sluggish application.
Now on default you run the application as a console which starts up a HttpListener which is called Kestrel in dotnet core.
This kestrel is totally build from the ground up (so modular priciples and barely any technical depth). And is build based on a very vast C++ library called libuv.
The modularity in this means that it has been build in various loosly coupled parts, meaning that you could replace or extend those parts if you want to. For example use a test server for automatic integration tests.
Ships in nuget packages
Normally you would install a netFramework eg: 4.5.0 and you would already get all these system.* dlls eg: System.web.dll
Now all these dll's are nuget packages and bundled into 1 package called netstandard: https://www.nuget.org/packages/NETStandard.Library/.
Multiple runtimes
If you build a dotnet project, it creates Dlls. these dlls can be run by by any OS if that os has installed the dotnet runtime. (basicaly dll is intermediate language and can be run by the dotnet runtime).
You can also build your dotnet project to include the runtime inside your application, so you can run multiple dotnet applications on an OS with different Dotnet runtime versions.
The downside of this last option is that you have to build your dotnet project for every OS specifically. So normally people choose to just build the OS independent Dlls and make sure the right runtime is installed on the OS.
I'd like to (try to) add HTTP/2 support to Kestrel - for my own edification, for now. I'm using Ubuntu as my dev platform, because my requirements include using Linux.
Of course, it appears fairly simple to make changes to the Kestrel code - just clone the source from https://github.com/aspnet/KestrelHttpServer, then make my changes, then build the assembly. The problem I'm having, is getting other code to reference my modified code/assembly rather than the "official" assembly from .NET Core. To that end, I would love to hear how to do the following:
"Install" my changed Kestrel assembly locally such that anything that depends on that assembly uses my changes automatically. This may include projects that I create via dotnet new -t web, as well as other .NET Core assemblies that I haven't modified.
Be able to propagate my changes to other machines as necessary, in a controlled manner.
Thank you, and have a good one!
There are 2 options
create own nuget package from sources using dotnet pack command, and then use own feed for nuget restore. See related SO answer and Hosting your own nuget feed guide;
or
add Kestrel project into your solution and add dependency as "project reference".
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 ?
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.
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)
.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
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).
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.
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.
Replace <TargetFrameworkVersion> properties with <TargetFramework>netcoreapp3.1</TargetFramework>.
Remove any .NET Framework references (like <Reference Include="System" />). .NET Core SDK assemblies are automatically referenced when using <CLRSupport>NetCore</CLRSupport>.
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:
When compiling, pass -clr:netcore to cl.exe.
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).
Copy ijwhost.dll (from the .NET Core app host directory) to the project's output directory.
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
I would like to test my app under the Mono runtime (to see if the SIMD support can offer me any performance improvements). I am compiling my app with csc.exe (in Visual Studio 2005) and then running it as mono.exe --debug MyApp.exe. However, Mono is using their own implementation of the core libraries (System.IO, etc.) which have some stuff not implemented.
Is it possible to tell the Mono runtime to use the core libraries shipped by Microsoft, rather than their own?
(Yes, I do realize that this would mean I'd have to distribute both MS .NET 2.0 and Mono with my app. If SIMD support is helpful for me, I'll eliminate these dependencies and use Mono's implementation. For now, I just want to test out the SIMD stuff without having to make a whole lot of other changes.)
You could put Microsoft's assemblies in your app's bin folder, and I think they would be picked up and used. If nothing else, you can put Microsoft's assemblies in Mono's GAC so it would have no choice but to use them.
Having said that, I highly doubt Microsoft's assemblies will work due to coupling between the assemblies and the runtime. (That is, the assemblies probably make private calls into the runtime that are different than Mono's runtime.)