Doctor Deploys Blog

In .NET 4 we have quite a few deployment options available for redistribution. There are basically 2 pivots. The Client/Full profiles and 32bit/32+64bit packages.

Here are the four redistributable options and their corresponding sizes.

The Client Profile is targeted to contain the parts of the .NET Framework that are used by most client applications and gives people the option to carry a little less payload if they use less of the Framework.

The 32+64bit packages are designed to give the option of installing either profile on any target machine regardless of OS architecture. On the other hand, if someone is targeting a pure 32bit customer segment, the 32bit package gives the option of reduced size with reduced breath of deployment.

Original post by Peter Marcu

Bob posted a blog entry how to use TortoiseHg to access the WiX source code on CodePlex. I thought the blog post was great but suffered from one fundamental flaw. It required you to do a whole bunch of mouse clicking. Here’s how to get into the WiX toolset source code using the command-line.

Read More…

Original post by Rob Mensching

There was a small change made to the WiX toolset recently that added dialogs to the WixUI library that are shown when patching. That part of the change was straight forward, the tricky part was that the dialog needed to support all the existing languages or the patch UI could come up in a different language (English) than the initial install. Fortunately, the Office Communications Server team (who was adding the patch dialog) was willing to localize the dialogs in all languages they support, 30+ of them. That’s good news but there is some bad news.

Read More…

Original post by Rob Mensching

Since it’s launch in 2004, the WiX toolset has been completely hosted on SourceForge.net. SourceForge is fine but feels a bit clunky and a little behind the times. About a year ago I started looking at alternatives since open source hosting platforms are now a dime a dozen. In the end, I didn’t find a single platform that offered everything I wanted. However, CodePlex provides Mercurial and a much better file release system than SourceForge so I decided to use those for WiX. For now bugs and the mailing list do not move (I’m still looking).

Original post by Rob Mensching

This question comes up so often, I should have written this blog entry years ago. The root issue is that the Windows Installer does not save Property values for you. That means if the user enters values in the install UI or passes them on the command-line, those values will be not be present during repair, upgrade nor uninstall. That last one, uninstall, catches people all the time. So let’s solve the problem simply then solve it completely.

The Simple Solution

As is often the case, the simple solution is not the correct solution but it definitely shows us the way. In this case, what we’re going to do is squirrel away the user provided Property values in registry keys and use a RegistrySearch to read them back out for repair, upgrade and uninstall. The code for this simple solution is pretty straight forward.

   1:  <?xml version='1.0'?>

   2:  <Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'>

   3:  <Product Id='*' Name='Demo Remember Property' Language='1033'

   4:           Version='0.1.0.0' Manufacturer='RobMensching.com LLC'

   5:           UpgradeCode='c2e7dfa4-3faf-4c41-9bcc-eabf7657a2b9'>

   6:    <Package InstallScope='perUser' InstallerVersion='200' />

   7:   

   8:    <MajorUpgrade DowngradeErrorMessage="A newer version already installed" />

   9:   

  10:    <Property Id='REMEMBERME'>

  11:      <RegistrySearch Id='RememberProperty' Root='HKCU'

  12:                      Key='SOFTWAREWixDemoRememberProperty'

  13:                      Name='Remembered' Type='raw' />

  14:    </Property>

  15:   

  16:    <Feature Id='MainFeature' Level='1'>

  17:      <Component Directory='ApplicationFolder'>

  18:        <RegistryValue Root='HKCU' Key='SOFTWAREWixDemoRememberProperty'

  19:                       Name='Remembered' Value='[REMEMBERME]'

  20:                       Type='string' />

  21:        <RemoveFolder Id='CleanupApplicationFolder' On='uninstall' />

  22:      </Component>

  23:    </Feature>

  24:  </Product>

  25:   

  26:  <Fragment>

  27:    <Media Id='1' />

  28:    <Directory Id='TARGETDIR' Name='SourceDir'>

  29:      <Directory Id="LocalAppDataFolder" Name="AppData">

  30:        <Directory Id='ApplicationFolder' Name='Demo Remember Property' />

  31:      </Directory>

  32:    </Directory>

  33:  </Fragment>

  34:  </Wix>

That’s a fully working installation, so I’ll comment on the interesting parts of the code:

• line 6: Note that I used a per-user install for this example because it saved me UAC prompts during testing. If your install is per-machine use HKLM instead of HKCU for the various registry roots we’ll discuss next.
• line 8: I’m using the new WiX v3.5 language simplifications with the MajorUpgrade element and the absent Component/@Id,@Guid attributes. If you’re using WiX v3.0 you’ll have to type more stuff.
• line 10: This is the Property that we’ll remember. In this case, I have no default value but you could add one if your scenario required it. You can have as many remembered Properties as you want, you just add more registry keys.
• line 11: This is the registry search that will reload our Property on repair, upgrade and uninstall scenarios. On the initial install the registry key will be missing so the Property will use its default value (which in my case is nothing).
• line 18: This is the registry key that remembers our Property. Put the registry key in a place that is logical for you. Again, remember to make your Root=’HKLM’ when doing a per-machine install.
• line 21: I added the RemoveFolder element to make ICE64 happy.
• line 26: Notice that I pulled the directory tree into a separate Fragment. I did this just to keep the rest of the code a bit more tidy. I also added the Media element to make ICE71 happy even though there are no files to install.

