Interop generated from VB6 dll, installing by Regasm, setting GUID

Hello, Hope you can help. VB6 is not my area. I feel I am missing something simple.

I have a VB6 DLL which I need to place a new version on a machine that will not interfere with the current version.

I can generate the Interop with a new version number which allows me to install it into the GAC.

I also need to Regsvr32 the DLL, and Regasm the Interop.

How do I control the GUIDs that is used for the DLL and Interop?

I have the source for the VB6 component. There is no AssemblyInfo.vb file, I do see that binary compatibility is selected, and it points to a version of the DLL. Is this where it will be pulling the GUID from?

Scanning the code for the VB6 component I see no other references to GUID.

From what I have been reading it appears that RegAsm generates a new GUID on instillation of the interop.

I see parts of the system (an IIS website, that uses java, vb6,, c#, and DLLs in vb6,, and c#) that have references to the Interop. The main one is a VB.Net DLL.

How do I make sure that these use the right GUID?

The GAC side is fine, but on my last release it appeared to use the old GUID for regasm/regsvr32 and that caused the old system to pick up the new files which I need to avoid.

I feel I am missing something very simple, if any of my assumptions above are wrong, please tell me.
Also if you could please explain what I am doing wrong or need to do in a very basic way, it would be vastly appreciated.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jacques Bourgeois (James Burger)PresidentCommented:
I haven't used VB6 for over 15 years. I switched to .NET the day it came out in beta and never looked back.

But seeing that the answer seems slow to come, here I am with what I can remember from these old times. But it's so long ago, and memory has that habit of mixing up things that we never use, even if we used them very often during a long time, way back. So I hope what I tell you is as true as I remember it. Just be skeptic about my words if things do not turn out right.

You have no way of indicating which GUID you want with VB6. This is done by the compiler. Binary Compatibility is a kind of switch for the compiler that can flag you if you change things in the code that make it break compatibility, as far as the compiler can see, between the old version and the new one. As an example, if you change the type of a property from Integer to Long, you break compatibility because older applications that use the dll will get an overflow when they will try to use that property in a situation where they were expecting an Integer.

The compiler will simply stop compiling if this happens. If it thinks everything is OK, it does compile the new version, and gives it the same GUID as the old one. Since the GUID is the calling card for COM/ActiveX applications (VB6 uses the COM standard) that require a dll, the older applications will automatically use the new version it is expected that they will still work without problems with that version.

Still if my memory is good, if you remove the binary compatibility check, the compiler assumes that you want a new version and know that it might not be compatible with the older one. It then compiles no matter what, and assigna a new GUID so that the old applications can keep using the old version of the dll. In newer applications, you will reference the new version of the dll and everything will be cool.

Or so it appears. There is a reason they changed the way versions are handled and added the GAC in .NET. The problem with the COM approach is that it is very easy to mix up the dlls, because they have the same filename. And you could easily make the mistake of overwriting the older version of the dll with the newer one, or the reverse. The GAC permits many copies of the same dll file name with different versions but, although it might seem so when you look at it in the Windows Explorer the GAC is not a single directory . And the GAC cannot be used for VB6 dlls.

The best solution, in order not mix things up is simply to give a new name to the new version of your dll. This is what Microsoft did with the VB runtime. It changed name with each version of VB (vbrun40, msvbvm50, msvbvm60 or something like these). So you could have runtimes installed for every single version of VB on the same computer, even in the same directory, and each application used the runtime it was compiled for.


As for the interop, I have never encountered a situation were you needed to either be careful about its GUID or Regasm. .NET does not use GUIDs to identify dlls, and you to do not need to register a .NET dll in order for a .NET application to be able to use it. These are necessary only when you create a .NET dll that will have to be called by a COM application. COM applications do not work without a GUID registered in the Windows registry.

Since the role of an interop is to have a .NET assembly call it as a bridge to a COM application, it will never be called by a COM application, and thus does not need to be registered. The only situation where you might want to do so is if you had a VB6 application that would go through your interop to call your VB6 dll. Complete nonsense. Let the VB6 use the VB6 dll directly.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
theMolandoAuthor Commented:
Thank you. Now know a way forward.

Have a feeling that many of the people who wrote the original system did not know that much of what they were doing, every file is being registered in every way.

I will remove the registering with regasm of the interop and see what happens. Have seen Microsoft pages saying that you should not both regasm and gac at the same time.

Will remove the binary compatibility and force a set GUID in with an, as that sounds that it will keep it with a fixed value.

If that does not work, will rename the dll, but will save that to last as it will mean many changes in other parts of the system.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.