Installer claims newer file already installed - file version info being ignored?


  •     I am trying to debug a C# custom action DLL within a Windows Installer project and I can launch the debugger just fine. I am trying to mimic the upgrade process by installing copies of past releases in the target folder. I also have to preserve any existing installed EXE file, so I install the new EXE in a subdirectory of the target directory (and the custom action is to decide what to do with the two EXE files).

        The EXE files all have valid version information. For example, I’ll make one build and run the setup program using version 3.70, and the custom action moves the EXE file from the subdirectory into the target directory. Then I’ll make another build and run the installer using version 3.80 (changing the installer ProductCode).  The install will fail with the error message “Unable to install because a newer version of this product is already installed.” But no other files have been changed other than the one EXE being installed and the ProductCode (and rebuilding), and the only other files installed in the target directory (for now) are the custom action DLL and Interop.IWshRuntimeLibrary.dll (since my custom action uses the Windows Shell object).

        What is triggering the installer to think that a newer version is already installed?

    Monday, August 28, 2006 2:08 AM

All replies

  • Bill,

    I have had similar issues, but finally cracked it. In addition to changing the ProductCode property within the Setup project, and the version information for your project, did you update the version property for the setup project?

    This seems to have 'squared the circle' for me.



    Sunday, September 03, 2006 11:31 AM
  • Your message is nothing to do with file versions - that message is a consequence of DetectNewerInstalledVersion being true in the project properties. The version is the setup project's version.
    Sunday, September 03, 2006 6:00 PM
  • I believe there is a defect in the installation project of VS2005.

    At the outset, there are two property names that are poorly named.

    "ProductCode" is documented as change and "UpgradeCode" is documented as never change. This seems backward to me.


    Specifies a unique identifier for an application, represented by a string GUID. This identifier must vary for different versions and languages.

    Windows Installer uses the ProductCode to identify an application during subsequent installations or upgrades; no two applications can have the same ProductCode. To ensure a unique ProductCode, you should never manually edit the GUID, instead you should use the GUID generation facilities in the Product Code dialog box.

    Specifies a shared identifier that represents multiple versions of an application, represented by a string GUID. This property is used by Windows Installer to check for installed versions of the application during installation.

    The UpgradeCode should only be set for the first version; it should never be changed for subsequent versions of the application, nor should it be changed for different language versions. Changing this property will keep the DetectNewerInstalledVersion and RemovePreviousVersions properties from working properly.

    Further, the values for "DetectNewerInstalledVersion" and "RemovePreviousVersions" seem to serve no purpose, they certainly don't allow you to circument the dreaded "Unable to install because a newer version of this product is already installed".

    In all, without some additional black magic, one is left with uninstalling an old version before installing a new version...something that gets tiring very quickly.

    I put this down to a defect and I am quite surprised that there is not more chatter on the web concerning this issue.


    Tuesday, September 12, 2006 5:16 PM
  • Phil -

    Indeed I (accidentally) had the DetectNewerInstalledVersion set to true. But why would that generate the "unable to install because a NEWER version is installed"? The version of the setup project had not changed, the product code DID change as it is supposed to, and I changed the EXE file being installed to a newer version, not an older version.

    So I'm still confused as to what is "newer" in the existing install that Windows Installer is looking at. Any ideas?

    And am I correct that Installer is ignoring any version information in the EXE file because it is never installed in the same directory as the existing EXE?

    Friday, September 15, 2006 3:27 PM
  • I looked at what Visual Studio generates. You used a new ProductCode, but DetectNewerInstalledVersion includes the original version. So it found the same UpgradeCode with the same version and gave you the message. It should really be called DetectNewerOrEqualVersion.
    Friday, September 15, 2006 11:27 PM
  • Thanks - that is very helpful to know.
    Monday, September 18, 2006 1:07 PM
  • Hi Stephen,


    I know, If DetectNewerInstalledVersion set to be false, we can install the older version even higher version already installed.  But my requirement is, Before install the older version, i need to uninstall the higher version automatically, i no need any confirmation here...


    Automatically in the sense, I no need to go to add or remove programs and manually do that.


    After uninstall the higher version, need to install the older version.


    Can you tell me the solution?




    Saturday, May 03, 2008 5:57 AM
  • Hi Bill,


    It sounds like hopeless to reply your post after over one and half years.

    However, I would still give you a reply, hoping that this information can help with this kind of problem.


    Based on my experience, your problem is probably caused by install new version of application involving the same DLL files. To say it more accurate, this error message is caused by installing DLL files using the same filename as old version.


    Be default, Windows loads the associated DLL and calls the custom uninstall action. Later, the customized install action from the new product is called. If this DLL has the same name as the DLL in the older product, Windows assumes that the DLL is loaded and it will not load the version of the DLL from your new setup.


    Because the install method from your old custom-action DLL is called instead of the one from the DLL in the new setup, your upgrade would not finish successfully. Similar problems have been reported with COM DLLs.


    Here is the solution: I recommend that you change the name of your DLL files in new version, which prevent this situation from happening.


    Please refer to this link for more information.




    Best wishes,

    Jun Wang



    Tuesday, May 13, 2008 6:10 AM

    Jun - Your reply may have been too late for Bill, but very timely for me.  You explained exactly what is happening and why, and a best practice.  Is your clear explanation in any out-of-the-box documentation (could not find this anywhere else)?
    Thursday, September 25, 2008 6:03 PM