Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Wise upgrade doesn't create files

Created: 25 May 2010 • Updated: 03 Jul 2010 | 10 comments
This issue has been solved. See solution.

Hi all!

I am new to using Wise. I work for a company where we have a VB6 windows app that we install using Wise for Windows Installer - Standard Edition.

I am trying to create an upgrade but every time I run the installer, it doesn't write most dlls and also the .exe file to run the app. It also skips all the shortcuts. If I run the installer after removing the old version, then all works fine.

As I said, I am very new to this installer application, so please use as many details as possible.

If someone knows of  a website with detailed tutorial on creating an upgrade package, and a detailed article on UpgradeSync, that would be highly appreciated.

Thanks.
Jean-Philippe

Comments 10 CommentsJump to latest comment

EdT's picture

Have a look at http://www.etlengineering.com/installer/resources.htm
Although the links are quite old many will still be valid and point you at some sites that may help you to understand the upgrade process.
Also, check out the file MSI.CHM that is installed with Wise - you don't mention which version of Wise you are using, but this file should be present in all versions although may not be entirely up to date with the latest Windows Installer SDK version if you have an older version of the Wise tool.
The most reliable method of creating upgrades involves moving the RemoveExistingProducts action to between InstallValidate and InstallInitialize, so that the older version is removed before the newer version is installed - this also makes it less important to get the Upgradesync process correct.
In an ideal world, an upgrade should only need to update files that have changed and remove any content that is no longer required, but for that to work perfectly, components that remain unchanged MUST maintain the same GUID throughout. This can be problematic if a component includes more than one file, and only one file changes, as this tends to cause problems such as removal of files that should not be removed when the installation cleans up at the end.

Are you also new to MSI packaging as well as new to Wise?  If so, and if you will be working on other MSI projects, then it may be of benefit for your employer to send you on a packaging course, as this will get you up to speed more quickly than trying to learn by trial and error.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jpchenot's picture

Thanks a lot EdT for your reply.

Unfortunately, the RemoveExistingProducts is already placed between InstallValidate and InstallInitialize. When going through the install process, I can clearly see that it doesn't install the .exe file. I can see it during a fresh install, but not during an upgrade. I can also see it removing it.

I am using Build: 6.20.0.281

EdT's picture

Running msiexec.exe /i yourinstall.msi /L*v c:\temp\logfile.txt will generate a logfile in c:\temp (or specify any other path if you wish), and then you can check exactly what is going on. All property values are shown at each stage of the install, as are directory values, feature states and all sorts of other relevant information.
When you say you can see the EXE file being removed - is this during an uninstall or during the upgrade?

If during the upgrade, then there must be something else going on which is stopping the new EXE being installed. Perhaps a condition is set on the component holding the EXE that is resolving to false, thus preventing the component being installed. The logfile should show if this is the case. Perhaps the EXE is in a feature which is not being installed because it has the wrong Level set or the feature is not selected for some reason. Again, a log will show this. Maybe the feature is not marked for local installation?

If you need help with the log, make sure you ZIP it before attaching it, and also specify the full name of your EXE.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jpchenot's picture

Thank you again for your response. 

I have been very busy on other stuff, this is why I am late posting this. I am attaching the verbose log file of the installation. I hope you can make sense of it.

The EXE's full name is: MMPxp.exe

AttachmentSize
logfile.zip 197.89 KB
jpchenot's picture

I forgot to mention, that although the installation failed, if I repair the installation, then everything works fine.

EdT's picture

There are many entries of the form:
MSI (c) (A0:C4) [11:14:42:948]: Disallowing installation of component: {32C36D87-3178-4B0F-8397-2CF5D71FC51C} since the same component with higher versioned keyfile exists.

What this tells me is that your upgrade appears to contain many files with lower (ie Older) version numbers than the original project.
The costing process determines what is going to be installed before any system changes are made, so consequently a number of the files do not get installed as they are flagged as being of a lower version than currently on the system.

I would be interested in knowing what REINSTALLMODE is set to in your properties - my guess is that it includes switches such as amus
which would cause a repair to replace all files regardless of version, and this would explain why an install fails but a repair works, and also why uninstalling first also works.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jpchenot's picture

Hi EdT.

I have inserted a screenshot of the properties. I hope this helps.

Thanks.

Jean-Philippe

 

EdT's picture

REINSTALLMODE is not set in the property table, so will default to omus.
Ultimately though, the actual cause of your upgrade issues still appears to be due to the new files having older or lower version numbers than the old files.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jpchenot's picture

I am sorry to bug you will all these questions, but could you tell me which files are older versions?

As far as I am concerned, I have updated all the files to the newer version?

Thanks.

Jean-Philippe

EdT's picture

Without access to your MSI or WSI file I cannot give you this information - but you should be doing this yourself anyway.

First of all, find all the log entries that look like this example:

MSI (c) (A0:C4) [11:14:42:948]: Disallowing installation of component: {32C36D87-3178-4B0F-8397-2CF5D71FC51C} since the same component with higher versioned keyfile exists.

Each entry has a component GUID (Globally Unique IDentifier) like {32C36D87-3178-4B0F-8397-2CF5D71FC51C} in the example above.

In Setup Editor, open the Component table (you can sort on any column by clicking the column title as with many windows apps).
Find each of the component GUIDs from your log, and note the associated component name.
Now open the File Table, which contains a list of files and also the component names that install the file. Sort on the Component column and look for component names from the previous step.
If you have used the project defaults, each file should be in a separate component, so once you have located each component, you will know which file it installs, and each of these files will have older version information than is already on the system.

The file versioning rules can be found in the SDK help file MSI.CHM, but basically, if the files have an internal version then the higher version wins. If one has an internal version and an identically named file lacks an internal version, then the file with an internal version wins. If neither file has an internal version, then the newer file based on date/time wins.  HOWEVER, if the file's modified date is newer than the create date, the file is considered to be user data and is not overwritten. In your situation, when working with DLL and EXE files, this should not be an issue as these are not user data.

The File Table also has a version column which contains the version number of the file, if it has an internal version resource. Cross check this against your updated files. Note that it is the FILE VERSION attribute that is in the version field, and NOT the PRODUCT VERSION attribute.  Note also that the version information is expected to be in xx.yyyy.zzzz.aaaa numeric format.  If you are using any other versioning data then that might also lead to unexpected results, so feel free to give us example of old and new version information for specific DLL and EXE files in your original and upgrade packages.
Finally, you can compare the file table entries in your original and upgrade MSI files and check once again that the version information in each file is correctly extracted.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

SOLUTION