Registering multiple versions of the same dll
I am trying to have two versions of the same dll running on the same machine, as I described in my last question here. As you can see from that question, I accepted the first answer, which I thought had solved my problem. But as it turned out, I hadn’t tested it out enough. The ‘If’ statement did change the GUID for release, but it didn’t handle a different factor.
Visual Studio always unregisters the old version of your dll before registering the new one, and it seems to keep track of GUID changes, at least in a limited scope. For example, if you have an assembly that is registered for COM interop, and you change the GUID, Visual Studio knows to unregister the old GUID instead of trying to unregister the new one which obviously hasn’t been registered yet.
This creates a problem, since I want both versions of the dll to be registered at the same time. I want to compile for debug, then compile for release (while keeping the debug version registered and working) and then go back to compiling for debug (while keeping the release version working). So I need Visual Studio not to unregister the old GUID when the ‘If’ statement changes it.
Visual Studio always unregisters the old version of your dll before registering the new one, and it seems to keep track of GUID changes, at least in a limited scope. For example, if you have an assembly that is registered for COM interop, and you change the GUID, Visual Studio knows to unregister the old GUID instead of trying to unregister the new one which obviously hasn’t been registered yet.
This creates a problem, since I want both versions of the dll to be registered at the same time. I want to compile for debug, then compile for release (while keeping the debug version registered and working) and then go back to compiling for debug (while keeping the release version working). So I need Visual Studio not to unregister the old GUID when the ‘If’ statement changes it.
ASKER
I’m not sure I understand your answer. The file path of the dll is not the issue I’m running into. By default the dll is compiled to the “…\Debug” directory when compiled for debug, and the “…\Release” directory when compiled for release. I can have both files on the machine at once easily.
The problem happens when I change the compiler from debug to release. If I compile for debug and then compile for release, Visual Studio removes the debug version from the registry (or wherever the list of COM components is kept). The file is still there, but it doesn’t show up in Excel since it is no longer registered as a COM component.
The final result I need is to have both versions (debug and release) to show up in the Excel references window at the same time, so I can pick either one (i.e. my Excel file in development uses the debug version, while live and in use Excel file uses the release version).
The problem happens when I change the compiler from debug to release. If I compile for debug and then compile for release, Visual Studio removes the debug version from the registry (or wherever the list of COM components is kept). The file is still there, but it doesn’t show up in Excel since it is no longer registered as a COM component.
The final result I need is to have both versions (debug and release) to show up in the Excel references window at the same time, so I can pick either one (i.e. my Excel file in development uses the debug version, while live and in use Excel file uses the release version).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
to achieve what you want you need all the registry informations stored to be completely different. all guid's of release and debug have to be different. the names of the dll's can be same as far as they were linked by import library to the executables. if they were used from Excel only the registration as separate COM controls is important.
Sara
Sara
ASKER
The dll will be used only from Excel, when you say a separate COM control, does that mean they have to have different names?
i don't know very much of excel. so i can't say whether excel could have the same name for different GUID. but I think, yes, you should add a D suffix to the name of the debug control.
Sara
Sara
ASKER
The problem here doesn't seem to be Excel. I've gotten Excel to use two versions of "the same dll" by making a copy of the project's folder and changing the GUID of copy's assembily. Both assemblies show up in Excel (with the same name but different file paths).
That is not very workable since I would have to make a new copy of the project and change the GUID in the copy each time I wanted to deploy a new 'live' version. I'm trying to find a way to do it from within the same project.
That is not very workable since I would have to make a new copy of the project and change the GUID in the copy each time I wanted to deploy a new 'live' version. I'm trying to find a way to do it from within the same project.
a dll is a file and it is not difficult to using two dlls located in different paths. a COM control has a unique identification in the registry. so you need two controls in registry for your case beside you could put them to a manifest.
debug and release have a different configuration. it is not impossible to define register information for debug and release differently such that you got two controls.
Sara
debug and release have a different configuration. it is not impossible to define register information for debug and release differently such that you got two controls.
Sara
ASKER
I'm aware that COM components have unique identifiers in the registry separate from their file paths. That unique identifier is the GUID (Globally Unique Identifier). I can change the GUID for different configurations (as shown in my previous question). I just need to be able to change it without having Visual Studio remove the old one.
I don't need Visual Studio to do an extra action, I need it not to do an action that it is already doing. Both versions of the dll would work if Visual Studio didn't un-register the old GUID before registering the new one.
I don't need Visual Studio to do an extra action, I need it not to do an action that it is already doing. Both versions of the dll would work if Visual Studio didn't un-register the old GUID before registering the new one.
ASKER
After a lot of searching and testing, I decided to use a separate development environment, as it seems that this really can't be done. Oh well...
http://stackoverflow.com/questions/2119539/visual-studio-how-to-set-path-to-dll