Installer built with Application Builder gives error "Cannot install, higher version already installed"

[Edjsch]

I am having an issue with an installer which I created with the Application Builder. I have a project that I have successfully deployed. Subsequently I created another project (and vi) which is based on a copy of the originals, both with new file names. In the renamed project file, I changed all file names, paths, and all resources, to reflect the new names. I also changed the installer’s destination and install folders, of course. I reset the executable’s version number (in the Build Specification properties) to 1.0 (the original was 1.3). I then successfully built an executable and the application installer. However, when I run the installer (setup.exe), it gives a dialog (after the license screen) that it “Cannot install” because a “higher version already installed”.

I’ve done exactly the same thing with other vi’s and projects of mine, and never had this issue. The installer correctly installs the newly created (and renamed) version where it is told to in the project file. Also, I’ve never had a problem deploying (installing) on my development PC either.

I have carefully checked and rechecked to make sure there is no reference to the original executable or paths. What could be causing this behavior? I want to keep the two projects completely separate, so simply changing the version to higher than 1.3 is not an acceptable solution.

Thanks to anyone in advance for any help and suggestions.

Ed

[Edjsch]

I created a new project file from scratch and it worked. I don't know what is wrong with my previous project file. I believe all the file names, paths, and properties are the same. Indeed, I used it as the model. The new project, of course, has a slightly altered name, and I put the installer in a new (different) folder.

If anyone knows of some "hidden" property in the project file, please let me (us) know. Thanks!

Ed

[RavensFan]

There is a application GUID number that is part of the installer.  It is a long string of hex digits in the Upgrade box under the Version Information settings of the installer.  When you created a new application, you were randomly assigned a new number.  When you copied the old application, that number stayed the same.  That GUID serial number is what distinguishes applications from each other when installing on Windows, not filenames or project names.

If you had hit the button to generate a new number, then the new application would have been identified as new and distinct from the old one.

[Edjsch]

Thanks, but where is that button to generate a new GUID number?

[Joseph_Loo]

It looks like it is found in the installer->Version->generate

[Edjsch]

I have version 8.5 and there is no such "button" or ability to generate a new GUID that is shown in the setup.ini file. I couldn't find it on the NI.com website either.

I checked other projects, and in evey new release the PackageGUID changes.

My nidist.id file (this works -- I didn't save the one that doesn't) has the following, for whatever thiis is worth:

[Volume Id]
DistributionGUID={615E12A4-DD28-4389-889B-6B2CD1CA1E1E}
DistPackageGUID={ECB21F78-A774-4A0A-B789-2C613E177500}
DistributionVersion=1.0.0
DistributionType=MDF
DistributionLanguage=9
Volume=1
ExePath=setup.exe

Thanks for your help.

[RavensFan]

This is LabVIEW 2012.  I don't have LV8.5 installed to verify that it had it as well.

[dan_u]

I think LV 8.5 does not give you control over the GUID. Whenever you create a new build specification it will also create a new GUID. When you copy a project, however, the GUID remains unchanged.

You could try to modify the .lvproj file manually. Close the project in LabVIEW, create a backup copy, then search for "App_applicationGUID" and modify the HEX value there.

[Edjsch]

Yes, LV 8.5 does NOT give me control over the GUID. In the project file there are three such strings:

"App_applicationGUID"

"App_INI_aliasGUID"

"App_INI_GUID"

They all have different numbers and none of them match the GUID or PackageGUID in setup.ini. I don't know if they are related or not, but usually it's not a good idea to mess with (manually edit) files like these (project, ini, etc.) unless you know what you are doing. (For example, I do edit the setup.ini file to change some of the [Dialogs] parameters, but that is based on direction from NI support.)

Anyway, like I said, I've made copies of projects before and never ran into this problem. At least I have a solution, however laborious, in creating a new project file from scratch.

Let me know if anyone has more thoughts on this.

Ed

[dan_u]

You're right, the setup uses the "DistID". It's up to you if you want to try changing it.

Anyway, you don't need to create a new project from scratch. You can just create a new installer build specification, this will have a different ID. Maybe even duplicating an existing installer build spec creates a new ID, but I'm not sure about that.