This is what I think I know:
TypeLib only descripes "what should be out there" (=How to locate and call the actual class)
If .tlb -file (=TypeLib) is imported in C++ -code at compile time, the compiled code already contains all information "what should be out there".
Interop -assembly (.NET) is pretty much the same as .tlb -file. It's only in assembly-form so that the .NET code can be compiled against it, but also contains info only about "what should be out there".
If interop in embedded, its TypeLib-info is included in the assembly and there's no need to deploy separate interop-dll when the application is deployed.
If the interop is not embedded, the interop-dll must be deployed to the same folder as the calling assembly so that the info can be found by the caller.
Of course the actual classes that the TypeLib is pointing to must be registered so that they can be found from the depth of the machine with the TybeLib-info.
Please correct me, if something above is wrong.
My question is, based on above "knowledge", why I sometimes see articles/questions/tutorials about REGISTERING TYPELIBs? It just doesn't make any sense to me (yet), since registering them shouldn't provide any excess information for the caller.
Thank you.
Related
I have an executable that looks for a particular DLL. I have changed the source for DLL and recompiled it (written and recompiled in VB6). Once I replace the DLL, the executable hits a runtime error when it gets to using that particular DLL. Works ok when I recompile the executable.
So my question is, with same DLL path, same name, and virtually identical DLLs, why does the executable need to be recompiled?
This is driving me bananas so any thoughts would be appreciated. Thanks, Callum.
A VB6 (or any COM) DLL has unique IDs for itself and its public interfaces, if you recompile these can change and any existing code bound to the old IDs fails.
Tldr; Tick "Binary Compatibility" in the DLL's project options & select the old working DLL as the thing to maintain compatibility with & recompile.
Detailed explanation: I keep hearing about DLL hell - what is this?
When you compile a VB6 DLL the compiler adds an exported DllRegisterServer() function to the DLL.
What exactly does this function do?
I do understand that its purpose seems to be to add entries to the registry that allow all the COM magic to work... calling it
"Instructs an in-process server to create its registry entries for all
classes supported in this server module."
But I am interested in a specific, detailed specification for what it does. I haven't found any MSDN documentation on this. Does something like that exist? Has anyone disassembled that code and documented their findings?
Edit: One reason I'm interested in this is that I think there are cases where it doesn't work fully / successfully (even when regsvr32 reports success) and I'd like to understand these potential failure modes better.
The function is used to register the DLL with the windows registry. For example, if you call regsvr32.exe with the DLL name, the DLL will be loaded and then the regsvr32.exe utility will call the DllRegisterServer() function. What the function ought to do from a COM perspective is to make the PROGID, CLSID, and TypeLib entries in the Windows registry so that COM clients can create and use the COM object through CoCreateInstance().
How can one programmatically determine which type libraries (GUID and version) a given native, VB6-generated DLL/OCX depends on?
For background: The VB6 IDE chokes when opening a project where one of the referenced type libraries can't load one of its dependencies, but it's not so helpful as to say which dependency can't be met--or even which reference has the dependency that can't be met. This is a common occurrence out my company, so I'm trying to supplement the VB6 IDE's poor troubleshooting information.
Relevant details/attempts:
I do have the VB source code. That tells me the GUIDs and versions as of a particular revision in the repo, but when analyzing a DLL/OCX/TLB file I don't know which version of the repo (if any--could be from a branch or might never have been committed to a branch) a given DLL/OCX corresponds to.
I've tried using tlbinf32.dll, but it doesn't appear to be able to list imports.
I don't know much about PE, but I popped open one of the DLLs in a PE viewer and it only shows MSVBVM60.dll in the imports section. This appears to be a special quirk of VB6-produced type libraries: they link only to MSVBVM60 but have some sort of delay-loading mechanism for the rest of the dependencies.
Even most of the existing tools I've tried don't give the information--e.g., depends.exe only finds MSVBVM60.dll.
However: OLEView, a utility that used to ship with Visual Studio, somehow produces an IDL file, which includes the importlib directives. Given that VB doesn't use IDL files, it's clearly generating the information somehow. So it's possible--I just have no idea how.
Really, if OLEView didn't do it I'd have given it up by now as impossible. Any thoughts on how to accomplish this?
It turns out that I was conflating basic DLL functionality and COM. (Not all DLLs are COM DLLs.)
For basic DLLs, the Portable Executable format includes a section describing its imports. The Optional Header's directory 1 is about the DLL's imports. Its structure is given by IMAGE_IMPORT_DESCRIPTOR. This is a starting point for learning about that.
COM DLLs don't seem to have an equivalent as such, but you can discover which other COM components its public interface needs: for each exposed interface, list out the types of their properties and their method arguments, and then use the Registry to look up where those types come from. tlbinf32.dll provides some of the basic functionality for listing members, etc. Here's and intro to that.
I have a native app that has an .OCX file that needs to be registered for it to be used in a .NET application.
Now currently there's different versions of this .OCX on the machine. Can someone please explain how this can affect the registration of this new (updated) .OCX file registration?
And how does my .NET app know which object to create from which .OCX file?
COM servers are required to change their CLSID guids if their interfaces are no longer compatible. So if your supplier did it right, you should be able to register both of them and get the right one when you use the right reference in your project.
Like any rule, this one got violated often and is presumably the reason you started this question in the first place. The back-up plan is to use registry-free COM, you write a manifest and add it to your program so it always uses the local copy of the COM server DLL instead of the one that was registered. Find out how to do this by googling "regfree COM", I see many relevant and useful hits at the top.
I believe COM class registrations include the entire path to the "server" providing the COM component. If the two versions of the .OCX have different class GUIDs, then there should be no issues.
I have been trying to load a OCX file into one of my VB6 projects for most of the day today. I've tried checking the COM registration in the registry the best that I know how, and have attempted several times using REGSVR32 on the file to no avail. All I keep getting from VB6 when I try to load the component (Under Project --> Components) is 'FilePath\FileName.ocx' could not be loaded. Has anyone else seen this before, and if so, any ideas how to fix it?
Just a couple of tips to help isolate the problem....
Look at the control with OleView
Examine the name: if it is one of the reserved words such as 'Menu', vb6 will fail to load it. (Although vb6 will happily let you create (and use) one with a bad name until it is saved and reloaded)
Examine the interface: does it describe the functionality? You may have a damaged or unlicensed ocx.
Attempt to load it with the ActiveX Control Test Container...
If you can, the problem is with VB6 and not the ocx.
This it may be a dependency issue -- some other component needed by the OCX is not present. Dependency Walker will find any static dependencies.
We fixed similar error recently. In our case the error was in the Visual Basic project (.vbp) file. Project file had been edited outside standardized build machine and contained references to OCX components - including workstation specific paths & versions of the components.
You can either edit the the project file in text editor or get a working version from version control.
Un-registering and registering again worked for me too.
Please note that you need to register this component using this syntax:
regsvr32 /i:design olch2x8.ocx
When you say you have used "REGSVR32 on the file to no avail" do you mean that you get a file name succeeded message, or an error message? If registering the file succeeds CMB is likely right about the ocx being unlicensed.
Licensing aside, there are a couple of other trip points with vb6. Especially if the OCX was developed in VB6.
If so, the 'officially' system registered version may conflict with the specific ocx you're using. In other words, both of them might have the same proper name (or classid) but the one you're attempting to use may not implement all the functionality described in the system registered one (i.e. you have a less evolved version). This arises when the author desires to maintain binary compatibility while enhancing the functionality of a control. As long as the public interfaces remain compatible, vb will not recalculate the classid.
You can fix this by forcibly unregistering the specific control (actually unregister all instances of the control). (regsvr32 /u control.ocx ) Then re-register the one you intend to use. Be certain that no running instance of VB6 exists when you do this or the results might not work. (Check your task list)
Hope that helps...
The control may be reliant on another DLL or OCX that may be missing or not registered and this could manifest itself as VB reporting that the control you're trying to use is missing. However, I'm not sure how you would identify the dependencies. As far as I know, dependency walker identifies static dependencies; I'm not sure if it can identify COM dependencies.
Un register the Ocx
re register the ocx
then loaded the project again in VB6, it worked for me.
Thanks everyone