I'm trying to convert our NSIS setup to a WiX/MSI based one. I used to use version numbers like 1.0.4 or 1.0.4.898, which works fine. However when I make a beta, I call it 1.0.4beta1, which is different from 1.0.4 (for example, it says 'beta' in the aboutbox, so it's actually build with different preprocessor #defines). This doesn't seem to be possible with WiX, the Version attribute of a Product can only contain a 'x.x.x.x' string. How do I encode free-text status in the version string, like beta or demo status? Thanks.
Windows Installer doesn't allow this (it encodes the ProductVersion property into a DWORD registry value). You must instead place your custom version string in another property.
Related
Building MSIs with WixSharp since years, I always followed this rule which basically says:
For each new release of your application, change the ProductCode but never change the UpgradeCode.
This always worked perfectly but recently I discovered that installing a newer release of my application does not replace the previous version but instead is getting installed in parallel.
Running this PowerShell script gives me this result on a test machine:
My question
What is the reason that a MSI file does not replace an existing one upon installation with the same UpgradeCode?
(I've also posted this as a question on the WixSharp GitHub repository)
Update/solution
I've finally managed to solve it. Basically I did the following things:
Removed the version string from my setups name (since MSI seems to also compare then names to check whether an upgrade is possible; only the same name seems to fit)
Changed my version number from 4 to 3 digits, as Christopher pointed out. I.e. I'm now incrementing e.g. "1.0.0" to "1.0.1" etc.
Added this code to my WixSharp ManagedProject instance:
InstallScope = InstallScope.perMachine,
MajorUpgradeStrategy = new MajorUpgradeStrategy
{
UpgradeVersions = VersionRange.OlderThanThis,
PreventDowngradingVersions = VersionRange.NewerThanThis,
NewerProductInstalledErrorMessage = "Newer version already installed.",
RemoveExistingProductAfter = Step.InstallInitialize
},
After these changes, an upgrade succeeded.
The constraint is ProductCode not UpgradeCode. Only 1 MSI per ProductCode can be installed. Attempting to do so again will be a maintenance operation, small update or minor update.
Many MSI can share an UpgradeCode. (Not a good practice though!) For example it's not required for you to author a Major Upgrade at all.
The usual cause here though is you must change the version number in the first three fields and each install must be in the same context (per-user and per-user or per-machine and per-machine). BTW that's another way to install the same ProductCode twice. One per-user and one per-machine. Again not a good practice.
Good:
1.0.0 → 1.0.1 FindRelated Products in the 1.0.1 MSI will see the 1.0.0 and tell RemoveExistingProducts to remove it.
1.0.0 → 1.0.0 or
1.0.0.0 → 1.0.0.1 Bad. FindRelated will see it as the same version and not remove it.
I have a problem with my phonegap-based project, and I'm suspecting I'm running a different version than I think. the config.xml file I'm using states it's 2.0.0, while I thought it's 2.9.
Is there a way to actually check the phonegap version in xcode, and not relay on a comment in a single file?
Thank you!
you can use device object's cordova(device.cordova) property to get the version of phonegap.
Below link provides more information for same.
http://docs.phonegap.com/en/3.0.0/cordova_device_device.md.html#Device
I thought I would add to #user1279357's answer, which demonstrates how to acquire the version of Cordova from the JavaScript side. However, on the Objective-C side, if you add #import <Cordova/CDVAvailability.h> you can call the constant: CORDOVA_VERSION_MIN_REQUIRED.
This constant is an int that will provide you with the version of Cordova you are using. The value is in the form of: 20000 = 2.0, 20800 = 2.8 e.t.c.
If you need to do checks against this value, there are other constants defined in this file for each of the versions, e.g. __CORDOVA_2_0_0 = 2.0.
Look here to see the source file for CDVAvailability.h.
Look in your cordova.js file at the top in the comments.
If you're using a really old version of cordova, it will be in the listed in the filename like "Cordova2.7.js"
Lets say my current production version is 1.2.3 and the new product version is 1.2.3.4.
Now, during installation, it will throw a warning message saying something like "The setup has detected the version 1.02.003 of...... already installed. This setup updates ..... to the same version that is already installed, therefore this update is not needed. Do you want to install the update anyway? "
This will be very misleading. Does anybody know a solution for this?
It is not InstallShield, but rather Windows Installer, the underlying technology has the behavior you observe. Take a look at this article, which explains how Windows Installer treats versioning.
The important part for your case is this:
Note that Windows Installer uses only the first three fields of the
product version. If you include a fourth field in your product
version, the installer ignores the fourth field.
This explains why it considers the new one to be the same version. So, the suggestion is either change the third digit, or go with small updates instead. Here is how you can apply small updates by re-installing the product.
Is there an official list of Inno Setup messages like "WinVersionTooLowError" somewhere? I need to change the "This will install AppName on your computer" but don't know how. Thanks!
The default language file should have a complete list, you can view the online CVS version here.
The translation download page contains this note:
Starting with version 5.1.0, the Inno Setup compiler will accept a
translation even if it's missing messages (it will use the default
English messages to replace them) or contains unknown messages.
so you should be able to create a custom English language file that only changes a couple of strings if that is what you want, but it is also possible to override the strings without using language files.
You might also want to take a look at Inno Setup Easy Translator
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)