0

I have been working on setting up a deployment pipeline for a customer using Octopus Deploy. The customer is building an MSI from a Visual Studio 2013 Solution (sadly, by using an old .vdproj, but that's another story). I am wrapping the MSI inside a NuGet package using OctoPack, and publishing it to Octopus internal NuGet repo using NuGet.exe.

I then deploy the package to a given environment using the "Deploy NuGet package" step in Octopus. Now, as a part of the deployment process I also install the MSI using a template from the Octopus Deploy Libray. This template also enables me to uninstall the MSI from the target machine first, if it is installed, which would be a natural step 2 in the deployment process. It uses msiexec to perform operations on the MSI. This is where my question comes in. Consider the following scenario:

  1. I deploy a NuGet package containing version 1.0 of the MSI to the target environment
  2. I later want to deploy a NuGet package containing an updated version 1.1 of the MSI, where a DLL that existed in version 1.0 has been removed, to the same target environment as the bullet above

When uninstalling the old version I need to provide the template with the path to the MSI I want to uninstall. Let us say that version 1.0 does no longer exist in the target environment. Could I point the template to version 1.1 of the MSI, to uninstall version 1.0?

As far as I have understood from the customer, there has been generated a fixed GUID for the MSI, i.e. the GUID of the MSI would be the same every time Visual Studio produces/builds it. Thus, I am wondering if msiexec uses this GUID to uninstall the MSI, and hence, that it does not matter which version of the MSI I point to in the template to get it uninstalled.

Is this a correct understanding? Appreciate any help and clarifications I can get.

nils1k
  • 467
  • 5
  • 20

1 Answers1

1

As far as I can tell, the deployment template is just a way to install an MSI with a bunch of parameters that include the path to the MSI and some error messages if it fails.

You do not need the path to an MSI file to uninstall it. All you need is the ProductCode (a guid) and use msiexec /x {ProductCode}

However....when you increment the ProductVersion of the MSI setup project it will prompt you to change ProductCode etc. If you accept this and set the RemovePreviousVersions property to True you will have an upgrade that is a fresh install but that will also uninstall the older product if it's already installed. So if you do that you don't even need to uninstall the older product because installing the new one does that.

So as far as I can tell, all you need do is use the same template to install each MSI product, 1.0, 1.1 etc, and as long as you accept the changes of ProductCode whwn you increment it wall always just install that new one and uninstall the old one at the same time.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • The template requires the MSI path to be provided to it, and then it uses it as an argument to the _msiexec_ call. I then assume that what is happening under the hood - based on your answer - is that it looks for the ProductCode associated with the given MSI in the registry, and thereafter runs _msiexec /x {ProductCode}_ if it is found? Thanks a lot for the information with regards to changing the ProductVersion and ProductCode, and then use RemovePreviousVersions - I was not aware of that. – nils1k Jul 15 '15 at 05:07
  • I don't really know what the template is doing, but if it thinks it needs the path to an MSI in order to uninstall it, then it's incorrect and making that entire process more difficult. – PhilDW Jul 15 '15 at 16:56
  • I created my own Powershell script to uninstall the MSI using the ProductCode (which is fixed), and it worked. I then tried to use the template script to uninstall MSI v1.0 using MSI v.1.1. That resulted in error code "1638". Working theory: VS2013 changes the **PackageCode** on each build/generated MSI, rendering it impossible (in some cases) to use a new MSI to uninstall an application, which was installed using an older version of the MSI package. I'll investigate that a bit more, but I am leaning towards using the approach suggested by you with regards to _RemovePreviousVersions_ instead. – nils1k Jul 15 '15 at 17:23
  • I ended up using your suggested approach @PhilDW. Thus, marking your answer as accepted. Thnx for your help! – nils1k Jul 17 '15 at 06:41