How To register 2 copies of the same component on the same server

I know it could sound weired, but as we have 2 test environments one uses the current production version of DLL, and on the same server we have another test session running concurrently that tests an updated version of the same DLL. I want to enable the first stream of test to go against the current copy that is in production (testing something before loading it in production), and at the same time in another project we made enhancement to the same DLL, and we want to test it concurrently with the first stream. How Can I register the 2 (binary compatible - same name - different locations on the same server) dlls. we are registering them on the client machines as COM+ components.
Please do not suggest a change of the test process, it is out of control. Is there a trick to do that (like virtual servers ...etc) thanks.
I know it is a hard question, so I will give it the maximum points.
Who is Participating?
ShauliConnect With a Mentor Commented:
You can't :)

As a rule of thumb, you should make your dll always compatible backward, which will enable previous versions to work with the dll, although it has new functionalities that work with the new version. If you do that, then you can use the same dll for both version.

What you can do, if you must, is create a new dll, and use two different dlls.


If they are binary compatible they will have the same GUID so you can't get your test environment to pick up different ones. Cold you break the binary compatability and compile one set of test code against the old one and another set of code against the new one then they will pick up the ones they have been compiled against so you can run your concurrent tests?

Technically, you can....given some assumptions.

I just created a simple application and dll to test it and I successfully ran two versions of the same dll.
I don't know how it wil work with COM+, but maybe this will give you some ideas.

Regsvr32 version 1 of the dll
Load app1.
Assuming early binding, the version1 dll is loaded in process.
Keep app1 running.

Regsvr32 version 2 of the dll.  
Load app2. It will load version 2 of the dll.
Keep app2 running.

As long as the applications remain running they should use their in process version of the dll.
If you use late binding, then I assume this will not work.

One of the problems with testing is that it is hard to overwrite a dll once if has been used by com+, it seems to get locked. So you end up having edit the project name like MyDLLV10 becomes MYDLLV11.  In your test program you can either reference then new DLL or you can remove the reference completly and test using late binding. So when testing DLL's for example I pass the project name as a parameter in the url or as a parameter in some ini file.  This works if you are using the same server that you created the dll on, if you are testing from a remote workstation it is a little harder as you ned to regersiter the MyDLLV11.TLB on the calling workstation so it becomes a pain.
fmichailAuthor Commented:
Dear Shauli

I do not mean your answer is not OK, but you are giving me the solution that I currently use, but in fact I expected some one to guide me to something New like "Virtual server". Virtual server I beleive could be the best solution, because you will have (I think) multi servers on the same server, and on each you can register the different Dll (which are binary compatible but have different code). on the machine you have 2 short cuts one against each copy of the main exe., and on the server you will have 2 copies of the main application each is compiled against the component in its own "Virtual server". I will try to be more specific:
Virtual 1 has
      MyApp1.EXE      pointing to the component MyDLL.DLL (of course on the same virtual server)

Virtual 2 has
      MyApp2.EXE      pointing to the component MyDLL.DLL (of course on the same virtual server, but the code in this dll is different, although it has the same name)

On the test PC we will have one shortcut pointing to MyApp1.EXE      , and onother to MyApp2.EXE      .

I am not stating that this is the solution (simply because you still need to register the 2 dlls on the same test machine, although they have the same GUID), but that was the chalenge in the question which made me give it the highest points.

your solution will work (of course), and that is why I think you are the nearest answer. Thanks to all of you experts.
sorry for being late.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.