Link to home
Start Free TrialLog in
Avatar of Lawrence Avery
Lawrence AveryFlag for United States of America

asked on

How to tell if a DLL is a COM DLL or a FLAT DLL?

How can you tell if a particular DLL is a COM DLL or a NON COM DLL? Is there a tool to analyze each one? I know by using the ILDASM tool  you can tell the difference between a .NET DLL versus
 a non -.NET DLL?
Avatar of Jacques Bourgeois (James Burger)
Jacques Bourgeois (James Burger)
Flag of Canada image

Unless you have a standalone dll file, in Visual Studio, since COM dlls need to be registered in the registry, COM dlls will show under the COM tab in the window used to add a reference. A .NET dll will either show in the .NET tab or not at all.

Also, once a reference has been added, if you click on the dll in the References window and look at the Properties window, you will get the type of dll in the File Type property. COM dlls show as ActiveX. This works at least since version 2010, I could not say for prior versions.

In code, you can try to load the dll with the Assembly.LoadFrom method. If it works, its a .NET dll, otherwise it is a COM or Win32 dll.
Avatar of Lawrence Avery

ASKER

Ok, I understand what saying until you mention a standalone DLL. In Visual Studio under the reference tab called COM, how is the list populated to select from? Does Visual Studio check the registry for all COM types or is this a preset package of COM modules only associated with the Visual Studio tool?
Also, I am asking the same question specific to the reference tab called .NET; how is that list populated? Can you add to that list? or is that somehow preset package only associated with the Visual Studio tool?

I hope I am not a pain by asking those questions but I have always been curious how those[b TABS:   .NET and COM get their content
ASKER CERTIFIED SOLUTION
Avatar of Jacques Bourgeois (James Burger)
Jacques Bourgeois (James Burger)
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Excellent answers. Thank you very much.
I just noticed under the Visual Studio - Add Reference - COM tab there is a heading called TypeLib version; That doesn't mean the dlls and exes mentioned under the Path heading are standalone Type Libraries necessarily but the actual COM dlls or exes that have type libraries embedded in them, correct? or they could be either standalone TLBs or COMs (with embedded Type Libraries)?
The assembly itself references the .dll / .exe / .ocx, so this is what you see after you have created the reference.

But what Visual Studio needs is the type library, the definition of the classes, properties, methods, etc. included in the application or library. In COM, the type library is most often included in the program itself, but depending on how the program was compiles it is also sometimes provided as a separate .tlb or .olb file. This is what you see when you are creating the reference.

The version of the type library is normally useless, but I suppose it could be useful to diagnose problems if, for some reason, the versions of the dll and of the type library are not the same.
Bottom line these COM tab modules are references not the actual COM module??
The name References tells it all.

What will happen with the COM files themselves depends on the rules you set in the Properties window.