I have a question concerning software updates. Currently I install new releases into a different folder each time. The user is then required to re-enter configuration parameters. This of course is not too optimal. The software is Windows forms and I use the settings. Settings file.
So the question is what happens if I install a newer version into the same folder as a previous install? Will files just get replaced? What about if I have added settings in the new version? Will they be merged?
Anything to watch out for?
Thanks
When the MSIs are related, typically you can only have one instance of it installed at a time. If that's the case, first the earlier version may be uninstalled, so the question is whether the files that store the settings are removed by uninstalling your MSI.
If the MSIs are not related, you can get into a world of pain by overlapping their installations (probably breaking component rules by having two different components describe the same file in the same location, but with a different component code), yet the core question comes down to the same thing: will the updated installation lay down the file that stores the settings.
These are likely the same question, as the easiest way to remove or install a file is by including it in the MSI directly. (There are other ways, but I'm assuming you're not using those yet.) If the file is not part of the installation, nothing will happen to it, and the answer to your question comes down to what your application does when it runs with a settings file created in a different version. If the file is part of the installation, and component rules are not being broken, it will either be uninstalled then freshly installed (wiping any configuration), or per File Versioning Rules and Default File Versioning, the file will either be left untouched or completely replaced with the new version. Windows Installer doesn't know how to merge your settings file.
Thanks for taking the time to answer my question.
So bottom line I should just avoid these issues and install in another folder. I should also make a copy of the settings and put them in my own file which can be used to update my new installation. That would be the safest route I guess.
Thanks
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
Not too long ago I got a new job working on a tool that the company created to make people's lives easier when working on AWR.
I have successfully done multiple fixes and improvements which I was able to distribute via HotFix installers (simply overwrite the files that are already there).
My latest change/addition to the tool requires I create a complete installer for the tool. This particular tool always installs 2 versions, the current/new and the previous/old, to give a smoother transition to users. I have never done an installer before so I am learning as I go.
I was able to create an installer using the previous installshield project by simply updating/adding/removing files and folders. This works great when there is no version of the tool installed on the computer and there are no files/folders of any version of it on the installation locations.
I looked online and found that to make an installer that will install over a previous version I would need to do a major upgrade with installshield, which I did do after reading that. Now the installer successfully installs over the old version, it successfully places the new files and folders on their locations but always leaves one particular empty folder behind, the one for the 1.1.1 version.
That didn't seem like a problem until I realized that the .exe failed to modify the .ini file that it needs to modify to let AWR know where to look for the scripts. I looked through the .exe code and after running some tests, running it alone, I realized the .exe is not the problem, it does the job correctly. After doing many tests I found that as long as those empty folders exist the .ini files cannot be modified. I have no clue why since the .ini file is pretty much a .txt file and it makes no sense for there to be some sort of dependency on the 1.1.1 folder.
So my problem is one of two, either I have to figure out a way to make sure that the upgrade deletes those 1.1.1 folders or find a way to modify the .ini files with those folders still there. I have looked online and every solution requires me/the user to manually do something and I am being asked to make the installer simply work when used. They are asking me to make it so the installer takes care of everything and the user should not do anything except run the installer.
Since the installer works correctly as long as those folders are not there I figured making sure the installer removes them is the best way but I am stuck and I do not know how to proceed.
Thank you for any advice and help you can provide with this issue.
Solution:
Deleted all files I needed to make sure were updated from the components list and re-added them to the installshield project.
Since doing that everything was updated correctly and the folders were removed since the .exe was the correct one.
I'm currently working with InstallShield to deploy a .NET Winforms app. I am new to InstallShield and have not enjoyed the learning curve. The Winforms app has three related DLL's which are not getting updated during a minor upgrade. For a minor upgrade I am changing the version from 1.0.001 to 1.0.002 for example. The package code is being changed for each build automatically.
I have tried adding the dll's to the [INSTALLDIR] and setting the property to "always overwrite". For some reason this causes the upgrade to also not update the main exe.
Tried changing the product code to force a major upgrade. This installed a new version alongside the old version, but the new version still had the old dll's.
Tried changing ReinstallMode from "omus" to "vomus". This had no effect at all.
Tried using REINSTALL=ALL, REINSTALLMODE=vomus. This did not update the dll's and also caused new installs to fail with message that application "is not marked for installation".
Tried changing the version from 1.0.00x to 1.1.00x. dll's still not updated.
I notice that when I view properties of these dll files, they have File Version = 1.0.0.0 and Product Version 1.0.0.0. Do I need to manually increase these versions in order for InstallShield to recognize that they have been updated?
Use one component per file and set each file to be keyfile in its own component. This avoid all sorts of component referencing and file replacement issues. Be aware that multi-file assemblies must share the same component as they are intended as one "atomic" file system unit.
In addition you must also increment the version number for each build or set REINSTALLMODE to emus instead of the default omus. Never use amus.
My advice: go with the file version updates - it is much more reliable. Like you state the File Version is used, it must be incremented. I like to auto increment the build version number (last digit). It has been a while, but I think you just replace the number with * and it auto increments. I think you can do this from the Visual Studio project property view.
Maybe read up on the file versioning rules as well. Essentially versioned files are version compared, and for unversioned files the create and modify date stamps are compared and the file is replaced if it is unchanged on disk. More sample info.
Remove the "always overwrite" flag you enabled for all the files you enabled it for. This flag may work poorly with patches if you ever need them and also with other features.
When a major upgrade creates two side-by-side installations it hasn't worked. What you are left with are two different products installed at the same time. There is good inline help in Installshield itself with regards to how a major upgrade is set up. Which version of Installshield are you using? The version bundled with Visual Studio may not feature this help material.
A note on major upgrades and "reverted files":
A warning on a classic major upgrade issue: be aware that changed, unversioned files not set to be permanent on original install may be uninstalled during a major upgrade and then reinstalled yielding the impression that they have been replaced, but they are actually deleted and recreated. These are typically important settings files like XML files or similar - and people struggle with this issue a lot. Major upgrades are essentially a sequence. The old product is uninstalled, and then the new one is installed or vice versa. In the former case the files may be uninstalled first and then recreated. This does not happen in the latter case if component referencing is done right because the files that are matching between products are not uninstalled, but retained and then overwritten if need be (according to the file replacement / versioning rules).
I have an InstallShield InstallScript MSI project that contains the FLEXnet Connect without Software Manager merge module. The version of this product is 6.0.32. I created a second installer for version 6.1 that also contains the FLEXnet Connect without Software Manager merge module. When I perform a major upgrade on a system that contains the 6.0.32 version I get a message in the MSI log stating:
Disallowing installation of component: {FF970098-B748-427B-B946-AA8E1A1F82AD} since the same component with higher versioned keyfile exists
The component is referencing the isusweb.dll file located in the FLEXnet Connect folder.
It looks like this check occurs prior to the 6.0.32 product being removed. The install proceeds to remove the 6.0.32 product, which removes isusweb.dll. During the 6.1 install the isusweb.dll is not put back because of the component version check.
The upgrade succeeds. When I attempt to run the application from a shortcut it verifies the components. Since the isusweb.dll is missing the MSI attempts a repair, then cannot find the MSI and does not allow the application to open.
Is there some way to get the merge module to always overwrite?
This sounds suspiciously like this bug:
http://support.microsoft.com/kb/905238/en-us
and I've come across this bug and you do see that log message, and RemoveExistingProducts is early in the install. It decides to not install the file based on the higher version being there, but doesn't re-evaluate that decision after the REP removes it. Then a repair restores it when you use a shortcut. The bug should apply only to files in the GAC or SxS, so that's a bit puzzling.
If you can schedule REP at the end of the transaction sequence (InstallExecute, REP, InstallFinalize) that should fix it - might be worth a try, all other effects of the move being ok.
Merge modules don't get installed, they get merged. Product MSI's get installed. One of the problems with using third party merge modules is if they have a bug, there isn't much you can do about it.
I'd consider creating an MSI solely for the purpose of encapsulating this MSM. Then I'd create a setup prereq or suite installer to install this MSI apart from your product MSI.
You have got two really good answers already, but to try and synthesize:
It really sounds like a buggy merge module. Phil suggests to fix your REP placement in the InstallExecuteSequence to work around the bug. Chris suggests to put the faulty merge module in its own setup. I agree with both and think you should follow both suggestions:
Remove the merge module from your main setup.
Create a new setup and add the faulty merge module and ensure the right REP sequencing.
For the REP fix to work your component referencing must be 100% correct - now and in the future. To eliminate this as a problem creating a separate setup allows you to contain the buggy module inside its own MSI. This will help you avoid re-activating the bug by mistake or by changed design in the future - and the latter is never unlikely.
As Chris says: a merge module isn't delivered, it is merged. An updated merge module may be available for all I know, but even then it is wise to contain it. Especially when you are dealing with the GAC (Global Assembly Cache).
Another solution that I applied when encountered this bug was to set to update the "Version" column from File table, in the merge module, using Orca. Set that to the maximum 65535.65535.65535.65535, this will force the upgrade to always install the DLL from the merge module.
I have created an installation package using Wix which installs a Windows service on the user's machine. Currently, the files are being installed to [%ProgramFiles%\APLICATIONNAME].
Is this a future proof way of structuring an installation folder?
Should I be installing to [%ProgramFiles%\APLICATIONNAME\VERSION_NUMBER] instead?
Any recommendations would be greatly appreciated.
Thanks,
Arnie
Update:
Side-by-side installation of different versions will not be supported.
Version specific folders are no good. What you need to do is make sure all subsequent installers upgrade properly over the previous versions so that different folders are not required.
You may want to do something like ProgFiles\App 1.0 using the major and minor version number if you want to allow side by side installs of different versions. But with all of this it should ultimately be up to the user where the installed files end up.
As an additional note, if you are storing application data in the registry of the %AppData% folders then those are sensible places to use versioned folder names,
eg. %AppData%\Manufacturer\Application\1.0 and HKCU\Manufacturer\Product\1.0 or whatever.
We use this with a folder for each major release, this way if we decide to change our registry structure, rework data file formats, etc we only have to ensure compatibility between minor releases. Major releases can use a separate procedure to help the user migrate from a 2.x to 3.x release.
If side-by-side installation of different versions will not be supported I think [%ProgramFiles%\APLICATIONNAME] is good enough. However personally I prefer [%ProgramFiles%\COMPANYNAME\APLICATIONNAME].