Cool. Now let’s walk through our install, repair, uninstall scenarios and see the simple solution work. I’ll show you the command I executed then the important pieces of the log files that demonstrate how it works. First install and it’s log file:

msiexec /l*v i.txt /i demo.msi REMEMBERME=1
MSI (c) (A0:3C) [21:31:02:897]: Command Line: REMEMBERME=1 CURRENTDIRECTORY=...
MSI (c) (A0:3C) [21:31:02:898]: PROPERTY CHANGE: Adding REMEMBERME property. Its value is '1'.
MSI (c) (A0:3C) [21:31:02:918]: Switching to server: REMEMBERME="1" TARGETDIR=...
MSI (s) (90:F0) [21:31:02:945]: Command Line: REMEMBERME=1 TARGETDIR=...
Property(S): REMEMBERME = 1
Property(C): REMEMBERME = 1

Now, repair and it’s log file (Note: that I only had to pass REINSTALLMODE="u" because we only need to repair our per-user registry keys) :

msiexec /l*v r.txt /i demo.msi REINSTALL=ALL REINSTALLMODE=u
Action start 21:35:52: AppSearch.
AppSearch: Property: REMEMBERME, Signature: RememberProperty
MSI (c) (C0:A0) [21:35:52:722]: PROPERTY CHANGE: Adding REMEMBERME property. Its value is '1'.
MSI (c) (C0:A0) [21:35:52:727]: Switching to server: REMEMBERME="1" TARGETDIR=...
MSI (s) (90:90) [21:35:52:742]: Command Line: REMEMBERME=1 TARGETDIR=...
Property(S): REMEMBERME = 1
Property(C): REMEMBERME = 1

Notice how the REMEMBERME Property was set to 1 after the AppSearch. That’s where the RegistrySearch element was executed and set the Property. Uninstall works exactly the same so I’ll skip that and move on to where our simple solutoin breaks down. What happens if you want to change the value during a repair? It goes something like this:

msiexec /l*v r.txt /i demo.msi REINSTALL=ALL REINSTALLMODE=u REMEMBERME=2
Action start 22:57:23: AppSearch.
AppSearch: Property: REMEMBERME, Signature: RememberProperty
MSI (c) (E4:A0) [22:57:23:378]: PROPERTY CHANGE: Modifying REMEMBERME property. Its current value is '2'. Its new value: '1'.
MSI (c) (E4:A0) [22:57:23:383]: Switching to server: REMEMBERME="1" TARGETDIR=...
MSI (s) (88:A8) [22:57:23:398]: Command Line: REMEMBERME=1 TARGETDIR=...
Property(S): REMEMBERME = 1
Property(C): REMEMBERME = 1

Do you see how the AppSearch that solved our problem creates a new one? It overwrites our attempt to set REMEMBERME to "2" with the remembered value "1". That brings us to our more complex but complete solution.

The Complete Solution

The complete solution builds on the simple solution. All we need to do is add a couple custom actions to save the Property value if it set from the command line. I had hoped to use the SetProperty element introduced in WiX v3.0 to make the solution pretty clean but that does not support the "firstSequence" bit for custom actions. So I’ve had to write out the custom actions completely.

   1:  <Fragment>

   2:    <CustomAction Id='SaveCmdLineValue' Property='CMDLINE_REMEMBERME'

   3:                  Value='[REMEMBERME]' Execute='firstSequence' />

   4:    <CustomAction Id='SetFromCmdLineValue' Property='REMEMBERME'

   5:                  Value='[CMDLINE_REMEMBERME]' Execute='firstSequence' />

   6:   

   7:    <InstallUISequence>

   8:      <Custom Action='SaveCmdLineValue' Before='AppSearch' />

   9:      <Custom Action='SetFromCmdLineValue' After='AppSearch'>

  10:        CMDLINE_REMEMBERME

  11:      </Custom>

  12:    </InstallUISequence>

  13:    <InstallExecuteSequence>

  14:      <Custom Action='SaveCmdLineValue' Before='AppSearch' />

  15:      <Custom Action='SetFromCmdLineValue' After='AppSearch'>

  16:        CMDLINE_REMEMBERME

  17:      </Custom>

  18:    </InstallExecuteSequence>

  19:  </Fragment>

There is nothing special here. We squirrel away the REMEMBERME value from the command line in the CMDLINE_REMEMBERME Property. Later we set the REMEMBERME Property to the CMDLINE_REMEMBERME value if one was provided. Since I put this in a Fragment the only thing remaining is to add a reference from the Product element. I added the following just above the close Product element.

  25:    <CustomActionRef Id='SaveCmdLineValue' />

Try it out yourself and follow the changes to the REMEMBERME Property in a verbose log file. In the future (WiX v4.0, perhaps), we might add something to the WiX language to make this much easier to write. In the meantime, tuck this solution in a Fragment for when you need it later.

