Is there any way to create minor upgrade (patch file i.e. .msp) or msi based on the old MSI installer and new MSi installer. we want to give the customer to minor upgraded patch (.msp or .msi0, which contains the changes only.
1) I have created (old) Test.msi, based on the 4 .wxs files. these 4 wxs files helps the installation wizard steps. Below are example.
Welcome.wxs file: where we mentioned just welcome message with reference of our project image
Main.wxs file: which contains the actual script of wxs sourcse file for the compononets and features.
InstallerPath.wxs: Where user can select his installation path
LicenseAgrement.wxs: license aggrement mentione dialog file.
2) I have changed the Product verison number only and modified few of my project files, and added few new files.
3) Then I have created (new) Test.msi, based on those 4 .wxs files.
4) By using these old and new installers, how can I genreate patch (.msp or .msi) for minor upgrade.
If you want to do this the two MSIs then this is a starting point:
http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html
Then there's WiX patching:
http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html
Or as a variation on the first one, you could create your own .PCP file and run msimsp from the Windows kit as described here:
https://msdn.microsoft.com/en-us/library/aa367816(v=vs.85).aspx
Just to provide one more link, as an additional information to the last link, PhilDW gave already: Useful, if you want to call the patch generation by an own app/framework for patching. Then you could target the PatchWiz.dll from MS directly without using msimsp.
https://msdn.microsoft.com/en-us/library/aa370590%28v=vs.85%29.aspx
But MsiMsp is a simpler first entry of course. Basically it's just a shell for this dll.
But: Creating .pcp Files is not everybody's favor... reserved for people who want to go deeper here.
But IF you want it, it is probably safer of doing it with code than manually, once you have understood all the points.
Related
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
As I put in title, the question is how does Wix decide to install a particular file?
So I have exe file and when I change something in exe file and rebuild it, it will not get reinstalled if I don't change version. But if I change something in resource file, resource file will be replaced even if I don't change version of my application. So how wix is deciding if he need to replace file during upgrade or not.
I am using wix3.9. MajorUpgrade is schedule afterInstallFinalize.
Versioned files get replaced based on file version, yes, but data files get replaced based on whether you have specified file hash or not. I think WiX generates file hases by default, so this is the overwrite rule:
https://msdn.microsoft.com/en-us/library/aa370532(v=vs.85).aspx
and it's a Windows Installer rule that applies to all MSI settup, not a WiX decision.
P.S. afterInstallFinalize isn't an ideal place. afterInstallExecute is safer, and it will have the same overall result. The issue is that after InstallFinalize means that the new product is installed. If the uninstall of the older product then fails and rolls back you will end up with both old and new products installed, otherwise known as a mess. afterInstallExecute makes everything part of the transaction so you get the original product installed if there is a failure to uninstall it.
I am doing a PoC that involves creating an MSI that has version 1.0.0.0; installing that version to a test machine.
Next, I create another MSI (same name, same product code, different package code, same upgrade code). I merely added a single new .txt file to the sources of the original (v1.0.0.0) MSI. I create the new MSI file using WiX and give it version 1.1.0.0.
All good so far.
Here's a breakdown of the codes so far (from Orca.exe):
ProductCode for msi-v1.0.0.0: {CBCF9206-1539-47B8-9A46-A18C2E40D7A1}
ProductCode for msi-v1.1.0.0: {CBCF9206-1539-47B8-9A46-A18C2E40D7A1}
PackageCode for msi-v1.0.0.0: {AB2B02E4-213E-48C1-9394-E30A75BAF2BE}
PackageCode for msi-v1.1.0.0: {C68D3A88-583A-41BF-A971-CB5E083B8547}
UpgradeCode for msi-v1.0.0.0: {06726F10-FF0B-4534-A008-032A70CACDBB}
UpgradeCode for msi-v1.1.0.0: {06726F10-FF0B-4534-A008-032A70CACDBB}
ProductVersion for msi-v1.0.0.0: 1.0.0.0
ProductVersion for msi-v1.1.0.0: 1.1.0.0
What I am trying to accomplish is the deployment of that new single .txt file via this Minor Upgrade. I know that there is a smaller type update called Small Update, but that is not where this PoC is headed. We will need to change the version number as a part of our end game.
I have this in the Wix script that is used to gen both the MSIs (I really don't think this has anything to do with my issue - just including it because it has the word 'Upgrade' in it):
<MajorUpgrade
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
AllowDowngrades="no"
AllowSameVersionUpgrades="yes"
/>
What I am seeing is that when I run:
msiexec.exe /i FileName.msi REINSTALLMODE=vomus REINSTALL=ALL
I do not get the new single .txt file delivered. I do see that the product version (in appwiz.cpl) changes from 1.0.0.0 to 1.1.0.0, and the cached local MSI file (under C:\Windows\Installer dir) is indeed now version 1.1.0.0 (verified by Orca.exe).
I am puzzled as to why the new single .txt file is not being deployed.
I guess my primary question is: Why won't this Minor Upgrade (i.e. same product code, diff package code, diff product version) deliver the new file?
Thanks in advance for any pointers!
If you broke the component rules you'll see something in the log about it. There'll be SELMGR entries and something about removing components being unsupported. That might happen if you didn't add the file correctly. If you do the minor update install with MSIENFORCEUPGRADECOMPONENTRULES set to 1 on the command line it will fail the install if you broke the rules.
I would read:
What happens if the component rules are broken?
and
Dealing with very large number of files
I'm not a huge opponent of this type of automation. Especially if you are trying to do minor upgrades and patches. Far too often I find people who learn a little bit about installers, don't really want to do it and find it more interesting and "automated" to automate the automation. Don't do it! :) Instead I focus on creating processes that make installer development and maintenance as easy as possible. (See IsWiX on CodePlex) Only the experienced developer knows his code and can make the right choices on how to deploy his resources.
I'm learning about Windows-Installer and Wix, and have a number of questions related to how it works:
If a component GUID changes, but the same files are in the component, what happens on a major upgrade? Do the files get replaced?
If a component is removed from a product, what happens to the associated files on a major upgrade? Do the original files get removed on an uninstall?
Am I correct in saying that a major upgrade will replace all files in all components, regardless of whether the assembly version of the file has changed, and that on small updates and minor upgrades, it only replaces a file if the GUID is the same, and the assembly version of the file has been incremented? What if the file doesn't have an assembly version, like an aspx page?
Suppose that a product was deployed on a machine without using an installer. If you then created an installer, with files of the same name in a component as what's in the installed directory, what happens to those files if you tried an installation? Are they replaced?
Am I correct in saying that if I used a tool like heat to create an xml file with all the files in a directory (like for a website), that you'd have to keep the GUIDs the same (manually or with a script), or you'd only be able to do major upgrades?
If a component GUID changes, but the
same files are in the component,
what happens on a major upgrade?
First, the question is whether the old component gets uninstalled. If you don't configure your upgrade to uninstall previous versions of your product, then the component will not be removed (although its files may be overwritten). See also answer to question 2.
Second, the question is whether the new component will be installed. A component is only installed if its keypath is missing. If the keypath is a versioned file, then a lower version also counts as "missing".
Finally, if the new component was marked for installation, and Windows Installer encounters a file with the same name as the one it is trying to install, the File Versioning Rules determine whether the file is replaced or not. For example, a file with a higher version will not be downgraded.
If a component is removed from a
product, what happens to the
associated files on a major upgrade?
Do the original files get removed on
an uninstall?
Unless you put the right entries in the Upgrade table and the InstallExecuteSequence that tells windows installer to remove the old product, the old components will be left alone. See this blog post by Alex Shevchuk for guidance on how to create an installer in wix that removes old versions.
Am I correct in saying that a major
upgrade will replace all files in all
components ...
No. It depends on whether the old component was removed first, whether the new component was installed depending on the keypath, and the file versioning rules.
Suppose that a product was deployed on
a machine without using an installer.
If you then created an installer, with
files of the same name in a component
as what's in the installed directory,
what happens to those files if you
tried an installation?
Again, it depends on whether the components get installed, depending on their keypath, and the file versioning rules.
Am I correct in saying that if I used
a tool like heat to create an xml file
with all the files in a directory
(like for a website), that you'd have
to keep the GUIDs the same (manually
or with a script), or you'd only be
able to do major upgrades?
Correct. The GUID is the identity of a component, so if you would change the GUID there would exist two components (in the old and new version of your product) that installed the same resources to the same target location. And that's a no-no according to MSDN: "Never create two components that install a resource under the same name and target location."
Learn the Component Rules. They're very easy to break and Windows Installer doesn't enforce them. However if you don't follow the rules, then weird strange voodoo happens.
Easy solution, stick with one file per component and use heat with compile time GUID generation (outputs with Guid="*" uses a stable algorithm, it's not random). Having heat generate GUIDs is random, but GUIDs generated by candle at compile time will be stable (based on filename + path hash or something from memory)
If windows installer finds a file already on disk during install, it will increment the reference count for that file assuming it's a "shared" file. Files are only removed from disk once the reference count returns to zero so if a file already existed, the count may never return to zero and you can get files left lying around even after uninstalling.
I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.
I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.
There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.
So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.
Update: Tried adding the following to the MSI Command Line value in the Release section:
REINSTALLMODE=vamus
This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.
In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.
The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.
Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.
If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).
The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.
See my answer here.
I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus
You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.