A legacy VB6 app I maintain has dependencies on some third-party DLLs. DLL information (from embedded metadata) is pasted below.
I am looking for any pointers to documentation, a current vendor who supports these DLLs, or any tribal knowledge at all about what they do.
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 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.
I noticed how you don't have to link opengl32.lib by yourself when you use libraries such as SFML and I'm really wonder how that could be since I have to link opengl32 in my projects that are using my own multimedia library which is a static library? Is it simply because the SFML library is a dynamic library and opengl32 is linked in the SFML project?
This is not a question about SFML, it's rather a question about all DLLs in general.
Yes, DLLs can reference other DLLs, or statically compile them internally. To inspect external dependencies, Microsoft long ago developed a tool called Dependency Walker, in which you can drag a DLL or executable and see which DLLs it depends on (and thus are automatically loaded). The tool used to be shipped with Visual Studio by default, but you can now download it from here for free. That page kind of explains everything else about it.
If a dynamic library is using another dynamic library, it will automatically get loaded into the process, yes.
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.