I have a Visual Studio 2010 Setup Project and I am trying to create an Upgrade to a new version of my software.
The upgrade process is running. I properly updated the Version Number, which caused an update of the Product Code. RemovePreviousVersions is also True.
My problem is that when I upgrade my software, there is one file that may have changed on the local filesystem, in the course of running the software. I'm finding that, because the file changed, the installer refuses to overwrite it.
I want my installer to force this file to be overwritten with the new version.
Is there something I can do -- within Visual Studio, with Orca, or otherwise -- to force a file to be overwritten even if it has changed?
UPDATE: In Orca, I noticed that the "File" table includes a "FileSize" column. I believe this might be the reason the file is being ignored. If the size of the file has changed, it doesn't match. Is there any way to override this?
You can't safely change the Windows Installer replace rules, but you are getting into this situation because the upgrade mechanism first installs the upgrade on top of the older product (invoking file replacement rules) then uninstalls the old product, ref counting down and removing the product. It's the "on top" that is the issue. If you move RemoveExistingProducts in the InstallExecuteSequence from just before InstallFinalize to just after InstallInitialize you will get a complete uninstall of the older product then the install of the new upgrade. That may not work if you are expecting to keep data files around.
Otherwise you could use the RemoveFile table with Orca. You'd add an entry targeting the Component name corresponding to the file (look in the File table, and there may already be some entries in the RemoveFile table as examples). You'd set the value to be Remove on Install. The RemoveFiles action occurs before the new files are installed, so it should work.
Related
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 had created a setup 7.7.0 using Visual Studio 2010. The setup installed all the files correctly. Now I create the setup 7.8.0. The Upgrade Code for both 7.7.0 and 7.8.0 is the same and the Product Code is different.
In the Launch Conditions Editor, I have added a search condition FILEEXISTS1 that searches for a file, d.xml, in a particular location on the system. In the File System Editor, I added the condition "NOT FILEEXISTS1" on the d.xml file to evaluate if the file is present and if it is present, to not install d.xml.
My problem is that having this condition removes the d.xml file altogether when 7.8.0 is installed. However, if I just have the search condition FILEEXISTS1 that searches for the file, but does not evaluate it (meaning I do not have the condition property NOT FILEEXISTS1 evaluated on d.xml), then the file is not overwritten.
I am confused by this behavior. Am I missing something here?
Does anyone know why this happens? Any help would be greatly appreciated.
A major upgrade automatically uninstalls the old version before installing your new one. This means that the old file is removed and a new one is installed.
So conditioning your new file is not a good approach for preserving the original one.
To determine if the new file is installed, Windows Installer uses the file versioning rules for the component key path. Here is an article with more details: http://setupanddeployment.com/windows-installer-bugs/missing-files-upgrade
A solution for preserving your old file is to create a backup before the upgrade starts and restore that backup after the upgrade finishes. This can be done through custom actions. Perhaps this will help: http://setupanddeployment.com/installer-concepts/preserve-data-install
Hopefully I can explain this clearly:
I have a Visual Studio Setup Project (C++), my current build scripts do the following:
update the version numbers
update the PackageCode
update the ProductCode
This has worked without any problems in the past (approximately 20 releases).
I just did a new release where a custom action was removed (which was included in most of the previous releases). My build process was the same as above.
Now when I install I get a duplicate entry in Windows Add and Remove Programs.
ie:
previous version was 1.0.6.2 and is installed on the computer.
I then install new version 1.0.7.0 (has custom action removed)
Add and remove programs lists 1.0.6 and 1.0.7.
Any idea what I need to do to fix this? I expect what is happening is that the new version is causing the uninstaller for 1.0.6.2 to run, but is not getting it to remove the FeatureComponents that were removed as part of 1.0.7.0.
Is there a way to force their removal?
Make sure that both versions have the same installation type (per-user or per-machine). This is controlled through ALLUSERS installer property or InstalAllUsers setup project property.
Also, they should use the same UpgradeCode. You can check it in Property table by opening the MSI files with Orca.
If these conditions are met and the problem persists, try creating a verbose log and see what happens when FindRelatedProducts and RemoveExistingProducts actions are executed.
A new version of our product (a software package) has been released recently. To expand functionality, we developed a plugin afterwards. Now we would like to deploy these files (two new files and an updated version of an existing file) as hotfix (or update) with MSI patch (msp). I downloaded a blank PCP file from MSDN website and made some changes in it. The changes involve the following tables:
ImageFamilies
PatchMetadata
PatchSequence
Properties
TargetImages
UpgradedImages
All the other tables remain blank.
Then, I managed to create an msp file with this PCP file based on two versions of the admin image of the software package, both of which were built from Visual Studio setup project (VS 2010). The difference between these two msi packages are that I replaced a file and added two new files in, but nothing else. I didn't change the product code (GUID), the upgrade code (GUID), nor the version number.
Then I was trying to install this msp file on top of the released version.
The first screen appearing is asking to Repair or Remove the product. This is not what we want. We want the installer is like a fresh installation, including showing the licence agreement. How do I define the UI for MSI patch?
During the installation of the patch, I got an error message as below, then the installation failed:
Error 1001. Exception occurred while initializing the installation: System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\WINDOWS\system32\Files\BPS\TestApp' or one of its dependencies. This system cannot find the file specified.
BPS is the folder where we install our product in [ProgramFilesFolder]. I wondered why MSI was trying to search in "C:\Windows\system32" for files installed in [ProgramFilesFolder]. In addition, the changed files in the hotfix are located in somewhere else ([CommonAppDataFolder]) instead of in this "BPS" folder.
Can anyone help me with these problems? If any more information is needed to identify the issues, please let me know. Any thoughts, advices, suggestions would be very much appreciated.
Dan
The first screen appearing is asking
to Repair or Remove the product. This
is not what we want.
In the upgrade package increase the Product Version. This way you will use a minor upgrade instead of a small update.
You can also try using the MSIEXEC command line to apply the patch:
http://msdn.microsoft.com/en-us/library/aa367574(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa367575(VS.85).aspx
During the installation of the patch,
I got an error message as below, then
the installation failed
Is there something in your installer using that file? Perhaps a custom action? Try looking in the log to see what action tries to access that file.
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.