I have to use a DLL in my project that is a .NET assembly. I have to use C++ for this project. I'm a relative beginner to programming, so my knowledge doesn't extend too far. I was told COM Interop is one way to get the DLL to work in my project (the other being C++/CLI). The problem is I have ZERO idea how to begin, as I've never done anything like this before, and the Microsoft documentation on the matter isn't really helping.
If anyone can even point me in the right direction, that would be much obliged.
Here are some good resources to get you started:
Introduction to COM
COM from Scratch (Covers using COM from C++)
MSDN's section on COM
That being said, you'll also need to make sure that your .NET project is setup to expose the classes via COM. Make sure to turn on Register For COM Interop in your project settings, and flag appropriate types with [ComVisible(true)] (Unless you make the entire assembly ComVisible, in which case you would flag types you don't want to expose with [ComVisible(false)])
Related
One of our products is a C++ application - using MFC (MDI). (And we skin the application with Codejock.)
I've been asked if we could "port the application to .NET" - so it would be possible to use, e.g., C# libraries and other .NET features. I know there is something called "C++.NET" - or maybe (if I understand it right) it should be called "managed C++" now. But I don't know much about it.
My question: Is this at all possible? Could we run an MFC-application as "managed C++"? (And can an application using Codejock be run as a "managed C++" application?) There is some other threads about this, but I haven't been able to find "a definitive answer"...
I'd be very grateful for some good advice! :-)
As far as I understand, you want to keep your MFC/Codejock GUI and allow the use of .NET libraries from you application's C++ code.
This is indeed possible, but for a complete application that is currently compiled as "native" C++ it is probably not such a good idea to convert all of it to being compiled with C++/CLI. "It Just Works (IJW)" is a nice meme, but it doesn't work always :-)
We have the same situation, namely a C++/MFC/Codejock application that needs to call into .NET assemblies. This works mostly without problems:
We have C++/CLI modules that offer a native C++ DLL interface for the native C++ code to call into and that then route these call on to an assembly written in C#.
We also have C++/CLI assemblies that offer a .NET interface for the C# code and then call back into pure native modules.
It should also be possible to have a single (say, exe) project that is compiled natively and you only enable the /clr switch for selected cpp files that need managed interop. And at the end you link everything together. Since we've never mixed it that way, I can't really say anything about this approach however. What I can say for sure though is that it is possible to compile parts on a module as /clr and parts as native.
I faced a similar problem some years ago, and found that unless for trivial cases converting from un-managed to managed or reverse side was really painfull. I ended leaving the two worlds each in its side, and simply use interop to have the COM - .NET compatibility.
It was not very nice, but a lot cheaper. The conclusion that we should wait a major evolution to consider a full rewriting.
I am still a bit new to Windows programming and sometimes find the documentation and tutorials I find confusing and sometimes contradictory but I hope I can make some sense and be corrected on any points I am mistaken about.
I am using an API where the documentation included is quite poor. It is made up of a number of DLLs that they envisioned would be added as a reference to VB projects (most of the users are biologists/chemists and are not very familiar with other languages, so they recommend VB). I thought they were .NET dlls at first but they cannot be registered with regasm and a tlb cannot be generated using this but can be registered with regsvr32, so I guess that means they are COM dlls...please correct me if I am wrong.
My understanding is that as this exposes the COM objects that I should be able to use this with .NET languages and unmanged c++. I have used it in C# but I would also like to use this in unmanged c++. I have seen tutorials like this:
http://cppkid.wordpress.com/2009/01/...nmanaged-code/
That import the type library but I do not have this, it was not supplied with the API. However using OLE viewer I was able to see that they were available (embedded in the dll?). I was wondering if anyone knows how I can go from this to actually using the dll in c++.
Cheers and thanks for any help.
I guess the easiest way to achive this would be to use the #import directive:
#import <mygreatlib.dll>
There are other ways though, like using #import with the ProgID of the entry point class of your dll, or using the MFC type library wizard
I currently have an old unmanaged C++ DLL using MFC. This DLL has a bunch of code which is multi-threaded and written back in 2003 using VC6. This code sadly doesn't work anymore.
I've been tasked with finding an alternative way of running this multi-threaded code so that it does function as intended. Someone before me had already rewritten it in C#, and I need to port that C# code over to VC++. I did some research and realized that I could save some time in the porting process by just porting the C# code to VC++ (using the .NET framework). But then I realized that my old MFC DLL cannot run this .NET code.
My idea is to write this multi-threaded code in a VC++ DLL (using the .NET framework) and using some form of interoperability to be able to call the functions from the old DLL to the new DLL.
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this? Are there any tutorials that could help me with this task? (I've already done some extensive searching and there are a lot of tutorials using unmanaged C++ DLLs to C# DLLs, but not much that pertains to my situtation).
Just so you know, I cannot compile the old DLL with /clr as this DLL is hosted in an old Win32 application as well. Compiling with /clr causes the application to crash, or else this would have already been done.
TO CLARIFY: I'm curious as to why calling functions residing in a C# DLL from an unmanaged C++ DLL through a COM interop seems so simple compared to doing the exact same thing using a managed C++ DLL. I even have a proof-of-concept between C# and C++, but I can't for the life of me begin to understand performing the exact same task with C++. Does there happen to be just a simple tutorial for calling just one simple (let's say 'Add') function from unmanaged C++ to managed C++?
If you have a (managed) DLL, regardless of the language(s) it is written in, you need a process to run it in. If you have a native process that -- for whatever reason -- must not use the CLR, that you cannot directly use a managed DLL (any code that depends on the CLR in-process) from this process directly.
You would need a second helper process that runs the managed DLL and, for example, exposes a COM interface that the native process could call. (out of process COM server)
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this?
Not sure what you mean with wrapper classes, but an out of process COM server for your managed DLL could do the trick. (Obviously, this is quite some overhand wrt. to managing the proper registration and startup/shutdown of the helper process.)
Breaking the problem up a bit (as far as I understand):
[oldish Win32 app (no! CLR)]
<- normal DLL interface -> [native/MFC DLL (no! CLR)]
<- via COM -> [stuff in a separate executable]
If this is what you are looking for, then this article (just a quick Google hit) may be helpful:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
For COM in general, I think any COM tutorial should cover what you are supposedly trying to do.
To better myself I am attempting to make my dll's COM compliant, I thought I'd just need to extend/implement a few interfaces and job done but now I am at a cross roads,
1) Should I learn MIDL?
2) Should I install the ATL (I am running VC++Express)?
3) Carry on reading the C++ tutorials (http://progtutorials.tripod.com/COM.htm) and hope my Express edition is too limited?
I was interested in transferring native C++ to Android and Java and read that the libraries would need to expose either static 'C' style functions or implement COM.
Android is Linux based operating system... It does not support DLLs and COM.
So no you can't go via COM. You need to learn how to use JNI.
1) Yes. If you are going to define new interfaces, you pretty much have to. It's not impossible to do without MIDL, but it's way harder than to learn basic MIDL.
2) Yes, please do. It'll hide much of the boiler plate code (which is tedious to write, and error prone).
3) I would recommend the book Essential COM by Don Box. It's awesome. Also, a great companion to that book is Essential IDL by Martin Gudgin.
As for VC++ Express - I have never used them. I guess it's possible to do COM with it, but with limited tool/library support.
What's the best way to do this....?
I have some Native C++ code that uses a lot of Win32 calls together with byte buffers (allocated using HeapAlloc). I'd like to extend the code and make a C# GUI...and maybe later use a basic Win32 GUI (for use where there is no .Net and limited MFC support).
(A) I could just re-write the code in C# and use multiple PINVOKEs....but even with the PINVOKES in a separate class, the code looks messy with all the marshaling. I'm also re-writing a lot of code.
(B) I could create a native C++ DLL and use PINVOKE to marshal in the native data structures. I'm assuming I can include the native C++ DLL/LIB in a project using C#?
(C) Create a mixed mode DLL (Native C++ class plus managed ref class). I'm assuming that this would make it easier to use the managed ref class in C#......but is this the case? Will the managed class handle all the marshaling? Can I use this mixed mode DLL on a platform with no .Net (i.e. still access the native C++ unmanaged component) or do I limit myself to .Net only platforms.
One thing that bothers me about each of these options is all the marshalling. Is it better to create a managed data structure (array, string etc.) and pass that to the native C++ class, or, the other way around?
Any ideas on what would be considered best practice...?
UPDATE:
I know I can re-write the native C++ code from scratch, but it means duplicating the code and prevents me from easily reusing any code updates with any Win32 application. What concerns me most is the best way to marshal the various data between the managed and unmanaged world. To me, a mixed mode DLL looks like the most flxible option, but I'd like to get a different perspective on the potential pitfalls.
Why not just use .NET directly? It seems to me like your problem arises from the fact that you are dependent on the original native library, but you don't mention that it can't simply be re-done in .NET.
As for .NET-native interop, PInvoke is messy, but it does work. I'd go with that if you can't change the original DLL into .NET.
Option C gives you the least work if the marshaling turns out to be simple and easy for the framework to handle (is everything blittable?). It also gives you a place to hook in your own marshaling. I wrote something about this ages ago marshaling between date types etc but I think today I would write a marshal_as<> overload between your managed and native types. It would be the most elegant solution and also the least code.
Update: found my old article - it was for PInvoke. http://codeguru.earthweb.com/columns/kate/article.php/c4867/