none
Wrong dll called because InprocServer32 data in registry RRS feed

  • Question

  • I have built an installation package using Microsoft Visual Studio 2005 Setup project.

    In my application I need to use a COM dll. This dll is copied with the installation and I have added a custom action script to run regsvr32 for this dll. All is fine so far.

    The problem arises when I run my program.
    The dll in question is OPCDAAuto.dll. When I get the servers for my node, one of the OPC servers has another version of the dll registered and calls this which causes my applikation to crash (because I need the newer version).

    When I check the registry I have the CLSID\InprocServer32 key. In there I find the defaul data to point to my newly registered dll ... fine. BUT ... I also have a darwin coded InprocServer32 data which points to the older version of the dll.
    If I just remove the InprocServer32 data it works fine.
    I want to do it in a clean and correct manner though.

    So ... to my question(s):
    1. What is the InprocServer32 data (mind you ... not the key)?
    2. How do I set up the registry correctly for my dll to be called?

    Input and ideas are greatly appreciated ...
    Tuesday, February 24, 2009 9:50 AM

Answers

  • IOt looks like the general rule for that COM component is that everyone is supposed to install it into the system folder. If you Right click File System on Target machine you can add tyhe System folder, and you can put your Dll in there. I assume it has a higher version than the previous Dll so it will replace it.
    Regsvr32 is nothing to do with it being in the system folder because it just registers it wherever it is. It just has to be copied to the right shared location (system folder) and registered there.
    Phil Wilson
    • Marked as answer by Bruce.Zhou Monday, March 2, 2009 2:06 PM
    Wednesday, February 25, 2009 10:55 PM
    Moderator

All replies

  • You don't call regsvr32 in a custom action, what you do is set the Register value in the Properties window for the Dll in the File System view to be vsdrfCOM.

    The big issue here is nothing to do with registration exactly. The problem seems to be that you have not replaced the older version of the COM Dll. You cannot have two copies of the same COM Dll on the system with in different locations. There is no idea that there can be "another version of the Dll registered". You must replace the existing Dll, and that is why there is a fundamental COM rule that new versions must be backwards compatible.

    The InprocServer32 data is an encoded path to the COM Dll. It's part of the resiliency/repair mechanism. If the Dll is missing it will repair ir by re-installing it.  It tells me that the Dll was originally installed in a correct way, because that's an effect of doing it the right way.
    Phil Wilson
    Tuesday, February 24, 2009 9:54 PM
    Moderator
  •  I know the Dll:s are supposed to be backwards compatible and I know you are supposed to replace the old version. I didn't know that regsvr32 isn't the way to do it though.

    The previously installed dll is not located in the system32 folder (there is one there aswell but that is because of my regsvr32 ... right?) but in that applications own folder. By replacing it you mean just to replace the registry settings? Will this not affect the resiliency/repair for the other application?

    Shouldn't the dll be put in the system32 folder aswell??

    Are there any good tutorials or so on how to acomplish this?

    Thanks for the input!
    Wednesday, February 25, 2009 7:51 AM
  • IOt looks like the general rule for that COM component is that everyone is supposed to install it into the system folder. If you Right click File System on Target machine you can add tyhe System folder, and you can put your Dll in there. I assume it has a higher version than the previous Dll so it will replace it.
    Regsvr32 is nothing to do with it being in the system folder because it just registers it wherever it is. It just has to be copied to the right shared location (system folder) and registered there.
    Phil Wilson
    • Marked as answer by Bruce.Zhou Monday, March 2, 2009 2:06 PM
    Wednesday, February 25, 2009 10:55 PM
    Moderator
  • Hi again!

    So, I changed my setup project to copy the dll to the system folder and set it to vsdfrCOMSetlfReg and now it actually seems to work! Thanks!

    A question: when I check the registry after running the latest installation package I only have the (Standard) and ThreadingModel values for the CLSID\GUID\InprocServer32 key. The InprocServer32 data (the encoded path to the dll) has dissapeared. I guess this was done when the dll was registered? Will this not affect the repair mechanism for the other application who had registered the dll?

    Is there any way to check the version of the current (if any) dll and to install/register the dll only if it is newer than the one already installed?

    Thanks for all the help. Much appreciated!
    Thursday, February 26, 2009 9:35 AM
  • SelfReg bypasses the repair mechanism. Juist use vsdrfCOM if you want to preserve the repair feature. It also creates the ThreadingModel value from the code in DllRegisterServer, so apparently it's not setting a value. I think if there's no value the default is Apartment, single-threaded.

    The default behavior of a MSI install is that it obeys the version rules and older versions will not replace newer versions.


    Phil Wilson
    Monday, March 2, 2009 11:52 PM
    Moderator