As the question states - is there a good tool out there which lists methods an unmanaged DLL exports? I would like it to list COM methods and interfaces too.
For DLLs, use the Dependency Viewer (depends.exe).
For COM objects, use oleview.exe
Take a look at Dependency Walker to get a list of unmanaged functions exported from a DLL.
You can't easily get a l list of COM classes exported from a DLL. What you'd have to do is something like to through the registry and find all objects that reference the DLL in question. DLLs advertise their classes via registration in the registry...
As an application packager we use a utility that monitors (or dumps) the registration information - WiseComCapture.exe - this is part of Wise Package Studio however which isn't free.
It spits out a .reg file of all it's registration information.
A bit of noodling around with google may 'expose' it
Related
I need to present an "About" style dialog about a COM dll that my .NET application is calling via interop. I've seen solutions for using GetFileVersionInfo on a currently loaded assembly, and also pInvoke style GetModuleHandle then querying calls. But since I'm using interop, in my loaded modules list I don't see it directly, just my interop dll.
If I use FileVersionInfo(filename) and have the full path to the dll, I get exactly what I need - however as the user will have control over where they install this COM dll, I can only think of querying the registery to get this full path. Can anyone see a better solution? Previous version of this product was a native application and thus loaded the dll directly.
Any ideas or is querying the registry the best choice?
Given a native DLL, with no documentation or anything, and assuming it is not a COM component, is there any way to extract some sort of interface from that DLL so it can be called from C#?
I know about PInvoke, but that requires me to already know the method names and signatures. I don't have those.
Is it even possible?
You can use a PE reading tool to list the exported functions. For example Dependency Walker will do that for you.
There's not a right lot you can do with that information though. There's no metadata with a native DLL that tells you how to call those functions, what their signatures are. Or even what the parameters represent.
Something has gone wrong with this project. A DLL on its own is not enough. You need a header file and some documentation.
I need to write a stub module which, when given a PE (DLL/EXE) as input, will determine whether it is a normal Win32 DLL/EXE or COM DLL/EXE. I need to determine this programatically.
Are there any Windows APIs for this purpose?
I suspect that this is something that would be very hard to do with near 100% accuracy. Some thoughts though:
A COM DLL will export functions like DllRegisterServer and DllUnregisterServer. You could use LoadLibrary() to load the Dll, and then GetProcAddress() to check for the presence of these functions. If they're there then its highly likely that its a COM dll.
A plain win32 Dll will export DllMain. You could use the same technique to check for that. If you find it then its very likely that its win32.
I'm not aware of a way to discover if an exe is a COM server. Servers written using ATL often have a registration script embedded in their resource table, but they don't have to. And you don't need to use ATL to write a COM server. Services using "registry-less com" will similarly have an embedded manifest. You could scan the registry (below HKLM/Classes/Software/) to see if the exe is registered, but it may be that the exe is using registry-less com or just hasn't been regisered yet.
Hope that helps.
For traditional COM DLL, you can look for the wellknown exported methods (search on msdn for these methods)
DllGetClassObject
DllRegisterServer
DllUnregisterServer
DllCanUnloadNow
I am not sure about EXE COM servers though because they generally use command line parameters for registration/unregistration and for class object usually calls CoRegisterClassObject when the EXE starts.
Most of the COM servers traditionally also registered in the Registry but you can create registration free servers now.
Are you also looking for a .NET assembly with some COM visible classes?
I recently ran across a DLL installed on my system that Dependancy Walker (and every other utility I tried) says has zero exports by name or ordinal, yet the file is approximately 4mb in size. I thought the sole purpose of a DLL was to export functions for use by other code so what would be the purpose of a dll with no visible exports?
One way to think of a DLL is as a container for functions. Exporting a function from a DLL makes those functions visible to callers outside of the DLL. While exporting functions from a DLL is perhaps the most common way to provide access to them, many platforms provide other ways to access functions which have not been exported such as reflection in the .NET Framework and Java and (I think) LoadLibtary / GetProcAddress in Win32
Reasons for doing this are varied, often it is because it is beneficial to the developer to have functions in a library but undesirable for those functions to be called from external applications
Resource-only DLL, maybe? Those are used quite often for localization purposes, for example.
EDIT: it's also possible to have a DLL with code that does something in DllMain() to somehow make its functionality available. The DLL can register itself with some global dispatcher, for example, or create named kernel objects...
I am very new to VB.net. I have written these objects in VB6 before. I'm just lost in VB.net, but (kicking and screaming) I have to learn how to do this. I've been googling for hours with only minor steps forward. Can anyone post a link that explains start to finish how to do this?
I have managed to write the class object, What I can not tell is how to register it and where the name1 and name2 in the CreateObject("Name1.Name2") come from.
Regsrv32 will not work. It says "Entry Point not found" and will not register it. Also, I can not drop it into the Assemblies directory. I read something about a regasm command one uses, but I can't seem to make this work either.
Thanks in advance for any assistance.
I am going to assume you are not trying to write a COM DLL but rather a complete project that call various sub assemblies like a VB6 EXE call a ActiveX DLL. If you can be more specific about what you are trying to do it would help me better.
Several points about VB.NET versus VB6.
1) For .NET only projects there is no registration. If a EXE or DLL references another .NET DLL the only requirement is that the DLLs be present in the parent's directory.
2) You can do a COM style registration for .NET apps only by registering the .NET assembly in the GAC. However there are several requirements for doing this. Do a search on the .NET GAC and it will give you the scoop on how to do this.
3) You can setup the .NET assembly to use COM in which case it will operate by the rules of COM including registration with regsvr.
You will find for .NET only project that #2, or #3 only come in rare instances. #1 will apply for 90% of your DLL assemblies. Of This is dependent on your project.
A common use for CreateObject is allow for plug-ins or installable libraries. .NET handles this through the Reflection API. With the reflection API you can look in a directory, go through each .NET DLL and see what them and create objects from what you find. Search for .NET Reflection to read up on this.
If your project is .NET only then I recommend that you create a Assembly that is reference by both the master assembly and the individual sub assembly that define the interfaces of the objects you are creating. This when you use the reflection API and determine the Object type you can assign it to a variable of that interface and code it noramlly with intellisense and other aids.
if you have old COM ActiveX Controls or DLLs .NET will generate a wrapper class that exposes the ActiveX Objects to .NET. I would spend some time learning how .NET does this. What I do create a dummy project and have .NET reference the ActiveX stuff I need. I then find the wrapper projects and DLL it made and move them into a central area. That why when I work on subsquent projects using the same ActiveX stuff I know where all the wrappers are.
You have to go to your class library properties and select the option "Register for COM interop". This will make your assembly available to COM.
You want to create what's called a COM Callable Wrapper (aka CCW) for your .NET component. This basically entails setting up some COM interfaces with some GUIDs and either enabling "Register for COM Interop" in the project properties (as mentioned) or using regasm.exe.