2

My project needs to have the ability to install 2 versions or more simultaneously. as far as i can find, the solution i have found is changing the upgrade code for each build of the installer.

however i want to do this automatically. in regular GUID i just use "*" but this won't work for upgradecode. is there a way to generate new upgradecode in every wix prebuild or any other solution? 

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension" xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">
  <Bundle Name="Prog" Version="1.2.1.16" Manufacturer="Gilad Corporation" UpgradeCode="{7E71F945-BA46-4872-A6B2-AF992FFDF2D0}">
    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
      <bal:WixStandardBootstrapperApplication LicenseFile="..\SetupProject\Gilad.rtf" />
    </BootstrapperApplicationRef>
    <Chain>
      <!-- TODO: Define the list of chained packages. -->
      <PackageGroupRef Id="Netfx45FullPackage" />
    </Chain>
  </Bundle>
Gilad
  • 6,437
  • 14
  • 61
  • 119
  • It's the ProductCode that defines the uniqueness of a product, not the UpgradeCode. – PhilDW May 07 '14 at 23:08
  • It would be nice if you can describe why you need multiple instances. There may be better ways of achieving this by altering the application design. – Stein Åsmul May 08 '14 at 05:02
  • @Glytzhkof i have an application where i create bug fixes and different new features. since my users needs to be able to work on 2 different version i don't want them just to upgrade. i want them to be able to install 2 or more versions side by side. – Gilad May 08 '14 at 05:04
  • What I would do for this would be to create a release version and a QA version of the setup that can co-exist on the same machine. Using instances would quickly get out of hand in my opinion. – Stein Åsmul May 08 '14 at 05:15

3 Answers3

5

Just to answer the "how to auto-generate the UpgradeCode" question, if you are using msbuild, you can do something like this in your project:

<PropertyGroup>
  <NewUpgradeCode>$([System.Guid]::NewGuid())</NewUpgradeCode>
</PropertyGroup>

<DefineConstants>NewUpgradeCode=$(NewUpgradeCode)</DefineConstants>

and in the bundle:

<Bundle Name="!(bind.PackageName.Package)"
        Version="!(bind.PackageVersion.Package)"
        Manufacturer="!(bind.PackageManufacturer.Package)"
        UpgradeCode="$(var.NewUpgradeCode)">

I'm actually using this in a template-like bundle for packaging some one-off packages, where I don't want them to be associated with one another. However, I still want them to have an upgrade code in case I need to upgrade them later.

I can't say whether this is the best solution for this use case, but seems to work.

Dave Andersen
  • 5,337
  • 3
  • 30
  • 29
  • I used this with success, but im not sure I understand what I did. You can use custom node in wixproj file (here NewUpgradeCode)? and [System.Guid]::NewGuid() is a powershell command? – David Levy Mar 15 '17 at 21:28
  • I wouldn't say it's a powershell command, since powershell is not invoked, but MSBuild is able to call into .NET classes the same as powershell, and uses a similar syntax. All it does it generate a random guid and passes it in as a WixVariable. – Dave Andersen Mar 15 '17 at 21:40
4

I am not 100% sure if you want to deliver different editions / language versions of your application, or if you want to install the same setup several times side-by-side. It sounds like you want to achive the latter. Let me try to briefly explain both scenarios.

First the basics:

  • Package Code: identifies a unique MSI file (hence it should always change for each recompile)
  • Product Code: identifies a unique product edition. Different flavors of the same product (such as english, german, french editions) tend to have different product codes.
  • Upgrade Code: identifies a family of related products. In essence a group of product codes.

Different applications editions / languages: If what you want is to install a different language version of your setup - say you deliver English, French and German versions, you can do that by keeping the upgrade code the same for all of them, but use different product codes and package codes for each setup. This allows each setup to easily uninstall another if it is already present on the machine.

Side-By-Side installations: I don't like this concept since it tends to indicate an error in the setup design in my opinion, but the concept of "instance transforms" should be able to achieve what you probably refer to. 

<InstanceTransforms Property="INSTANCEID">
   <Instance Id="Install2" ProductCode="*" 
             UpgradeCode="guid-goes-here" ProductName="Product" />
</InstanceTransforms>
Community
  • 1
  • 1
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • I want to explain a little why this is my design. I have a application with an algorithm. the algorithm goes to hardware. so if i want have a backward compatible option. so if i install the app and 2 month later i want to install the new version and the old version side by side i will have the option. – Gilad May 08 '14 at 09:10
1

Be careful with what you are trying to achieve. Are you trying to install multiple instances of the same software? Or do you have different applications of this program which might need to be installed onto the same machine.

MSI is not designed to allow side by side installation of the same software.

As @Glytzhokof has mentioned, you have three separate codes in the MSI which you need to address.

Usually you would generate an upgrade code which never changes with the life of your MSI. If you try to install two versions of an MSI that have the same upgrade code then you will trigger the upgrade logic in MSI (i.e to upgrade an existing installation or prevent a rollback unless you explicitly enable this)

What you are trying to achieve would require a unique product, package and upgrade code for all software packages (to allow a side by side installation of V1 and V2 of the software) However you need to be very careful with how you choose to allow side by side. I've seen versioning where 1.2.x have the same upgrade code, but 1.3.x has a new upgrade code allowing a side by side installation.

Sounds like you are in for some fun.

Spence
  • 28,526
  • 15
  • 68
  • 103