I have followed the steps here to create a COM DLL in Visual Studio 2008. My objective is to wrap an existing unmanaged C++ .lib.
Is there an easy way to implement the COM interface for the lib. Or do I just have to keep adding ATL simple objects which essentially wrap the objects in my library?
For example, I have added the simple ATL object, CMyObject to my COM library, am I to create wrapper code including function members etc in CMyObject that essentially wrap the behavior of MyObject contained in the unmanaged C++ library?
In order to expose your functionality to COM you'll need to perform two major steps:
introduce COM interfaces
implement those interfaces using functionality of code you already have
So yes, the scenario you described is the typical way to solve this problem.
Using ATL will simplify things a lot. However you have to take care of exceptions as well. Since your code is in C++ it can throw exceptions. COM doesn't allow propagating exceptions outside COM methods - if the client is not in C++ it will crash once exception is thrown from your code. So your wrapper layer needs to have try-catch for every method directly called from COM.
I think adding wrappers the way you describe is the best way to go. Given that parameter types for OLE will be different to the C++ parameters in many cases, e.g. BSTR rather than string or char*, some wrapping is required for COM. The only alternative is to have a non-COM DLL.
Related
I am trying to use the COM system for VCProjectEngine. It is pretty simple to use in C# but I am hitting a wall in native C++.
I am using the COM system and so far I was able to get a pointer to the VCProjectEngine interface using the CoCreateInstance function.
But now what should I do with this interface? I would like to access the VCProject interface to be able to add files to the project. I tried to go with LoadProject or CreateProject but it takes a IDispatch parameter not a VCProject one.
Can someone help me with that?
Calling COM interfaces from C++ can be done in a number of different ways:
"low-level" COM calls using CoCreateInstance and the IUnkown interface
ATL (Active-X Template Library) which provides a number of smart pointers and utility functions to make the job a lot easier. Use in conjuction with #import to generate wrapper classes for you.
For Windows Store Apps you should use C++/Cx or WRL (Windows Runtime C++ Template Library)
There are many good tutorials and code samples on MSDN.
I am working with C++/CLI for C Library. I explored in the net about it. I got several links about it.
Mixed mode C++/CLI performance considerations - best practices
I am developing a C++/CLI DLL which will wrap a C static library.
There was one suggestion that I really wanted to discuss here is "One should not mix up managed and unmanaged C++ code in wrapper". I don't understand meaning of it.
The managed DLL will, of course, contain managed C++ code and unmanaged C++ code.
The purpose of the wrapper is to translate calls from the static library to managed code DLL.
Please clear my doubts - I wanted comments on this.
If you have a regular C++ library (non-CLI), you should avoid turning on the 'CLI' compilation option for that library, for performance reasons.
Instead it is good practice to create a library that just has your wrapper classes in it. This library will of course be C++/CLI, and will create an assembly that can be referenced by regular .Net libraries.
So that's probably what the advice would be talking about - create a wrapper library for your CLI wrappers
-- addendum for the updated question
A managed C++/CLI class should not contain unmanaged code because it /cannot/ contain many types of unmanaged code.
For example, a C++/CLI class cannot have any unmanaged member variables that are not references or pointers. This is because the .Net runtime garbage collector may decide to put the object somewhere else in memory at any time (this is the reason you need to pin memory etc.). If the GC decides to move your native C++ objects to some other place in memory, this will potentially invalidate any pointers you have to that object. This is obviously bad.
C++/CLI is a great language. If you use it, however, you should either decide to write pure .Net code, or you should use it as an interface between native C++ and .Net. Having mixed memory models in the same class just confuses things.
I have an ATL COM service which I can connect to via my Windows Forms Application .NET4 application, written for the most part in managed c++.
I can successfully retrieve a pointer to the interface (via CoCreateInstance()), but run into issues when attempting to implement an event sink. I wish to create an unmanaged c++ class in the application which implements an interface defined by the COM server, and receive events from the ConnectionPoint. What I've got so far:
Realising this isn't possible using a managed (ref class) c++ class, I'm using a normal unmanaged class.
Not being able to use any ATL macros, I need to implement the IUnknown abstract functions (AddRef, Release, QueryInterface etc) in the sink class.
I can retrieve the IConnectionPoint pointer for the interface, but the call to Advise() returns E_NOTIMPL. This leads me to believe that i've missed implementing some ATL base functionality somewhere, but I'm not sure where to start.
As an aside, i've found very little resources on the net about using COM in a managed c++ project. The closest i've come to is this article. Does anybody have any good reading on this subject? It's mangling my brain at the moment.
In your managed C++ application add a reference to the COM server using "Add reference" option, this will create a managed wrapper (assembly) for your COM component which you will be able to consume in your "managed c++ code". The events in your COM component should be available as .NET events which can be handled using regular event handling in managed C++.
From your description it seems that you are trying to consume the COM component in your managed C++ application using unmanaged code, which is making things complicated. Mixing managed and unmanaged code should have clear boundaries and jumping too much in and out of these boundaries will make things complex and will lead to other serious issues. Hence I suggest you to consume the COM component using "managed code" (c++) only bu creating the managed wrapper for the COM component.
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 an unmanaged class that I'm trying to dllexport from a managed DLL file. I'm trying to use the unmanaged class in another managed DLL file. However, when I try to do this I get link errors.
I've done this lots of times with unmanaged DLL files, so I know how that works. I know how to use "public ref", etc. in managed classes.
Is there some flag somewhere I need to set? Or do I have to do some DllImport magic?
This is on .NET 2.0 and Visual Studio 2005.
If you want to use an unmanaged class from managed code, you can:
Use some nasty P/Invoke to load the class member functions (constructor, destructor, etc.) and make a nastier managed wrapper class to call the "real" member functions. This gets even worse when there are virtual methods involved.
The second option (which in my opinion is better) is to write a C++/CLI wrapper class (you mentioned that you're familiar with this) that is a simple proxy to the unmanaged class. For every member function you have in the unmanaged class you'll have a similar one in your proxy class. Then it's a simple case of adding a reference to that DLL from your managed project, and you'll be able to use your class as any other .NET class. Take into consideration that you'll run into more work if your class exposes other unmanaged stuff (those that can't be marshalled).
If you need more information on the second option, I could look up some old links that explained this technique more.
You need to use an interop assembly for unmanaged libraries or COM components. Here is a link with good information regarding this.
If it is a COM DLL file then you can use COM .NET interoperability. Stack Overflow question Is there a best practice for accessing C++ native COM functions to interop from C#? is another question which answers this.