I have a piece of code that compiles for both the Silverlight and the .NET targets. It depends on Json.NET and SharpZipLib. My goal is to make a portable library that Silverlight and .NET projects can both link against.
Since there is no version of SharpZipLib targeting "portable-net40+sl50", I have a problem.
However, if I knew how, I would be willing to write the wrapper code myself.
So: How can I write a portable library that depends on Silverlight's SharpZipLib when being linked against from Silverlight and depends on .NET's SharpZipLib when being linked against from .NET?
Is that at all possible or is that something only Microsoft can do?
If your code uses a limited sub-set of the SharpZipLib API, you could create a "dummy" PCL library comprising this API subset, but without any functionality implemented.
What you then must do is to change the strong name (assembly name and signing) and version of the existing .NET and Silverlight SharpZipLib:s to be the same as your "dummy" PCL SharpZipLib and re-compile the platform specific libraries as well.
With this set of assemblies (PCL, .NET and Silverlight) you will now be able to consume the PCL library from other PCL libraries. In a platform specific application that makes use of PCL libraries that in turn consumes the SharpZipLib library, you should explicitly reference the platform specific SharpZipLib library that has the same strong name and version as the PCL analogue.
You should find more about this technique ("bait-and-switch") here and here. The PCL Storage project is also a good example of where this technique has been applied.
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 testing an UWP application and I want to use a proxy to consume a WCF service. I have a proxy that is a library for .net 4.6 but I can't add this project as reference in the project of universal application. It is normal because is a library for .net 4.6.
So I am trying to create a portable library and I have two options, to create a portable library. This option let me say what targets can I use. I select .net 4.6 and windows universal 10.0. The problem is that I can't add a reference to the System.ServiceModel that I need to use the proxy.
The other option is portable library for windows universal. In this cases I can't select the target projects, it has sense because it is only for universal applications. In this case I can add the reference to the System.ServiceModel.
I know that in a portable library I only can use the libraries of the target project more restrictive, in this case I guess that is windows universal, no .net 4.6. But then, why do I can add the reference in the portable library for universal applications and not in the portable library in which I am using .net?
I would like to have a generic portable library to be able to use the proxy in WPF applications and universal windows applications.
Thanks.
Unfortunately there isn't a simple subset relationship between different target frameworks; i.e. in your case UWP is not a subset of .NET 4.6, therefore when you create a portable class library targeting both, you don't simply have all the APIs from the smaller framework available.
When dealing with clientside System.ServiceModel code the situation is even more confusing: although both target platforms include basic support for WCF proxies, the APIs are different enough that there is no portable equivalent that would be available when creating a PCL. This is the reason for the behavior that you are seeing: you can create a proxy both in a .NET 4.6 class library and in a UWP class library, but you can't create it in a portable class library targeting both of them. You will need to create 2 separate libraries.
If you're only going to call the proxies from the platform specific WPF an UWP code, then this shouldn't really be a problem, but I suspect that you would like to call them from the business logic code which you would prefer to implement in a portable class library.
You can achieve this as follows:
Create an interface for the proxy class in a common portable class library for UWP and .NET 4.6.
Reference this common library from both platform specific class libraries: UWP and .NET 4.6. The proxies in these 2 libraries should implement the common portable interface. I haven't tried it, but if you configure the service references to reuse the types from your portable class library, the generated proxies should already implement your interfaces. This way you could avoid create wrappers around your proxies in each of the platform specific class libraries.
You can now write business logic in the common portable class library and only ever work with proxies using the common interface. To get concrete instances of this interface on each platform use a portable dependency injection framework, such as Ninject.
In application code for each platform you will then initialize the dependency injection framework by registering the correct proxy implementation of the interface, either UWP one or .NET 4.6 one. Of course you will also reference the common portable class library from both applications, as well as the correct platform specific class library in each application.
I'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?
I am a .net developer who has never touched c++. I don't want to either :)
Unfortunately, I have to work with c++ module in .net 4.0 and I am clueless.
Is there a tool that can generate a .net assembly for a given c++ module?
If not, what are my next steps to successfully call these c++ libraries?
There are many ways:
COM Interop
Tlbimp.exe (Type Library Importer)
How to: Generate Primary Interop Assemblies Using Tlbimp.exe
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.
PInvoke/DllImport
Calling Native Functions from Managed Code
The common language runtime provides Platform Invocation Services, or PInvoke, that enables managed code to call C-style functions in native dynamic-linked libraries (DLLs). The same data marshaling is used as for COM interoperability with the runtime and for the "It Just Works," or IJW, mechanism.
C++/CLI
Mixed (Native and Managed) Assemblies
How To: Migrate to /clr
This is more advanced because it will most probably require the C++ module to be updated and re-compiled.
Mixed assemblies are capable of containing both unmanaged machine instructions and MSIL instructions. This allows them to call and be called by .NET components, while retaining compatibility with components that are entirely unmanaged. Using mixed assemblies, developers can author applications using a mixture of managed and unmanaged functionality. This makes mixed assemblies ideal for migrating existing Visual C++ applications to the .NET Platform.