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.
Related
I have a Visual Basic application, and there are a lot of clients using it. Every XX days I make some updates to the source, and after that, I contact every client to tell them that there is a new version of the application.
But I realize that I have a few clients using an old version of the system.
Is there a way (by this I mean some kind of code, library, functions, etc.) to modify/update my master source, so that if a user is using an old version of the application, some kind of message appears after a successful log in into the system?
Message: "You are using v.1.00 and this is an old version of the
system. Try to update to the newest version, v.2.01"
Additional to the information described above, in my VB application I used some parts of VB.net code for some actions that require connections to Internet web pages.
Any suggestions/help/comments or guidance would be very helpful!
You can't do much about the customers who are already out there.
An easy way to implement this is to have your code retrieve an XML file from a website that you control. That XML file would contain the most recent version number. The code compares its version number to the version in the XML. If they're different, you display a message.
As a bonus, your XML can include a URL that points to the newest version for download.
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.
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.
I have a question whether what i am trying to do is doable, and if the answer is yes how to do it.
I am new to the wix and have been doing some reading on how dynamically to include a folder to an installer and eventually i were able to do a task in nant that uses heat.exe to generate wxs file and latter adding newly generated wxs file to light and candle tasks. This allowed me to add the content of a folder to the msi and subsequently have that folder and its content to be installed.
My problem starts at the point where the folder that i am adding to the msi contains files that has their names already localized (this is a requirement).
When i am adding a file to the directory structure that has its name in Russian for example which is not 1252 codepage i am getting the error:
[exec] ......Templates.wxs(65) : error LGHT0311 : A string was
provided with characters that are not available in the specified
database code page '1252'. Either change these characters to ones that
exist in the database's code page, or update the database's code page
by modifying one of the following attributes: Product/#Codepage,
Module/#Codepage, Patch/#Codepage, PatchCreation/#Codepage, or
WixLocalization/#Codepage.
I tried to set Product/#Codepage to 65001 (UTF-8) however that did not solve the problem.
Eventually what i want to do is to have an ability to add a folder and its content to installer and someone else latter add any number of files that has their names localized into that folder. This way whenever the build runs and subsequent creation of msi happens, msi would contain that folder and its content.
Thank you very much in advance.
This is what WiX.chm says about setting the code page of the MSI database:
You can set this to a valid Windows code page by integer like 1252, or
by web name like Windows-1252. UTF-7 and UTF-8 are not officially
supported because of user interface issues. Unicode is not supported.
As long as you are going to have files named in different languages, that is, File table won't fit into a single Windows code page, you have very little choice. UTF-8 is said to be not officially supported, and this leaves a place for a hope.
If you set the CodePage attribute of the Product element to UTF-8, it will build successfully. And you can install/uninstall the resulting MSI with no problem. I have played a bit with it, and didn't face with any "interface issues" mentioned in that warning above.
Furthermore, I've googled the topic a bit, and found out that InstallShield allows setting the MSI database code page to UTF-8, which is reflected in their docs (search for 'utf-8' on that page). They have more to say about the potential interface issues:
However, some scenarios result in user interface issues. For example,
if an end user specifies the /qb command-line option or uninstalls the
product from Add or Remove Programs, Windows Installer uses very small
fonts to display the user interface text in a UTF-8 database.
They also want to stay on the safe side, hence this setting is false by default (no UTF-8, just ASCII).
So, finally, what would I do in your situation?
if that's a strict requirement to the installation package, use UTF-8 as code page
test all possible scenarios (install / uninstall / repair / upgrade / etc.) on all possible combinations related to localization (English OS, non-English OS, various combinations of current culture and culture UI)
if you face with those ghost "interface issues", show those to your stakeholders, decide whether this is what you can live with and publish known issues if you do
otherwise, recycle this idea and just thank your life for an opportunity to level-up your skills in this area :)
Hope this helps.