Hi we have a c++ project (library) which has to exposed to .net languages or may be other languages (old vb for example but this is not very important). Two options are write COM wrapper for the project or managed c++ wrapper. Which one to choose?
One great advantage, for example, of using manged c++ is using .net collections classes to pass as a parameters instead of enormous complexity of collections in COM.
The term "COM wrapper" doesn't make much sense. If want to create a COM class, there's no reason why you should first create a vanilla C++ class and then create a COM class that wraps it and mimics it. That's one advantage of COM over managed C++: in managed C++, you DO have to create a vanilla C++ class (for unmanaged clients, unless you don't have any) and a managed wrapper class for it (for managed clients).
In my opinion, the deciding factors for when you should use COM or managed C++ for interop are easy:
Use COM if you want to create a completely new unmanaged class (not a wrapper) that can be consumed by clients in any language.
Use managed C++ if want to create a completely new class (not a wrapper) in which you mix a lot of managed and unmanaged code.
So you see, the word "wrapper" shouldn't come up anywhere in your design. Wrappers suck :)
If you're COM collections are enormously complex, you may want to rethink how you approach COM collection management. Totally different issue there, but that being said...
Your mention of old-VB not being very important is more critical to your answer than you may think. Old VB doesn't speak .NET, but it does speak COM very well. If you foresee having to go that road, that is a major push to the COM side.
I'm not a fan-per'se of managed C++ only because it is about the most non-portable, hard-to-manage, hard to read dialect of the language you'll likely ever encounter. However, if the core code in your library is simple enough, you could probably get it up and running in managed C++ with reasonable effort. The more dynamic the library is, the harder it will be to port to .NET management. However...
Once it is there, a COM wrapper can get you back to your COM clients like legacy VB without too many problems provided you took wise choices when doing the port and kept things easily wrappable along the way.
Thats about the most round-about way I can say (with great pain) managed C++ is likely your best option, but I would seriously gel on it before throwing down that gauntlet.
Related
I'm working on a fairly large project written primarily in C++ using MFC. We are tasked to gradually port this application to use Qt. Years ago, a wrapper around much of our functionality was written using COM. I feel using the COM wrapper from the new Qt code will help isolate code that would force dependencies on MFC. Unfortunately, we're also being asked to ween our use of COM/ActiveX. So, introducing new consumers of our COM wrapper in Qt isn't ideal. Visual Studio has a class wizard that will generate a C++ class based on an interface in a TLB file, but it's dependent on MFC and the interface still exposes COM (LPDISPATCH, SAFEARRAY*, etc).
With all that said, does anyone know of a tool (free or commercial) that will take a Microsoft IDL file and convert it to C++, who's interfaces aren't dependent on MFC nor COM?
and working with the code generated by midl.exe
That's hang-up number one. Midl.exe does not generate code, it only generates declarations. Pure virtual classes in C++, only method declarations with no implementations. Either to a .h file or to a .tlb type library file. The type library is handy because it is easy to read by tooling, having a restricted sub-set of COM called Automation. And implemented by just about any language runtime on Windows.
Key point is that these are just declarations, the glue that makes code written in different modules and/or different languages or class libraries work together. Very important in large projects, interfaces tie the pieces together.
Our system architect learned of our approach and advised that we find a way to not add these COM-specifics to our new Qt projects.
That's singularly unhelpful advice. "Don't do that" is something my doctor tells me when it hurts to put my arm behind my back. I can live with that, I have a good alternative and can just turn around. In your case I would have to demand more from the architect. He's messing with the body parts, he's separating the torso from the legs and head and feet and hands. Brain utterly disjointed. The very glue that makes the different chunks of code you have now work together. Break that interface and you'll seriously break your app, Netscape style.
Beware of the astronaut architect (another Spolsky favorite) that's happy to force you into something that he understands but doesn't have to implement. Demand a reasonable alternative, an architectural approach since breaking the interfaces has a deep architectural impact on your app. Those MFC classes that everybody implemented from the interfaces are pretty much junk when you change the interface. Rewriting them all into Q classes is going to seriously keep you unproductive for a while. And is devastatingly boring code to write. Only to produce the same thing, with more bugs. Things You Should Never Do, part 2.
If you are able to keep using Visual C++, a solution would be to use the plain compiler support for COM.
You need to #import your TLB file
http://msdn.microsoft.com/en-us/library/8etzzkb6%28v=vs.100%29.aspx
Then you can make use of the COM compiler support to handle the COM object instances,
http://msdn.microsoft.com/en-us/library/h31ekh7e.aspx
I have a library written in standard C++. I also have a .Net windows form app written in C# that utilizes the unmanaged library.
I understand I can just use pinvoke, but my C++ is completely OO and I really wouldn't want to mess around with marshaling and such.
Is there a way that I can just create a new managed C++ dll project, copy and paste my header and code files, and compile it and have access to all the classes?
Or would I have to create some ref class in managed c++ and hook it up to my unmanaged class? I just want this to be as simple as possible.
Thanks!
You would still have to write specific .NET wrappers even in C++/CLI, they just look different. So the answer to, can you put it in a C++/CLI project and recompile and use it as is, is no. You still have to either marshal the data over (in which case you may as well use p/Invoke probably) or you can create handles and use pinned memory to make your structures available to managed code.
I've done this both ways: I've written a GPU library in CUDA C and called it from F# using p/Invoke and I've written a video processing library in C++ and written a thin C++/CLI wrapper then used it in a .NET app. I think the CLI wrapper was more painful, but for live video I needed less latency (less copying memory). For the GPU project I was more concerned with throughput.
You are probably going to want to write the wrapper classes in C++/CLI. It's fairly trivial to do, as long as you return handles instead of pointers, enumerators instead of collections, etc.
I'm currently working on a project in .NET that communicates with native C++ libraries through the use of a C++/CLI project. However, moving forward with this project, I would like to be able to expose specific modules of the native C++ code, preferably with as little extra implementation as possible, while maintaining re-usability and scalability.
I've done some research into both uses, but cannot work out which would be better for solving this purpose. Could someone explain which approach is best suited to this scenario, if any?
If you want to wrap native C++ code for .NET, use C++/CLI. For simple C-style API it is possible to use PInvoke.
If you want to wrap native C++ code both for .NET and COM clients (like Internet Explorer, MS Office, scripting languages etc.), use COM.
To my opinion, writing COM wrapper is more complicated task. But COM guru can have another opinion - it depends on your experience in these technologies.
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/
I have a pre-existing c++ object model which represents the business layer tier of an application. I want to be able to expose the object model to applications written in other languages i.e vbscript, VB, javascript etc. I believe the best way of doing this is to wrap the business objects with a COM layer.
What fast and effective methods are there for doing this. Any advice, links to practical "How to" documentation would be very much appreciated.
Because I'm starting a bounty on this , here's a few extra guidelines for potential bounty hunters :-
1)I've decided on an ATL approach
2)I'm now specifically looking for links to really good "how to and quickly" documentation on wrapping a pre-existing c++ object model to make it useable by a scripting language like javascript
3) Something with small working examples showing me what code needs to be added to what files, e.g what goes into the cpp , idl and hpp/h etc. It' must include an example I can compile test and change to get a better understanding.
Addendum .....
Further context. For me this is a re-visit to COM after about 10 years. I did MFC and ATL COM for the 3 years prior to 2000. I understand what COM is , the principles used to implement it in C++, threading models etc. Any "how to and quickly" documentation will not be leading me blindly and glazing over important principles, more it'll be a guided re-learning experience.
If I had more time I'd dig into "developer's workshop to COM and ATL 3.0" by Troelsen, a very good book but it's a very slow kick (re)start.
Further context following comments...........
Keeping it as simple as possible , Single-Threaded Apartment model and an inprocess dll.
I find a good collection of articles for beginner in http://www.codeproject.com/KB/COM/index.aspx?#COM/DCOM/COM+%20-%20Beginners. This are:
http://www.codeproject.com/KB/COM/hellocom.aspx, http://www.codeproject.com/KB/COM/comintro2.aspx,
http://www.codeproject.com/KB/COM/comintro.aspx, http://www.codeproject.com/KB/COM/com_server_without_mfc_atl.aspx, http://www.codeproject.com/KB/COM/com_in_c1.aspx
But if you start to program a COM objects it's very important to understand threading models of COM. This is explain very good here
http://www.codeproject.com/KB/COM/CCOMThread.aspx, http://www.codeproject.com/KB/COM/CCOMThread2.aspx
But I decide to answer you because I want suggest to choose a little other modern way. COM technology is very old. Dot NET has all the features inside and will permanently developed. So I find an approach from Building COM Servers in .NET the most interesting. You write your COM full in C# divide the development of your COM objects in two parts:
You write interface only assembly without any implementation and register it.
You develop a .NET classes which implements this COM interface.
You can look at the more easy version of the same in http://www.codeproject.com/KB/COM/COMinDotNet.aspx, http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx, http://msdn.microsoft.com/en-us/library/ms973807.aspx, but I recommend you the way "Building COM Servers in .NET" described in http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx.
UPDATED after the comment: Sorry, but you are searching an easy way to solve a complex problem. It is impossible.
It is very important to understand, that despite of quasi similarity there are a lot of principal differences between object oriented C++ and COM. It’s important to understand, that COM isn't an object-oriented language but a binary protocol. A software component (COM objects) is a binary unit of reusable code. It solves a lot of problems existing in separate compilation of modules of programs designed based on object-oriented approach.
If, for example, somebody inherited you classes and you change later some private members, it makes influence to the all inherited classes. The full code used your C++ objects must be recompiled at least because sizeof(object) has been changed. Such problem not exists in COM, because all who use your objects don’t inherit your object classes. One uses your objects through interfaces, which signature and sizeof() will not be changed after you modify some private members of your base classes. You can read online some very good examples in the first chapter of the classic book "Essential COM" by Don Box: http://books.google.co.uk/books?id=kfRWvKSePmAC&dq=essential+com&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=6&ct=result. I recommend you also to read a small article http://edndoc.esri.com/arcobjects/9.0/ArcGISDevHelp/DevelopmentEnvs/COM/IntroToCOM.htm to understand more differences between COM and C++ objects.
If you rewrite your C++ objects as a COM objects you have to choose threading model, you have to understand how to write a thread safe program or you have to use Single-Threaded Apartment model. All your objects will be exist (allocated and running) in a separate thread. If you choose Out-Of-Process COM object (an exe with all your objects will be created), then a new process will be created. If somebody calls a method of your object a marshaling of all parameters will be done. Marshaling of parameters means allocation of memory in another thread and copying of all parameter to the thread.
All this things which I described before are not a terms of C++ objects. I write this only to clear that COM really not the same as C++ object model.
So to wrap your existing C++ objects you have to define some pure virtual classes – interfaces which you implement in your objects. This interface must be in written in IDL/MIDL (Microsoft Interface Definition Language). This is the most important thing! Then you have to implement these interfaces as COM coclasses using your existing C++ classes.
I am sure if you do these work in .NET you have not be required to study a lot of implementation details typically needed to know for COM developer. You just define an Interface in C#/C++ (a pure virtual class) and compile it. You can generate a private key for strong signed assembly inside of Visual Studio. Just go in the project settings in "Signing" part and select "Sign the assembly" then choose "New" strong name key file. It’s all. With this way you full define a COM interface. A MIDL version of the interface will be generated for you.
Then you create a new project in C# or C++ and declare classes which inherit the interface which you define before. During implementing of this interface you can use your entire existing C++ object. So you will be able quickly rich your targets. Just follow the way described in details in http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx. With this way you will not have to study a lot of technical details which you have to know for classical COM implementation in C++. And you will study a modern .NET instead of studying the old and de facto dead (or not further developed) COM.
Sorry for the long answer.
http://www.lambdasoft.dk/Comet/index.htm
Comet is language binding between COM and C++. It allows you to do both COM client and COM server programming, without any dependency on either ATL or MFC. In other words Comet is a replacement for ATL.