Original post by Rob Mensching

About a year ago we started WiX v3.5. At that time we decided on a new plan for WiX v3.0 that moved the Votive for Visual Studio 2010 and Burn features out of WiX v3.0 into WiX v3.5. The goal was for v3.0 to ship earlier. That worked out well because WiX v3.0 released last July.

Through the summer, the plan to deliver WiX v3.5 right around the time Visual Studio 2010 shipped seemed sound. Votive for Visual Studio 2010 in WiX v3.5 stabilized basically on schedule. However, in September, we moved Burn development to a new foundation and Burn still needs a lot of work.

Of course, two weeks ago Visual Studio 2010 shipped which means we should be finishing WiX v3.5 soon. Lots of people want a stable drop of the WiX toolset that supports Visual Studio 2010. Unfortunately, with the current plan we’re a year out.

So we need a new plan.

WiX v3.5

This release is now all about Votive for Visual Studio 2010. The goal will be to finish as quickly as possible. If the IIS7 custom action stabilize quickly they’ll stay in this release. Burn is out though.

• Votive for Visual Studio 2010
• IIS7 custom action (if it stabilizes quickly)
• [cut] Burn

It would be great to have this release out in July, basically a year after WiX v3.0. That is aggressive so my confidence is low. As the bugs drop, I’ll start tracking the progress here just like I did for our last release.

WiX v3.6

This release is all about Burn. Burn will not get cut from a release again. WiX v3.6 is where Burn will ship with all the features I described before. If the IIS7 custom action doesn’t stabilize in time for WiX v3.5 we’ll also finish it here. Finally, to reduce our build and test matrix I plan to drop support for Visual Studio 2005.

• Burn
• IIS7 custom action (if it doesn’t ship in v3.5)
• [cut] Votive for Visual Studio 2005

At this point Burn is something like four years late. Unfortunately, Burn probably won’t be completely done for another year. Our first goal is to get Burn installing the WiX v3.6 toolset and hopefully be mostly stable by end of September.

WiX v4.0

This release will be all about simplification. Over the last decade, the WiX toolset grew into an extremely powerful tool for your Windows installation needs. In that push we’ve added more and more functionality but sometimes the features came at a cost of complexity. In WiX v4.0 I want to take time to make the toolset easier to build and easier to use. My hope is that some of us can start WiX v4.0 at the end of the year.

Conclusion

Burn is cut from its WiX release for a second time. I know a lot of people will be disappointed by that (I know that I am extremely disappointed by it). However, I believe there are more people that will be happy to know that a stable WiX toolset release that supports Visual Studio 2010 is just around the corner.

As always, please feel free to send me feedback.

Original post by Rob Mensching

Over the last week and a half, the Visual Studio team that contributes heavily to the WiX toolset put the finishing touches on Votive to support Visual Studio 2010 RC. Want to use WiX in VS2010 RC? Download the x86 or x64 Wix35 MSI from here: http://wix.sourceforge.net/releases/3.5.1419.0/.

There are three things I want to note:

1. This is *not* a “release candidate� build of WiX v3.5. We still have a lot of work to do in the WiX toolset. There are plenty of bugs left to fix and I’m sure you’ll find more using Votive in VS2010. Please, help us out and file bugs when you hit them.
2. With this build we are no longer supporting the Visual Studio 2010 Betas. We’re rolling forward with the Visual Studio train and we hope you are too.
3. Have you found the new Harvest feature in WiX v3.5’s Votive? No? Want to try it out? Okay, sure. First, create a new project that will build an executable, say a C# WPF application. Next, add a WiX Setup Project. Third, add a project reference from the WiX project to the executable project. Finally, build. The result will be an MSI that installs your executable. Yeah, that’s it. There is plenty more work for us to do here (like how to add a shortcut?) but hopefully you can see the potential here. Like it? Thank Tony.

No go out there and get coding. You know I am!

Original post by Rob Mensching

Honestly, the TARGETDIR/SourceDir Directory element is something that we should have hidden from the developer using the WiX toolset but didn’t. Sorry. The truth of the matter is that the Windows Installer expects the Directory tree to always be rooted in a Directory row where the primary key (Directory/@Id) is "TARGETDIR" and the DefaultDir column (Directory/@Name) is "SourceDir".

During an install, TARGETDIR will default to the largest drive on the machine. SourceDir will be set to the location where the MSI is being executed. Now, SourceDir is tricky after the initial install because it won’t be set unless the ResolveSource action is called. However, you don’t want to explicitly call the ResolveSource action because it is likely to prompt you to provide the original source media (aka: insert the CD, please).

What we should have done in the WiX toolset is remove the need to specify the TARGETDIR/SourceDir pair and say "Any Directory element that has no parent will automatically be parented to TARGETDIR because that’s what the MSI SDK says to do." Instead, you have to do it yourself… and some devs wonder what it all means.

Maybe we’ll fix this in WiX v4.0.

From the StackOverflow question: http://stackoverflow.com/questions/1641094/in-wix-files-what-does-namesourcedir-refer-to

Original post by Rob Mensching