Everytime a dll is registered a new TLB CLSID is created

[Thomas Tierney]

Hey all,

Everytime the a dll is registered, not compiled but regsvr32.exe is run against a dll, a new GUID is entered into the registry for the TLB. This really isnt a problem except for the fact the whenever Regsvr32.exe is run against the same dll the TLB entry is not removed. This means the everytime I register the dll during the development process I will also need to unregister and manually go into the registry and remove the TLB entry. This has proven to be a pain in the hind quarters.

This may be part of the problem people are having with .net and vb references.

Thanks

[Kev Peel]

Have you used #COM GUID and also specified a fixed GUID for each exposed class and interface?

[Thomas Tierney]

irrelevent.

The fact that the guid changes is not part of the problem. It is that when DLLUnregisterServer is called or Regsvr32.exe dllname.dll /U is used the entry IS NOT cleaned up. This leaves the TLB entry in the registry so that when you open up the references page in VS2005 you will get a list of multiple entries.

[Kev Peel]

I add the TLB file as a resource and use REGSVR32 with the DLL and it adds/remove the registry entry fine (at the #COM GUID location, that is what it's for). This works fine in VB6 as well.

I had your situation earlier but it seems to have resolved itself after deleting the TLB and DLL and all references, and recompiling it all.

[Thomas Tierney]

are you sure its the TLB Guid or the COM Guid? They are two different creatures

[Kev Peel]

Where is the TLB GUID defined? I only have the DLL with the TLB as a resource. You can see the GUID by running the PB COM browser and opening the TLB file -- it's listed near the top. This GUID is the same one used with the #COM GUID statement and is also used (by REGSVR32) to register the library at a single location in the registry.

[Thomas Tierney]

The TLB GUID is located in HKEY_CLASSES_ROOT\TypeLib\{GUID}

I am not sure about VB but VS 2005 VB.NET lists the TypeLib from here.

And I want to make myself clear on this, I understand that If I do not user #COM GUID GUID$(SOMEGUID) that one will be dynamically generated for me. This is not the problem. The problem is that when I unregister the server, everything is gone except the type lib guid.

[Michael Mayerhoffer]

This is a problem developing TypeLib and has plagued MS for a long time. I mentioned this before.

KB156078 it has more info .


-------------------------------------------------------------
Added later....
This is not the right KB article KB156078 , can not find the one I speak of on line. This one seems to be a condensed article and touches on the matter.


Visual studio can leave you hundreds of stray entries. VB alone makes tons of left over entries that never get cleaned. Just making a project.This is one reason to have 2 pcs, one for development and one for ever thing else.

If you make PB your default Tool of choice, you can avoid the registry and avoid some of these issues. I believe that by some mechanism unrelated to any specific product ends up leaving stray com entries.

[Thomas Tierney]

This is not true. Although VB does have a usage problem it in no way affects pb. For instance, if VB is not told to do so it will generate new GUIDs everytime the application is compiled. Once compiled and registered you will need to unregister the dll if you plan on compiling again. Doing this over and over will create alot of problems in the registry. However, if you clean your environment by unregistering the dll before you recompile then you will be okay.

Powerbasic, if using dynamic GUIDS, will also create the same situation. The problem is that when using dynamic guids and then unregistering the DLL DOES NOT remove all information from the registry. Try it, you will see.

DllRegisterServer must write all information to the registry, DLLUnregisterServer MUST remove entries written to the registry, ALL entries written via DllRegisterServer.

[Michael Mayerhoffer]

I took all the DLLs (3) I been playing with and replaced the static GUIDS with dynamic GUIDS. I sent them 3 to a person with nicer spy tools. (and a neutral party) - person stated- they register and unregister fine and cleaned up ok too. Worked ok in VB.

I retrieved the GUIDS with Ole view and used regedit to search. I could find no problems. PB is still picking the GUIDS.. still had to compile ...embed... register and unregister the DLL. I see no difference, just the GUIDS are invisible to you when picked.

Labor day is over and I am not aloud to play with VB untill memorial day.