We want to be able to patch our product in the future by producting an ".msp". A particular exe in the .msi is missing version information.
If we create an .msp in the future, will we have problems upgrading that .exe?
I want to know whether we need to add the version information and rebuild the .msi or whether we can avoid it so we don't have to repeat our release process for the .msi.
This post: http://blogs.msdn.com/b/astebner/archive/2005/08/30/458295.aspx
explains that a versioned file will always replace an unversioned one. So, as long as the any updated version of this exe is given version information before it gets put in a .msp, then it should upgrade ok.
Related
I have a WiX bundle that includes the .NET core runtime installer and my product MSI. If I don't tweak anything, I get two entries in the Add/Remove Programs list - one for the bundle and one for the product MSI. I have tried two approaches of showing only one but I run into some issue either way.
Approach #1 - Set MsiPackage attribute "Visible" to "no" in the bundle. This leaves a single entry in Add/Remove Programs (for the bundle).
The problem here is if they do an initial install with the bundle, but later only install the MSI to upgrade, they get 2 entries in the Add/Remove Programs list - the original bundle one and the new product one.
Approach #2 - Set Bundle attributes DisableRemove and DisableModify both to "yes" in the bundle. This gives a single Add/Remove Programs entry - this time for the product MSI, not the bundle.
The problem here is the following sequence:
Install bundle version 10
Uninstall ARP entry (product MSI)
Install bundle version 9
That third step fails because the system sees a version 10 bundle still installed.
Our bundle is 30MB and our product is 3MB. I don't want to have to have every subsequent update download another bundle when I know .NET is already present and not necessary. So what approach can I use to install the bundle originally but later update with an MSI and not run into the issues above?
EDIT: The only approach I can think of is to have a custom action on uninstall which detects whether or not the MSI was dispatched via the bundle (as opposed to standalone) and if it is not, it then uses something like MsiEnumRelatedProducts() to find the product guid for the bundle and inline uninstalls that. Seems super messy and I'm not sure if it would even work or if that invocation would hit some kind of "installer already running" error.
Setting ARPSYSTEMCOMPONENT = 1 in Property Table of MSI installer(or from command line) will prevent it from displaying in Add or Remove programs. So, Your first approach should work after this change.
I think the simplest solution here is to never distribute MSIs and create two versions of the bundle - one that only contains our package, and the other which contains our package plus the .NET runtime. Always mark the embedded MSI as visible=no and have the bundle's entry show up in ARP. This ensures bundles always update bundles, ARP shows the correct version, and that nothing ever gets left behind on an uninstall.
I tried to implement a custom action on MSI uninstall to query the bundle's Upgrade Code and manually remove it. Unfortunately, WiX bundles do not show up to the system as normal products. So while I could manually parse the registry, the more robust APIs like MsiEnumRelatedProducts() cannot be used. Therefore, I think the bundle-of-one is my best solution at this time.
What is the best way to ensure that all developers and the build server are using the latest version of FAKE?
If a build.cmd like the one from FSharp.Data is used, the developer will not be on the latest until they delete FAKE from the packages folder or just delete the whole packages folder.
If you add FAKE as a dependency in .nuget\packages.config, your build.fsx script must include the version information and be updated each time you change versions. You will not automatically get the latest version.
With NuGet 2.8.1 you can remove the "if not exists" parts - NuGet will check (very slowly) if the latest FAKE is installed.
We have a product that we install using WiX, and we have done some re-branding, and I would like to change some things in installation paths and file names.
So, when I make a new version of our installation, the folder with old name remains in Start menu, for example. Also, if I rename a file, the old versions are not deleted, either.
I would like to know what would be the best way of installing files with new names over previous versions of installation.
It sounds like you're doing a major upgrade with a late scheduling of RemoveExistingProducts. When you do that, you have to strictly follow the component rules. My blog post on upgrades covers ways of avoiding that, such as by using an early scheduling of RemoveExistingProducts.
I tried REINSTALLMODE=amus option but it didn't work showing error message Another version of this product is already installed....
If I give INSTALLMODE=vomus option it works well. But, some files are not overwritten, not updated. Maybe it seems to be a file version related problem. Is there really no way to force WI to overwrite its files except doing major upgrade?
Take a look at the MSDN topic REINSTALLMODE property. The "v" is needed by the minor upgrade, the "o" tells it to only overwrite older files and the "a" tells it to reinstall all files regardless of hash or version.
So REINSTALLMODE=vamus should be what you need. However, if the files in the installer were properly versioned this shouldn't be a problem in the first place.
I'm trying to create patches using the method from this tutorial. An issue I'm running into is that I can't install a new patch on top of a previous patch.
I can full install Version A,then patch to Version B. After that I can't patch to Version C.
I can full install Version B, then patch to Version C.
Currently we just do full installs with major updates each time which is working fine, but because of the frequency of our (internal) updates the file size and update time is becoming a burden so we're looking to reduce the update time (both downloading and installing) especially when most of the files don't change.
Edit: Another requirement is that at any given time a full install can be done instead of a patch. The solution I came up with setting a static product code made full installs on top (without manually uninstalling) doesn't work.
If you're not doing a major upgrade, but you are changing versions, you're doing a minor upgrade. To be able to install the next version .msi file over an existing installed previous version, you're going to have to set REINSTALL to a list of modified features somewhere (or to ALL if you're lazy and willing to put up with Windows Installer doing extra work). Often setting REINSTALL handled by the bootstrap, but it is possible to set it in the .msi and reset it to empty ({})when the previous versions are not installed (condition Not Installed).
Looks like the issue was that I was previously making all upgrades major upgrades, but that's not supported with patching. Changing to a static product code rather than auto-generate fixed it.
Edit:
Looks like it solved the first problem of Install A Patch B Patch C not working, but now trying to do a full install of D on top doesn't work.