Is there any way I can reference and use classes and methods from a managed .net assembly from within a totally unmanaged C++ application? (no /clr)
Absolutely, and this gem from CodeProject should prove helpful
You need a CCW (COM callable wrapper).
You can - by hosting the CLR. I found one set of example code here . I have no way of knowing how good the advice there is though, as I've never done it.
You can expose the .NET class thru COM and consume the classes thru COM.
Related
Has anybody tried to use C++/winrt to create Win32 COM objects? The C++/winrt docs document that consuming them is possible and of course creating "new" UWP COM objects. I was wondering if for some simple scenario's one could use the C++/winrt headers instead of ATL to generate some simple COM objects.
You can write a COM component with C++/WinRT. Here’s an example of a COM executable server but the principles and techniques are much the same for a DLL.
https://gist.github.com/kennykerr/d983767262118ae0366ef1ec282e428a
For a DLL you just want to make sure you export an implementation of DllGetClassObject and DllCanUnloadNow. Otherwise, its just like any other DLL and you can use the winrt::implements class template to implement the various classes and factories.
I have followed the example here: http://msdn.microsoft.com/en-us/library/vstudio/jj822931.aspx to create an In-proc Classic COM DLL using Windows Runtime Template Library (WRL). I am also able to modify to code to run the DLL as COM surrogate (wrapped inside DllHost.exe).
However, I couldn't find the way to create an out-of-process COM EXE using the WRL. There is a simple example using barebone COM API here: http://www.codeproject.com/Articles/3173/A-simple-yet-debuggable-COM-skeleton-code, but I'd like to know how I can utilize WRL to simplify that.
Thanks.
Yes it is possible. I just got one working. Here's the basics that are required, as compared to implementing an in-proc coclass.
Implement your coclass using WRL::RuntimeClass the same way you would for an in-proc class. (https://msdn.microsoft.com/en-us/library/jj822931.aspx)
In your main function, create a module object using WRL::Module<OutOfProc>::Create(), and call module.RegisterObjects() on startup, and module.UnregisterObjects() and module.Terminate() on shutdown.
You need to build a DLL to host the proxies: https://msdn.microsoft.com/en-us/library/windows/desktop/ms688707(v=vs.85).aspx
Static Registrations: DO register the Interface and the CLSID of your proxy stub. DO NOT statically register your coclass.
In the Client, when you call CoCreateInstance, be sure to use the appropriate CLSCTX. (I use CLSCTX_ALL when the hosting model is not important to the client.)
(I know it's been almost 4 years, but I had the same question this week.)
I have found out that it is essential to derive my base MFC class from CWinApp and use AFX_MANAGE_STATE(AfxGetStaticModuleState()) for every exported method! (if MFC is dyn. linked)
I would like also using an pointer to external native C++ object in MFC dll constr (I should use extension dll - but how work this with CLI???)
Have someone a good example for doing this kind of wrapping ?!
Thanks and greets,
leon22
I'm not sure what your question or your problem is. You don't always need to use the AFX_MANAGE_STATE macro, it depends on the circumstances. What's a 'MFC dll constr' ? What does 'I should use extension dll' mean? (I know what an extension dll is, but what do you mean by 'should' in this context?) What does 'this kind of wrapping' mean?
I need to use a COM object in my .NET 2.0 compact framework project, but I can't use the CreateObject function. Is there any other way to call a COM object that will work in my environment?
You'll need to call CoCreateInstance(). You can find a P/Invoke declaration for it here. If you only have a ProgID then you need to call CLSIDFromProgID() first. Make sure you've exhausted all possibilities of finding a type library for the COM server (Tlbimp.exe), this kind of code isn't easy to get right.
We know that .NET framework class encapsulate the Win32 API, now I am wondering how the .NET framework class call Win32 API?
Ways I know so far:
Through P/Invoke
VC++/CLI
Both 1 and 2
Anybody know the answer?
Most framework classes use P/Invoke if they need to call unmanaged APIs. Fire up Reflector on System.Windows.Forms and you'll see classes called NativeMethods and UnsafeNativeMethods which do a lot of P/Invoke. Similarly System.Drawing has a SafeNativeMethods class which declares all the GDI+ P/Invokes.
The other main interop method you don't mention is COM interop. I don't know how widely this is used within the framework, but I'd guess that some of the WMI (System.Management) stuff uses it pretty heavily, plus of course WinForms ActiveX support.