I have the source code of a dll project that Targets .NET Framework. And I'm current developing a Universal App, I want to reference that dll to my project but it is not applicable since the Universal App uses a .NET CORE and that dll is specifically targets .NET Framework.
I'm thinking that I can change the dll's Target Framework since I have the source code but I don't know how.
Or is there another way of solving this?
I don't think there's an automated way to convert the library directly (if anyone knows a way, would be more than happy to hear about it).
However, sine you have the source code you can manually move the code.
Create a new Universal Application Class library and start move the code from the old library in there.
Chances are, not everything will work, since there are pretty major differences between namespaces and APIs between .NET framework and .NET core but at least you'll know what you need to change. I would recommend a modular approach where you include portions of the library, make sure it compiles and so on.
Related
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've got a netcoreapp1.0 (Microsoft.NETCore.App) application that is a kestrel based web service and I'd like to leverage some of my existing C# DLLs (.NET 4.5.x) I also have a few other netstandard1.6 (NETStandard.Library) assemblies that I'm using.
The big question: is it possible to pull in legacy code without porting it all to DotNetCore 1.0?
Breaking it down, I suppose I'd like to know:
What is the correct framework target for my application? I'm assuming it has to be netcoreapp1.0 rather than net451.
What imports (ex. dnxcore50, net451) does my application require?
What additions need to be made to my C# assembly? Is a project.json sufficient or does having an xproj provide some additional value?
What is the correct framework target for my C# assembly? I'm assuming NETStandard.Library 1.6.0 is wrong since I believe it would require code changes to get compiling.
Any suggestions and/or guidance would be greatly appreciated. Thanks!
Since the meat of the work was all in comments...here's a summary of the answer:
Everything works as expected if you accept that net46 can't run under netstandard1.6. That is, if my DotNetCore app, DotNetCore library, and C#.NET library all target net46 it works as expected.
We are using some old open-source .Net Framework libraries that depend on things that are not in .Net Core. Can Mono be used to fill in the rest of .Net Framework?
Specifically I'm thinking of creating a Universal Windows class library that includes everything in Mono (excluding some of the System namespace) that changes the namespaces from System.* to MonoSupport.System.*.
Of course, better approaches would be to re-write the library's code, use a different library, or be more selective in taking things from Mono. I was hoping to do this as a temporary measure.
(I want to use iTextSharpLGPL but it uses XmlTextReader, streams with .Close(), System.Security.Cryptography, etc.. The pay version of the library does not support UWP either.)
Edit: I gave up on this and rewrote my app to use Apitron. That worked great until I tried to deploy and found out they don't support .NET Native. I'm now waiting for some library to support PDF generation on UWP.
I do not think so. The following immediate reasons
Mono is a clone of the .NET Framework and therefore based on mscorlib ideas, while UWP is based on System.Runtime. Would require significant extra effort.
UWP apps - when released - are based on the .NET Native runtime. This runtime enforces some patterns in the library implementations (e.g. no reflection, no C++ implementation of types etc). Mono is also strong in AOT, but I think there are dragons.
Mono is a bad choice. Better is the microsoft referencesource for the .NET Framework as published on github.
The time you will invest in your plan will be so significant high, it is much better invested fixing it in corefx directly and wait for the next release of UWP to contain your fixes.
For your problem I would urgently recommend you to fix the problem as a submission upstream at iTextSharpLGPL by surfacing new methods and removing of close or maybe by just copying the MIT licensed XmlTtextReader. But I highly recommend you, not to mess around with crypto ;)
I have an old project, I converted to Visual Studio 2010. Of course, it remained targeting the .NET Framework 2.0. So, when I edit the target framework in the Compile tab, and change it to 3.5, it closes and reopens the project. However, the References still show that System, System.Data, etc. are still .NET 2.0. Further, I cannot access the .ToList method for an array that I need, so it must not be loading the newer framework. Does anyone have ideas on how it can work?
Well it did minimum changes required to switch framework version, so that your breaks are minimal. If you want, you can manually remove and re-add .NET DLLs targeting a newer version. Even though in most cases upgrading version for all referenced DLLs is not a problem, in the most generic case, there may be issues (especially if you hacking deeper into .NET core).
Regarding ToList, you just need to import System.Linq, which is in System.Core.dll.
I am in the process of creating a lightweight application in vb.NET, and was wondering if it is possible to create an application that uses some of the dll's within the .NET 2.0 framework, without actually using the framework itself.
For instance, can I take the dlls from the .NET directory that the app will reference (and only those dlls that it references), put them into a folder inside the app's directory, and then just change the reference path to that new location? That way, when the app is installed on pc's without .net framework installed, the dlls can just be zipped and copied over to the newly installed app directory.
This may all sound a bit confusing, just let me know if you need any more info.
It is quite unlikely that you'll be able to do that.
There is this thing called .net framework client profile for creating lightweight .net apps that do not need the whole framework but you still need to have that installed.
I would recommend using something like Delphi if you need a standalone exe that does not depend on anything.
There is concept of Client Profile in .NET 3.5 and .NET 4.
That is subset of .NET, smallest necessary fraction of .NET that client must have in order to be able to run .NET applications targeting client profile.
There is more detailed overview of the features you may use when targeting client profile.
Unless you move to .Net 4 or above, you need full framework on the client computers. Having said that, which OS are you targeting? Newer MS OS often come with .Net framework installed already.