I have perhaps a silly question:
We have a VC++ COM DLL (developed internally) and we have ported our main app to C# and used COM Interop, reg-free to access the COM dll. Everything works just fine with internal embedded manifest.
However, the friendly product-dev/marketing/sales want to minimize the package and include the COM dll directly. Somehow, someone became convinced that the app distro should include the exe only (since it's unmanaged we can't just ILMerge it in).
Since we have the tlb/lib of the COM, could we somehow statically link it, without porting the whole COM to C# managed re-work?
Thank you
P.S. Pardon my wording: the company was downsized and I am the Python guy who had to learn everything .NET in the last week or so since now I am doing my job and the job of 2 ex-senior .net developers
It looks like Costura can more or less do this.
https://github.com/Fody/Costura
It specifically has support for merging unmanaged assemblies (ie a C++ DLL) into a .NET assembly.
Note - this is not true static linking but would achieve the aim of packaging everything in the single EXE to be distributed.
It is possible to include the source for the COM DLL into the project for the exe, or you could change the COM DLL project into a static lib project. Once you've accomplished that, you must modify the code to create the COM objects directly. All said, neither options are particularly easy.
Alternatively you could look into products like Spoon Studio that would allow you to wrap your exe and COM DLL into one exe without any code.
Related
I have a .Net add-in and within this I have referenced a DLL I have made in C++/CLI. The DLL was designed against the OpenCV API - so now my .Net application can take advantage of the cool graphics capabilities offered by OpenCV.
The problem occurs when I deploy my add-in to other computers. When the user enacts a part of the program that specifically calls upon my C++ DLL it complains about missing the reference:
I suspect the code does not actually know where the DLLs are located but within my dev environment everything (obviously) works as I will have my environment set up different to your standard build PC.
What am I missing here ?
How can I successfully call DLLs created in C++ from a C# add-in? Bearing in mind add-ins are supposed to simplify the customisation of software like Office etc. This is very important - I have to be able to roll in non-.Net DLLs into my project and my code be able to find them.
My dll is just a plain dll, not a COM compatible dll (maybe it should be?) or should I be decorating my C++ code with __declspec(dllexport) a la https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=vs-2017
So 2 things
Use Dependancy Walker to identify any dependancies on your dll and the dlls it uses further down the 'tree' hieracrchy. I found 2 that were missing and it wasn't obvious without this useful tool. Don't be overwhelmed with the results it gives you, just take notice of the missing dlls it's complaining about.
Make sure your dll is referenced within your project and not outside of it in some other folder where you built it.
This fixed my problem - in general just make sure your dlls are on the same path as your executable.
I have a rather large legacy nmake (Win32) project that creates a static library from native C++ code. I need to use this library in a C#/.Net application. In the past after much effort I had been successful at wrapping the static library in a managed C++ library, which I am then able to reference in a C#/.Net application. However, after receiving updates from the developers of the nmake project, and having gone through an many upgrades on my own build machine in the meantime, it is no longer working.
I am however able to import the cpp and header files of the nmake project and build it to a Win32 static library in VS 2010, by setting all of the preprocessor constants in the build properties. I set the build configuration type to DLL, and then try to add a reference to the Win32 output in my C#/.Net application hoping to use P/Invoke down the road, and it fails with a message "A reference to MyLibrary could not be added."
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
If you want to directly reference the library, you'll need to build a C++/CLI project using your library, and make managed wrappers.
If you want to use P/Invoke (which is a separate concept), you can make exports with a C API, and call those directly via P/Invoke.
The two approaches are both valid, but completely different in terms of implementation (C++/CLI vs. C API wrappers) on the native side, as well as used differently (directly referenced for C++/CLI vs. P/Invoke via [DllImport]).
You can use SWIG to generate wrappers for your code. SWIG is a very powerful tool and worth taking the time learn. It creates wrappers for a number of languages including Python, C#, and Java so if you get it working with one language it is fairly easy to use in other languages as well. It will generate all the wrapper code for you, although you will probably need to do some work with type. You use swig to create a special DLL that SWIG generates code for and then used supplied C# code to access the DLL without needing to deal with managed C++ assemblies which can be a nightmare to deal with.
http://www.swig.org/Doc2.0/SWIGDocumentation.html
Edit: my explanation may not be that clear and the docs are pretty overwhelming, take a look at the "What is swig?" section here to get started:
http://www.swig.org/Doc2.0/SWIGDocumentation.html#Introduction_nn2
I have a .Net Com Dll is it possible to use this dll and create .OCX file in c++ or MFC. If yes what are all the steps which needs to be followed. If any sample code is availabe that would be a great help
You could expose the .NET assembly as COM object using the regasm.exe tool. You could use the [ComVisible(true)] to indicate that all classes should be visible by COM clients when registered. This assembly level attribute could also be set in the properties of the project in Visual Studio. You could also apply it only to some classes that need to be exported. Once the assembly registered as COM object you could instantiate any class from unmanaged clients as with any standard COM object.
There is nothing particularly special about an .ocx file, it is just a DLL. Microsoft came up with that filename extension back in the Visual Basic version 4 days to make it obvious to VB programmers that they had a DLL that contains controls. ActiveX controls as opposed to VBX controls from the 16-bit days.
If you made the .NET assembly [ComVisible] then you already have a COM server that's usable in other projects. Provided you registered it properly, .NET assemblies must be registered with Regasm.exe instead of Regsvr32.exe. Done automatically in a .NET project with the Project + Properties, Build tab, "Register for COM interop" option. And at installation time with a Setup and Deployment project. If you need a type library then use Regasm.exe with the /tlb and /codebase options. Or Tlbexp.exe
If this really needs to be a traditional .ocx, in other words have controls, then you can use a Winforms UserControl or your own class derived from a Winforms control. Winforms automatically implements the plumbing to make classes derived from the Control class function properly in an ActiveX host.
If you're wanting to use a .NET library in normal C++, there are ways, mostly involving COM Interop. Microsoft has a whole section of MDSN dedicated to COM Interop: http://msdn.microsoft.com/en-us/library/6bw51z5z%28v=VS.71%29.aspx.
If the .NET DLL supports COM Interop, use that.
Try using VC++'s #import directive to read the .NET DLL in as a COM object. When compiled, VC++ should output a .tlh file and a .thi file (header and implementation respectively) which will be automatically compiled into your project. But this may or may not work depending on the DLL's construction, dependencies, etc.
Look at creating your own COM Interop .NET wrapper library that marshals calls to the base .NET DLL.
I have a python project that calls a c++ wrapper dll that calls a c# com interop dll.
In my computer, with all frameworks and programs installed, my project runs very well.
But in a computer that just got formatted it doesn't.
I allready installed c++ 2008 redistribute and the c++ part is working but when I call a function from it (that will call the c# correspondent one), it gives an error.
I want to know what are the dll dependencies from both c++ and c# dll's to see what is missing :)
Looks like you need Dependency Walker.
Dependency Walker (a.k.a. depends.exe) works for both native DLLs and managed DLLs.
It is included in some Visual Studio versions, and can also be downloaded here.
I have the source code of a C# program. I want to create a DLL out of it which I want to use in C++.
Is it possible to create a native DLL in Visual Studio 2008 which can be used in C++?
native <-> .Net interop is one of my pet disciplines, which is why I needed this as straightforward and reliable as possible.
The result was that I made me an MSBuild task which I just need to drag into a project to allow me to export static methods from pretty much any .Net language. And since the whole marshalling infrastructure works for exports as well, you can do pretty much anything with it that you want (like passing native/managed objects as IUnknown).
The resulting assembly will look to the consuming process like a real DLL, which means you can't have it to scale up to 64bit automatically anymore.
However, since you do have native bits in your application, you already have this issue anyways. ;-)
When you do not specifiy the CPU target in your C# project, my task will emit a warning that it created a folder for all targets (x86,x64 and Itanium), and there you'll have *.dll and *.pdb for each platform.
If you want the program to be native, and not managed, you'll need to port it to C++, instead of using C#.
That being said, you can compile it in C# into a library, and use it from C++ by using C++/CLI. This just requires that you compile the files that use the C# library with the /clr flag. This provides C++ access to the .NET framework, and lets you use libraries made in C# directly from C++.
Alternatively, you can use .NET's COM interop to expose the C# class(es) as COM objects, and then use those from native C++.
It is possible in Visual Studio 2008, but you're not going to be able to write it using C#.
To create a native DLL, you'll have to write your code using one of the unmanaged C++ project types.
You can expose the DLL to COM. Have a look here for some examples.
yes you can.
you need to create second project.
the project must be unmanaged (like "visual c++"->class library).
the name of this procedure is "calling from unmanaged code to managed code".
good to read unmanaged to managed (codeproject)
you must be aware, that any computer that using your dll must have preinstalled DotNet and Visual C++ Redistributable Package