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
Related
we are having an issue using Visual Studio installer project 2017.
We are preparing a setup for an application, and previously we were using InstallShield LT with no issue.
The previous setup is working correctly, as well as updating older version to newer ones.
Trying to reproduce the same behavior with the new tool seems to be quite challenging though.
At the current point, we are able to generate the setup but when we try to install the new version
over the previous one (made with InstalShield) the final folder is empty.
Starting Windows Installer via command line to enable logging, shows that the final phase of the installation
procedure is the remove of previous version, which quite clearly remove the newly installed files.
Installing the same setup file without older version present, or staring after the first update (which
perform a repair) work perfectly, which appear clearly in the log files since there is no RemoveExistingProducts performed.
This is a very small extract with the order of ending Install and THEN Removing the previous version:
Action ended 16:05:03: InstallExecute. Return value 1.
Action 16:05:03: RemoveExistingProducts. Removing applications Application: [1], Command line: [2]
Action start 16:05:03: RemoveExistingProducts.
This behavior seems quite odd to me, and the lack of documentation is not helping.
The development machine (which is also the one we are testing on) is Windows 11.
Any idea is welcome.
Best regards
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.
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
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.