I have a com dll written in vb6. I need to write c# code that wil get me a list of all the classes within it.
My Objective is to get the classes and generate the classes in .net with all the properties and create a mapping class.
I just need to get a list of classes from the dll.
Summary:
How can I get a list of all the classes in my com dll?
I would suggest using TLBINF32.dll. It is a COM component that ships with most versions of Windows. Make sure it is registered using regsvr32.exe from an elevated command prompt (along with your COM dll). Reference it in your .NET app (compiled to x86) and use the TLIApplication.TypeLibInfoFromFile method. From there you can traverse the type library of the COM component and get the classes, methods, interfaces, and properties exposed.
We use this library for various utilities.
Using reflection to walk the Interop for your COM DLL will give you classes and interfaces that a vaguely analogous to COM CoClasses and interfaces.
If quick and easy is what you're after, add your COM DLL as a reference in Visual Studio and use the code below to walk through the Interop assembly looking for classes. If it's a VB6 COM DLL everything is going to be IDispatch anyway, but you could optionally filter on objects with a CoClass, Guid or InterfaceType attributes on the types identified below (you didn't specify whether you were after classes or CoClasses).
var classes = Assembly.GetAssembly(typeof(MyComDLL.RandomTypeFromWithin))
.GetTypes()
.Where(type => type.IsClass);
If you're trying to really do this properly, the articles Dennis linked to in his comment are better, as is p/Invoke'ing LoadTypeLib and walking ITypeLib (the latter option being non-trivial).
Related
I am trying to create COM wrapper class for a COM library. I first used MIDL to compile the .IDL into .TLB, then used TlbImp to generate a managed wrapper assembly. However, I found some of the interfaces are not included in the managed wrapper, the reason is they are not mentioned in the 'library' section.
Is there any way to let the final managed wrapper assembly include all the interfaces instead of changing the .IDL and manually writing all interfaces inside 'library'?
I have a c# com visible dll and I want to call this dll in vb6 project, which also generates a dll.I am not using regasm.exe to do this call, instead of that I am using manifest generation for the c# dll and then creating its tlb and calling it from vb6.
I have created two interfaces in c# dll one is Itest and another is Itest2,made both interfaces comvisible and added Guid to both interfaces,there are two classes named testimp and classimp which implement both the interfaces respectivly.These both classes are comvisible, Classinterface type as none and have their respective GUID.
The problem is that I am able to instantiate only testimp class from my vb6 project not classimp class.
COM registrations are usually referenced from the TLB GUID - which is to be registered in the registry
How to register a legacy typelib (.tlb) on Windows 7?
Note that on Windows Vista and up (IIRC) it's also possibly to deploy with application-local COM registrations in a .manifest file:
Registration free COM Interop
If your problem is per user install, use Regasm to create a regfile, then edit the regfile to change references to HKCR to HKCU\Software\Classes.
I am trying to implement a COM interface in my C# dll for others to consume. I have defined an interface in foo.idl.
I've run foo.idl through tlbimp to produce foo.dll, a .Net assembly. Now to implement my interface, I can reference foo.dll in my dll to implement the interface.
This works perfectly as it stands with one exception: I now have to distribute two dlls instead of one. This actually goes against the requirements of the project I'm working on: deliver one DLL.
Is there a way to merge the tlbimp dll into mine, or any other way to do this (implement a COM interface in C# without the second dll)?
A good disassembler gets the job done, like Reflector. You can simply disassemble the interop assembly and copy the generated C# interface declarations into your source code. Of course you should only do this if the interface declarations and IIDs are stable.
And definitely consider upgrading to VS2010. Its "embed interop types" feature allows you to ship your assembly without the interop assembly.
You could probably cheat by using a .tlb instead of the 'glue' dll.
I'd suggest you create a mixed-mode assembly using MSVC++/CLR
http://msdn.microsoft.com/en-us/library/k8d11d4s(v=vs.100).aspx
Interop (How Do I in Visual C++)
This might have the drawback that you can't use C# in the same assembly. Should you want to add C# code to the mix, you might be able to squeeze out of your tough situation using
IlMerge
For other, possibly interesting, thoughts see my earlier answer:
Is it possible to compile a console application into a single .dll file?
I got an desktop application which uses a small DLL written in C# registered as an COM object to collect some infos from Active Directory. The app is written in C++, it works fine. I would like to write a small app in C# which would call the same registered DLL's methods (kind of testing tool), but can't figure out how to do this without referencing the COM DLL at compile time (I really need to use the COM registered dll)
I followed this article, managed to instantiate the object, but i cannot cast the instance to my interface created from IDL. Also the debugger knows the exact type of the instance with all members shown. I suspect this is due the DLL is loaded in the CLR as well.
Is this even possible?
thanks
You can't. The IDE will refuse to let you add a reference to the type library. You can fool it by using late binding. But that still doesn't fool the CLR, it won't create both a CCW and an RCW. You'll need a native client, like C++ or a scripting language to truly exercise the COM specific path.
There's just no point, just use the assembly reference directly and use normal C# code to test it.
You can consume a COM component from a C# project. The general steps are as follows:
Locate a COM component to use and register it. Use regsvr32.exe to register or un–register a COM DLL.
Add to the project a reference to the COM component or type library.
When you add the reference, Visual Studio uses the Tlbimp.exe (Type Library Importer), which takes a type library as input, to output a .NET Framework interop assembly. The assembly, also named a runtime callable wrapper (RCW), contains managed classes and interfaces that wrap the COM classes and interfaces that are in the type library. Visual Studio adds to the project a reference to the generated assembly.
Create an instance of a class that is defined in the RCW. This, in turn, creates an instance of the COM object.
Use the object just as you use other managed objects. When the object is reclaimed by garbage collection, the instance of the COM object is also released from memory.
For more information, see Exposing COM Components to the .NET Framework.
Detailed Article
I would suggest you use the .NET 4.0 dynamic type instead of all the mess of dealing with reflection in that article you mentioned
Pretty much what it says on the tin. I've tried googling around but can't find anything helpful.
I'm trying to automate a process and part of that involves running forms/VBA code from an access 2003 database. What's the best way to call these from C#?
The Primary Interop Assemblies let you to automate Access 2003 from your C# application. In particular, you should be able to use commands like DoCmd.OpenForm and DoCmd.RunCode, allowing you to run your Access 2003 forms and VBA code.
Create the VBA code in a separate COM dll, and then you can use COM interop to call from C#
For instance, see SO question: Using a COM dll from C# without a type library.
Exposing COM Components to C#
You can consume a COM component from a
C# project. The general steps are as
follows:
Locate a COM component to use and register it. Use regsvr32.exe to
register or un–register a COM DLL.
Add to the project a reference to the COM component or type library.
When you add the reference, Visual
Studio uses the Type Library Importer
(Tlbimp.exe), which takes a type
library as input, to output a .NET
Framework interop assembly. The
assembly, also named a runtime
callable wrapper (RCW), contains
managed classes and interfaces that
wrap the COM classes and interfaces
that are in the type library. Visual
Studio adds to the project a reference
to the generated assembly.
Create an instance of a class that is defined in the RCW. This, in turn,
creates an instance of the COM object.
Use the object just as you use other managed objects. When the object
is reclaimed by garbage collection,
the instance of the COM object is also
released from memory.