I am using a COM DLL in VB.NET. I want to list out the classes in COM DLL implementing a specific Interface.
How can read the types which implements a specific Interface from .NET???
Related
How does one expose a System.Data class in a COM Wrapper? I have followed the tutorial here: https://www.codeproject.com/Articles/7587/Exposing-COM-interfaces-of-a-NET-class-library-for. Which works beautify to allow a VB6 program to access .NET only DLLs, but I want to pass a System.Data.DataRow to the VB6 program for manipulation. The ``DataRow class isn't being exposed to COM and shows up as an Unknown data type in the references. Is there a way to expose/implement/extend a DataRow to be visible to a COM program?
Is there a smart way to scaffold a COM callable .NET class library from an existing native COM DLL?
Scenario
Suppose you have a COM based C++ Win32 application and you want to replace one of the COM DLLs with something written from scratch.
Constraints
The new library shall be written in C#, targeting the .NET Framework (4.x)
No modifications to the rest of the existing unmanaged application shall be required.
No recompilation of the unmanaged code shall be required.
What I already know
You can create .NET assemblies which are COM callable.
You can import the type library IDL from an existing COM DLL.
Based on this question, what I want should be possible, even if arduous.
Question
Is there a smart / efficient way to generate the scaffolding code for a COM callable .NET class library with the exact same signature as an existing unmanaged COM DLL so I can replace the DLLs?
There does not need to be any implementation at first, every method could just throw a NotImplementedException for example.
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 several ATL COM services and would like each of them to have their own namespace, but be under a single base namespace, just like the System namespace in .NET.
For example if a C# project were to include these COM objects, all would be under the same base namespace:
using MyCompanyName.Terminator;
using MyCompanyName.Superman;
using MyCompanyName.Thor;
... instead, what I have currently is this:
using Terminator;
using Superman;
using Thor;
... which is what I do NOT want. I want to be able have a base namespace and sub-namespaces under that base. I don't know how to do this when creating an ATL service and what I need to modify to do this. Is it something I modify in the IDL file?
In case you are targeting managed clients it is possible to provide namespaces for them! However since COM is language independent you cannot provide namespaces using the interface description (type library). But whenever you are creating managed wrapper assemblies (that are actually referenced by the client), they can have namespaces to address the RCW objects. The keyword you are looking for is Primary Interop Assemblies. Those are assemblies that you as the vendor of the original library provide for clients to reference. To simplify this: You are doing the work, Visual Studio does for you when you are adding a reference to a COM library. You are creating the interop assembly and the customer does not reference the type library, but the assembly you generated. Using the tlbimp.exe tool it is possible to encapsulate the RCW types inside a namespace using the /namespace parameter.
i was looking for some COM, .NET interoperability topics, and i came across a few legacy COM examples using c++, to round it up, i understood that u define every interface and coclass inside and idl (interface definition file) so other com aware languages can understand type information, but the only com class not defined in an idl file is the one derived from IClassFactory, can some one please tell why since other .NET languages need also to obtain a class factory to instintiate other com classes, so how can they understand the type information ??
Class factories are rarely used directly. In fact, if you needed to create a class factory first to create any COM object, how would you create the class factory itself?
COM library takes care of creating objects. E.g., if COM server is a DLL, it is required to export DllGetClassObject function. When a client wants to create a COM object, it calls CoCreateInstance specifying a CLSID. Using CLSID, COM library finds the server and (if it's a DLL) loads it and calls its DllGetClassObject.
This is just a couple of words on the topic. COM is a very big topic; you might have to start at the very beginning if you want to have complete understanding...