VB6 and COM compatibility

[Carlo]

I recently started in a new position, and I inherited an application written in VB6 that uses a bunch of DLLs and OCX controls. Version Compatibility is set to Binary at the project level, but since I do not have the most recent source code, on compilation it always asks me to break compatibility. The app has been installed on half a dozen remote sites, and I am not sure what all the different versions are. To clean up this mess, I decided to recompile everything without any Compatibility settings. That works fine, and tested it fine locally. There are no other apps that use these controls or DLLs, so I think it's safe to redeploy this project without COM Compatibility. However before I can reinstall this app on the remote sites I guess I need to clean up all old OCX, DLLs and registry settings on those boxes to make it work. Is there an easier way?

 

[Michel Posseth [MCP]]

if the project is installed with

A , the setup and deployment wizzard , or a customized setup1.exe
B a installer based technology ( wise , installshield etc etc )

You do not need to do anything at all as to install the new version on the target system


these installation routines will automaticly overwrite ( in the case of installer deinstall ) previous versions of dll`s ocx`es


by the way did you notice the dotnet prefix in this newsgroup ? some people over here might be upset with your non dotnet related question , so you might bether ask questions in the classic VB groups microsoft.public.vb.XXXXX ( the ones without dotnet )




regards

Michel Posseth


"Carlo" <[email protected]> schreef in bericht I recently started in a new position, and I inherited an application written in VB6 that uses a bunch of DLLs and OCX controls. Version Compatibility is set to Binary at the project level, but since I do not have the most recent source code, on compilation it always asks me to break compatibility. The app has been installed on half a dozen remote sites, and I am not sure what all the different versions are. To clean up this mess, I decided to recompile everything without any Compatibility settings. That works fine, and tested it fine locally. There are no other apps that use these controls or DLLs, so I think it's safe to redeploy this project without COM Compatibility. However before I can reinstall this app on the remote sites I guess I need to clean up all old OCX, DLLs and registry settings on those boxes to make it work. Is there an easier way?

 

[Phill W.]

I recently started in a new position, and I inherited an application
written in VB6 that uses a bunch of DLLs and OCX controls. Version
Compatibility is set to Binary at the project level, but since I do not
have the most recent source code, on compilation it always asks me to
break compatibility.

Oh ... my ... God.

So where /is/ the most recent code, then?
How "out of date" is the code you've been given.
How many "bugs" in the application are you going to re-introduce,
because you don't have the source code that /fixed/ those bugs?

Seriously, this is a crazy point to start from.
But anyway ...

The app has been installed on half a dozen remote
sites, and I am not sure what all the different versions are. To clean
up this mess, I decided to recompile everything without any
Compatibility settings. That works fine, and tested it fine locally.

If you really have recompiled **everything** - that's /every/ Dll and
exe that's been deployed to /every/ site, then you might have a fighting
chance of making this work.

There are no other apps that use these controls or DLLs, so I think it’s
safe to redeploy this project ...

Test it thoroughly first. Clean machines to start with, then try and
get hold of a tame user or two who don't mind having their previous
installations trashed while you confidence test the new one.

... without COM Compatibility.

Absolutely not.

The whole point of compatibility in the VB/COM world is that, if you
/don't/ have it turned on (preferably to Binary) then you're going to
have to go through this entire exercise for /every, single/ code change
that you make to /any/ of the DLL's.

With compatibility turned on, you'll /only/ need to do this if you
change the [published] API's to your DLL's, i.e. you break
compatibility, which is what VB's warning you about.

However before
I can reinstall this app on the remote sites I guess I need to clean up
all old OCX, DLLs and registry settings on those boxes to make it work.
Is there an easier way?

I'm guessing you'll be overwriting the same, physical files, so you
don't have to worry about those. When you register the DLL's and OCX's,
the Registry on each machine will be updated to the new ID's embedded in
the new DLL's.

HTH,
Phill W.