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 ;)
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 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.
I'm using VS11 Beta on Win 8 Consumer Preview. After install VS11 Beta I have F# 3.0 SDK installed. But I'm not able to find a compatible FSharp.PowerPack.dll as CodePlex only provides PowerPack for F# 2.0.
Any idea how to deal with this?
You can compile the PowerPack sources on your own (against F# 3.0), to make your own copy of the library.
Alternatively, I think a binding redirect in your final foo.exe.config, along the lines of
https://stackoverflow.com/a/9648673/19299
but redirecting 2.0.0.0 (that PowerPack uses) to 4.3.0.0 (in VS11 SDK) will also work.
In addition to what Brian said, I think that the easiest way to use functionality from the F# PowerPack is to just copy the source code for the parts that you're using to your project.
The PowerPack library contains quite a wide range of functionality and I typically only use one or two parts. If you're looking for components like lazy list, parallel collections (PLINQ), hash multi-map or async extensions, you can usually just copy one or two files and you don't have to build the whole library.
(Also note that most of the LINQ functionality from F# PowerPack has moved to the F# core library in F# 3.0)
Don Syme has recently uploaded F# PowerPack 4.0.0.0 which is compiled against F# 3.0.
There is an MSI installer for Windows.
There is also a zip archive which even worked with MonoDevelop 3.0/F# 3.0 when I tried to use it on Mac OS X. So much time and efforts are saved especially when one needs to use fslex/fsyacc for parsing.
Update for F# 4.0: At this point the F# PowerPack - or at least the remnants thereof - are on GitHub. The major components have been spun off into their own projects. (FsLex/FsYacc is what brought me here too.)
Is Enterprise Library 5.0 backwards compatible with Enterprise Library 4.1?
Can I just change the reference and have it work?
The definitive answer is: maybe.
It really depends on the scenario and how you have used the blocks. In the best case scenario you could replace the assembly references, change the configuration and it should work.
From Microsoft Enterprise Library 5.0 Change Log:
Major architectural revisions in
Enterprise Library to use the
dependency injection mechanism. [...]
Enterprise Library no longer uses the
static facades and static classes that
were used in previous versions.
However, these facades and classes are
still included in Enterprise Library
for backwards compatibility with
existing application code, and you can
continue to use the previous approach
to creating Enterprise Library
objects.
Of course, things rarely seem to work out that way so, to help resolve any issues and go through the migration approach, you should definitely read:
Microsoft Enterprise Library 5.0
Change Log: Breaking Changes
Microsoft Enterprise Library 5.0
Migration Guide.
In a nutshell, we've tried hard to keep public facing API backward compatible as much as possible. And for most users, the upgrade path would be pretty much the change of references and a rebuild.
The architectural refactoring mentioned above includes major revisions of internal guts. However, you should not be affected unless you write custom blocks. BTW, guidance on EntLib5.0 extensibility (including on how to write custom blocks) will be available soon.
Two references above (the Change Log and the Migration Guide) will help you with migration.
So far, most people who I spoke with commented on a pretty easy and straightforward experience.
Please let me know what yours was and whether you ran into any issues.
Regards,
Grigori Melnik
Enterprise Library Producer
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.)