Thanks for the various responses - I've summarised them below - yeap they are COM DLL's, created in VB6

I don't think I can use the copy the DLL's to the executable directory or the PATH suggestion, as it's IIS that is instantiating the objects - interesting tip on the fact that Windows app's search their local directory first, but does this apply to COM DLL's as well ?

I think Bob's comments on COM effects and having to use scripts to unregister/register seem to be possible way forward - we do have binary compatability set in the VB projects - does that maintain same interface, progid's, etc. ?

Another sledge hammer option I'm now looking at is a different PC for each release - well actually a different virtual PC for each :-) - I've got VMWare (and just got Virtual PC 2004 from MSDN) and been quite impressed with just how close to reality the virtual PC's are

Cheers, Steve C.

Steve Culshaw writes:

You have several alternatives, all variants of two basic solutions. You can either fix the registry entries to find the right DLLs or you can use the PATH to resolve the DLLs in development instead of the registry.

For the PATH variant, have your development environment run the executable from within a wrapper script that sets the PATH for that shell. Of course, if your executable checks the registry regardless, then this won't work.

You could instrument your executable to test for a signal environment variable and avoid the registry checks when it's present, but that would

introduce more variability and opportunities for problems in your production executables. That could be mitigated by conditional compilation directives, but again that has its own risks.

On the registry front, you could perform an uninstall and install, you could create a .reg file that touches only the right registry keys and execute

that when changing workspaces, you could use the last suggestion and always run the reg patcher from a wrapper script around the executable.

A hybrid variant would be to understand how your application finds the DLL when the registry is not set and use that to rely on the path or the current directory to supply the DLL location. This may require some restructure of your development environment and of course would conflict with formal installs of your product.

Good luck.

Stephen Vance http://www.vance.com

Saturday, March 20, 2004, 9:06:55 AM, you wrote:

To be pedantic, you're talking about COM DLLs. It's the COM registration that you need to handle when you're switching versions. Non-COM DLLs don't have that problem. (They have others.<g>)

It's worse than that.<g> Unless both versions expose the exact same interfaces, progids, etc, just having them in the same place isn't enough.

Any time you're working with COM objects, you need to have scripts that let you easily unregister and re-register them. That's the easiest way to deal with them.

-- sig://boB http://foobob.com

Steve,

I can see a couple of options.

IIRC, windows applications search their local directory before searching

the path or registry. You could insure that the DLLs with the bug are mapped into the executable's directory with either a branch or a client change (I'd change the client).

Or, you could remove the newer DLLs from your client spec and map the older DLLs into their place on the local drive. Unfortunately, switching client specs on the same machine will not work, you'll have to

either edit your current one, or use the 'forced sync' (p4 sync -f) when

you switch between clients.

-- Rich Ireland Firmware Engineer Idaho Technology, Inc. http://www.idahotech.com/ mailto:rich.ireland at idahotech.com

Thanks for explaining how DLL's work (like I said, I've never had the "pleasure" of experiencing DLL hell).

I think I understand the situation a bit more.

I won't claim that the following is the most ideal solution but my intuition says to: - put the DLL's in Perforce using a good naming convention; an alternative is to place the DLL's in a well-known place on the disk, each version in its own place (eg //my/dll/1.0, //my/dll/2.0, ...) - each release of your project should have an installation/registration script that will install/register the proper DLL's into the proper places

When switching from one release to another, run the installation/configuration script.

One big limitation I can already see is that you'll be able to work on only one release at any one time, but I think until .Net becomes more common, this is just the way it is on Windows.

Again, I'm not a windows programmer so you'd know better whether the above is feasible or not.

HTH, Noel