1

I would like to deploy mutually exclusive applications into mutually exclusive environments based on User Input in a WIX project. The research I've done tells me I can't do this using conditions http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/ This seems like a fairly common question and a definitive best practice would be valuable.

I've implemented this using features and publishing events per the above article. The events in my UI are below.

In my situation I'm installing one of two mutually exclusive web applications into one of three different environments. I did this by creating 8 features, 1 each for the applications and all files except web.config and 6 for the web.config files depending on the application being installed and the environment being installed into. I had to include a condition in each of the features to pass ICE validation even though they are controlled by publish elements below because they are being installed to a directory named the same on different servers. Is there a better way or is this the standard practice for this sort of situation?

      <Publish Event="AddLocal" Value="WebApp"><![CDATA[ServerType="Web"]]></Publish>
      <Publish Event="Remove" Value="WebApp"><![CDATA[ServerType<>"Web"]]></Publish>
      <Publish Event="AddLocal" Value="DataApp"><![CDATA[ServerType="App"]]></Publish>
      <Publish Event="Remove" Value="DataApp"><![CDATA[ServerType<>"App"]]></Publish>
      <Publish Event="AddLocal" Value="WebDevConfigFeature"><![CDATA[ServerType="Web" AND Environment="Dev" ]]></Publish>
      <Publish Event="Remove" Value="WebDevConfigFeature"><![CDATA[ServerType<>"Web" OR Environment<>"Dev"]]></Publish>
      <Publish Event="AddLocal" Value="WebQAConfigFeature"><![CDATA[ServerType="Web" AND Environment="QA" ]]></Publish>
      <Publish Event="Remove" Value="WebQAConfigFeature"><![CDATA[ServerType<>"Web" OR Environment<>"QA"]]></Publish>
      <Publish Event="AddLocal" Value="WebProdConfigFeature"><![CDATA[ServerType="Web" AND Environment="Prod" ]]></Publish>
      <Publish Event="Remove" Value="WebProdConfigFeature"><![CDATA[ServerType<>"Web" OR Environment<>"Prod"]]></Publish>
      <Publish Event="AddLocal" Value="AppDevConfigFeature"><![CDATA[ServerType="App" AND Environment="Dev" ]]></Publish>
      <Publish Event="Remove" Value="AppDevConfigFeature"><![CDATA[ServerType<>"App" OR Environment<>"Dev"]]></Publish>
      <Publish Event="AddLocal" Value="AppQAConfigFeature"><![CDATA[ServerType="App" AND Environment="QA" ]]></Publish>
      <Publish Event="Remove" Value="AppQAConfigFeature"><![CDATA[ServerType<>"App" OR Environment<>"QA"]]></Publish>
      <Publish Event="AddLocal" Value="AppProdConfigFeature"><![CDATA[ServerType="App" AND Environment="Prod" ]]></Publish>
      <Publish Event="Remove" Value="AppProdConfigFeature"><![CDATA[ServerType<>"App" OR Environment<>"Prod"]]></Publish>
      <Publish Event="EndDialog" Value="Return">1</Publish>
atevans
  • 373
  • 1
  • 9

3 Answers3

2

The trick I like to do is have 2 components with 2 different key files

c1 -> f1 ( web.config.dev ) c2 -> f2 ( web.config.qa ) c3 -> f3 ( web.config.prod )

each of these files are then given a copy file element of web.config and a mutually exclusive condition

DEPLOYMENTTYPE~="DEV" DEPLOYMENTTYPE~="QA" DEPLOYMENTTYPE~="PROD"

The result is no more then 1 of these components will get installed. You might get a web.config.dev and a web.config and it'll work.

All of this can be done using a single feature.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • This sounds perfect. Is there a trick to getting the conditions to evaluate after CostFinalize though? In my dialog is where I set the variables and I can't show my dialog until after CostFinalize. – atevans May 09 '12 at 19:38
  • You'd have to use feature conditions instead of component conditions and then use the ADDLOCAL and REMOVE control events to conditionally turn the features on and off. – Christopher Painter May 09 '12 at 20:07
  • Okay, that's where I'm at right now, my concern is the "feature bloat". I've got 8 features that I have to control using the control events. Seems like in spite of the failings this is the standard practice. Thanks for your help. – atevans May 10 '12 at 20:14
1

Depending on whether you want to choose the files by environment (no questions), indirect user input (related question), or direct user input (feature selection), there are various approaches to take. Christopher Painter's approach is good for the first two, but for feature selection, you might try the technique described on this InstallTalk blog post.

Michael Urman
  • 15,737
  • 2
  • 28
  • 44
0

Personally I would split the two separate applications out into two msi's with a common library for duplicated code. They can be bootstrapped together if required using burn.

Also there is no need to stored all the different versions of the web.config as the differing values can be modified at install-time using either the XmlFile or XmlConfig elements. The advantage of this method of modifying the web.config files is the values can also be passed into the installer on the command-line if they ever change, preventing the msi's from having to be rebuilt just for config changes. To make things easier you can even create dialogs to set them rather than passing them in via msiexec.

caveman_dick
  • 6,302
  • 3
  • 34
  • 49
  • My only issue here is that I'm using the Web Transformations built into WebDeploy and would rather not have that logic in two different places. – atevans May 09 '12 at 19:35
  • BTW Splitting into two MSIs is certainly doable though. The two different web apps are part of the same application so I thought I would ease the burden on our Deployment guy by giving him only one MSI. – atevans May 09 '12 at 19:43
  • I follow two patterns depending on the needs of the situation. Yes, you can use XmlConfig elements to apply transforms to a single XML and that's very good in "shrinkwrap" scenarios. However it's painful in scaling to many attributes but painless in many values. In some situations ( like in-house IT applications ) it's better to just have multiple config files. It scales to many many attributes but very few values. It allows in house dev's to maintain XML files without any knowledge of the installer. Make sense? – Christopher Painter May 09 '12 at 20:09