I need to set the version visible in the 'Programs and Features' dialog in Windows. I know that this version doesn't have to follow the major.minor.build.revision restriction (for example, wxPython shows '2.8.12.1-unicode' in its 'Version' column), but when I attempt to set the Version attribute in the Product element I get the following error:
Product.wxs(50,0): error CNDL0108: The Product/#Version attribute's value, '2.3.4.0-55628f206205451282ae6060d9305254bd79cb87', is not a valid version. Legal version values should look like 'x.x.x.x' where x is an integer from 0 to 65534.
There must be a different property but I can't find it in the Wix documentation.
How do I set this version visible in Wix to an arbitrary string?
EDIT:
See the image below to see some of the different version schemes that don't follow the Windows Installer standard (wxPython, Windows Driver Package*, Windows Mobile 5.0 SDK).
Windows Installer doesn't support having separate product version and display versions.
If you are using the .Net setup project look for Version under "Deployment Project Properties".
I am not entirely sure what you are referring to with "Programs and Features"? Are you talking about "Add/Remove Programs" in Windows, or are you talking about the dialogs in your setup?
I suppose you can have a look here: Configuring Add/Remove Programs with Windows Installer, but without knowing more I don't quite know if this is what you are asking.
Please be aware that this list of programs and applications does not come from just one registry location. I do believe that it is not possible to override the version field for Windows Installer packages whether they are built using Wix or other tools. If the installation is done with non-MSI setups, I suppose they can set the version field as they see fit, but Windows Installer enforces restrictions. Perhaps you can set the ARPCOMMENTS property to a value indicating what you want to indicate.
The underlying MSI property that shows up in Add/Remove Programs aka Programs&Features is the ProductVersion property and it does have to follow a numeric format:
http://msdn.microsoft.com/en-us/library/aa370859(v=vs.85).aspx
You may be able to get a text version to show if you create a DisplayVersion text string in the Uninstall registry key. I suggest you look at the wxPython entry in the Uninstall key to see what's in DisplayVersion rather than in the binary Version value.
Related
I have a wix installer with five features. My current version is 0.0.0.125. I am installing this in one machine with first three features. Later i wish to install the remaining two features and so deselected first three and selected the remaining two features.
So this time the first three already installed should not be deleted, and the remaining two features should be installed. But when i install the same build second time, the three features are automatically removed from the destination location and the selected two features only installed.
I used RemoveFile child attribute to each Component to overwrite and when i manually copied the file and pasted into the destination directory, next time when i install the same version installer, it is not overwriting and deselected(previously installed features) features also deleted. So i have restricted this by adding 1 in InstallExecuteSequence.
i)I need to overwrite all the files
ii) Each installation of the same installer should not delete the previously installed files
Thanks
I can't tell exactly what you mean by features and installing the same setup twice, but:
You cannot install the same MSI setup twice. It's already installed (the ProductCode) so it will go into maintenance/repair mode. This may do a repair/reinstall or, if you've authored it for feature maintenance, then Windows will again notice that the product is already installed but offer the standard feature dialog which lets you add features from the setup, and this latter mode is exactly what you get if you go to Programs&Features and choose change. In other words a true feature maintenance setup offers the feature selection dialog primarily from Programs&Features, and in your scenario with adding two features you'd simply use Change from Programs&Features and not attempt to reinstall the same setup.
Your post refers to Components and RemoveFile, and you should definitely not need to do any of this. If you're not using true Windows Installer features and have built a Component-based setup where Component installation is based on conditions then that would explain what you are seeing. The property values used for your conditions are not preserved so when you attempt to install the same setup again it goes into maintenance reinstall mode for the currently installed product, the property values are empty, the conditions are false, so those components are removed.
Having said all that, you haven't posted your WiX, and the fact that you're attempting to install the same setup twice implies you may not be familiar with maintenance, features and components. In summary, it seems that you should be using the WixUI_FeatureTree dialog set, grouping your components into features to achieve what you're looking for.
If your aim is to replace files that need updating then you should look at the WiX MajorUpgrade element. If you set MigrateFeatures to yes then the upgrade will result in the same features still be installed after the upgrade. Schedule afterInstallExecute is probably what you want. Increment file versions of files you want updating, use a new ProductCode, increment the ProductVersion in the first three fields and use the same UpgradeCode. Alternatively you could look at creating a patch, an msp file.
Usually you would set Permanent="yes" for files that you want to keep on a computer after un-installation and "no" if want to remove or overwrite them.
For example:
<util:XmlFile Id="fileId"
Action="setValue"
Permanent="yes"
File='[INSTALLFOLDER]pathtofile\yourApp.exe'
ElementPath=""
Value=""
Sequence="1"/>
Hope this helps!
I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.
For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).
I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.
I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.
Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.
Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).
However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.
[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.
I have a .msi installer (via wix) for an application I'm working on but the application's version number doesn't fit the X.Y.Z version numbers required my MSI's registry Version so the version number is "mangled" into something that does fit and still increases with every release.
I'm okay with this.
msiexec, as part of it's final cleanup, converts this X.Y.Z integer-encoded version number into a string and dumps it into the DisplayVersion registry entry. What I'd like to do is overwrite that string with my own that contains the actual version number of my application.
This certainly seems possible. For example...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\19BF4688EE4961F41A44D0282A2340D9\InstallProperties
DisplayName = (REG_SZ) "Configuration Manager Client"
LocalPackage = (REG_SZ) "C:\Windows\Installer\41202.msi"
DisplayVersion = (REG_SZ) "5.00.7958.1000"
Version = (REG_DWORD) 0x05001f16
The Version is the encoded value of "5.00.7958", so where did the rest of the DisplayVersion string come from?
How, using only wix/msi supported options, do I overwrite DisplayVersion in the registry with my own custom string?
Might be a larger change than what you're looking to make, but...
if you set ARPSYSTEMCOMPONENT=1 in your MSI it won't register an ARP entry for your product. Then you can create your own ARP entry for your product by populating the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] keys in the Registry table of your MSI.
I eventually accomplished this by having the MSI launch a custom installer binary near the end of the installation procedure. That program forks a background copy of itself and exits so that the install can finish.
The background task sleeps for a while to let the installation complete and then directly alters the registry to set DisplayVersion to the desired string.
There's a race condition here but it hasn't been a problem and updating the string isn't essential.
Is it possible to examine an existing installer and determine if it is a WIX / WISE / OtherTechnology installer?
The Windows Installer spec covers this:
Creating Application Summary property
ORCA doesn't show this field for some reason but a quick snippet of code reveals it:
using Microsoft.Deployment.WindowsInstaller;
foreach (string file in Directory.GetFiles(#"C:\windows\installer", "*.msi", SearchOption.TopDirectoryOnly))
{
using (Database database = new Database(file, DatabaseOpenMode.ReadOnly))
{
Console.WriteLine("{0} : {1}", database.ExecutePropertyQuery("ProductName"), database.SummaryInfo.CreatingApp);
}
}
Returns interesting results...
All files can be checked with Windows Explorer: Right-click ยป Properties then Verison or Details. It may not be conclusive. By default, Windows Installer packages built with WiX indicate that in a property viewable with Windows Explorer. For full access to Windows Installer packages, you can use Orca from the Windows SDK or InstMSI, among others. If there are custom action binaries, you can extract those (as DLLs) and check them, too. Custom actions may also use certain naming conventions for properties or custom tables. For example, WiX uses WIX_... for some property names. Similarly, Dialogs might have recognizable names or control layouts.
For executables, try CFF Explorer or UniExtractor. Also, the.exe /? might just tell you.
But, in general, there is no specification or practical requirement that an installer builder or runtime should be identifiable.
I am seeing the following messages during an upgrade using an installer built with InstallShield 2012 Spring:
The InstallShield Wizard will update the installed version (9.01.005) of <our product> to version 9.2.0.53.
The InstallShield Wizard is updating (9.01.005) of <our product> to version 9.2.0.53.
These are messages are based on string resources IDS_IFX_SDWELCOMMESSAGE_UPDATE_WELCOME and IDS_IFX_STATUSEX_STATICTEXT_UPDATEUI. I believe the un-altered string resources would look like this:
The InstallShield Wizard will update the installed version (%VI) of %P to version %VS. To continue, click Next.
The InstallShield Wizard is updating (%VI) of %P to version %VS.
although some resources indicate that the second string resource is "The InstallShield Wizard is updated %VI of %P to version %VS."
The problem is that the old (installed) version number is supposed to be a display string like "9.1.5.2" instead of a formatted version of the internal version number like "9.01.005". As I understand it SdSubstituteProductInfo uses IFX_INSTALLED_DISPLAY_VERSION to populate the %VI substitution in OnUpdateUIBefore's default InstallScript code. And IFX_INSTALLED_DISPLAY_VERSION defaults from IFX_INSTALLED_VERSION, which explains why the preferred display string is not appearing where we would want it to. And I assume SdWelcome (or any dialog or code similarly referencing IFX_INSTALLED_DISPLAY_VERSION), also displays the badly formatted version.
Despite all my searching on the web about the functions, strings, and string IDs mentioned above, I have not found the ideal solution to displaying the properly formatted old version number (DisplayVersion) in the correct format. Some articles suggest hard coding a format string that skips the old version number instead of using a string resource that includes %VI. Others suggest manually formatting the version number as desired and putting the result into IFX_INSTALLED_DISPLAY_VERSION. I know there's a better answer, and I want it to be easier to find next time I or anyone else looks for it.
On the OnBegin InstallScript function, add the following line of InstallScript code as the first line after begin:
RegDBGetItem(REGDB_UNINSTALL_DISPLAY_VERSION, IFX_INSTALLED_DISPLAY_VERSION);
Performing this in OnBegin also ensures that another message not mentioned in the question uses the correct format:
The setup has detected that version %VI of %P is already installed.
This setup installs an earlier version of %P (%VS).
You will have to uninstall the previous version before installing this version.