Fact Check: Microsoft Office 2007 (setup) was developed entirely with WiX

I recently noticed the following tweet:

The quote comes from the WiX Tutorial at Tramontana:

You might wonder if WiX is already mature enough for the installation of large, complex applications with a large number of files to be deployed. Well, Microsoft itself is switching to WiX with all its major software packages. Just as an example, the setup of Microsoft Office 2007 was developed entirely with WiX.

That is a great testimonial to the maturity of WiX.  The only problem is that it isn't true.   Consider the following dialog:

This dialog is not created by WiX.  It's created by an internally developed bootstrapper that provides a multilingual external user interface.   Sure, the installers are mostly WiX underneath the covers ( I see some custom actions in there ) but the majority of the user experience has nothing to do with WiX.  Additionally the Office 2007 consists of many smaller MSI's that are chained together.   WiX simply does not yet support this story.

Sure, the WiX team is currently been working on Burn but it isn't done and the claim isn't true.   Why is this important?   Because I want everyone to remember, Don't Believe Everything You Read.   I like WiX but let's keep it real and not get blinded by enthusiasm.

New Book/eBook Available: WiX: A Developer's Guide to Windows Installer XML

Nick Ramirez announced today the availability of a new book focusing on Windows Installer XML authoring.  I can't say I've read it yet ( other then skimming the first chapter that's available online for free. ) but I'm going to go out on a limb and say everyone should go ahead and buy it.  To put my money where my mouth is, I just ordered it myself.

I don't know if I'm doing Nick any favors or not but here's the way I see it.   Let's be honest, how often do we see a new book on installers?   Once every 5 - 10 years is my guess.    Leslie Easter and Phil Wilson's books were fine but they are very, very old.   So just on that alone I give Nick's new book a buy rating.

Seriously, apx $50 ($10 if you are into eBooks ) is chump change when it comes to investing in training.  So either break out your credit card right now or go on down to your boss and ask him to sign off on it and let's show Nick that his work is appreciated.

Then feel free to come back here and post your reviews of the book as comments.

VSTO 4 ( 2010 ) Lessons Learned

Two and a half years ago, I posted the blog VSTO Lessons Learned. Since then Microsoft has released .NET 4.0, Visual Studio 2010, Office 2010, VSTO 2010 Runtime.   Recently, Stefan Krueger  posted a link to an article over at MSDN called Deploying a Visual Studio 2010 Tools for Office Solution Using Windows Installer.   This was of interest to me since I've recently been working on a project for a client that needed to deploy an Outlook AddIn developed in .NET 4.0 / VSTO 4 targeting Office 2007 / 2010 (x86/x64) on Windows XP ( x86), Vista (x86/x64) and Windows 7  (x86/x64).  As a result of this project I've become intimately familiar with the deployment requirements of such an application and I can say with confidence that the MSDN article has missed the mark.

First, the article teaches the use of Visual Studio Deployment Projects and Installer Class custom actions despite Microsoft announcing that VDPROJ is retired and every MSI expert at Microsoft declaring Managed InstallUtil Custom actions evil.  In case you aren't aware, not only are Installer class custom actions fragile, but VDPROJ will schedule the custom actions with impersonation.  That's a horrible combination if you want to support UAC / Elevated Installs. (Which you should.)

Then they suggest building X86 and X64 MSI's to support Office 2010 x86 / x64 when in reality the only difference is which registry hive you register the AddIn. ( See: Office 2010 Bitness Pain )  This seems to me Microsoft's answer to bitness but many people, including myself, are concerned about the environment.

Not to overlook a single detail, I noticed that their LaunchCondition exampes fail to include "or Installed" to prevent problems during repairs and uninstalls. 

But let's get to what I consider the really import lessons learned:

Office 2007 Beware

There are two problems lurking in Office 2007 GA:

1) It only supports registering Per-User AddIns.

2)  It doesn't load VSTO AddIns unless .NET CLR 2.0 installed.  This is even true if your VSTO is authored using .NET CLR 4.0

There's a hotfix and registry value  that fixes this however the hotfix is not redistributable and requires Office 2007 SP2 already be installed anyways.  ( See: Deploying your VSTO add-ins to All Users, KB976811 and KB976477 )

Frankly, if you come across a machine in this state, there isn't much you can do legally.  You can't redist SP2 and KB976477.  You can pretty much do one of a few things:

1) Add .NET 2.0 to your bootstrapper and use the unsupported/ not recommended HKLM - > HKCU registry propogation pattern described at Deploying your VSTO add-ins to All Users.

2) Add .NET 2.0 to your bootstrapper and use a mutually exclusive registry component to register the AddIn in the user profile and rely on Advertisement to fix it for other users.  ( "Please wait while Windows Installer Repairs [ProductName]...."  badness. )

2) Author a System Search / Launch Condition to block the install.  For this I author one search to look for [CommonFilesFolder]Microsoft Shared\Office12\mso.dll  ( MSO12DLLFOUND) and another one to look for it as  min version 12.0.6520.4999 ( MSO12DLLGOODFOUND )  The LaunchCondition is then

Installed or Not MSO12DLLFOUND or (MSO12DLLFOUND and GOODMSO12DLLFOUND)

[ProductName] Setup has detected a problem with your installation of Office 2007 that must be fixed before installing [ProductName].  Please visit Windows Update or read Microsoft Knowledge Base Article KB976477.

Perquisites

The preqs for this type of application seem simple at first:

.NET 4.0
VSTOR 4

However,  VSTOR4 is really two packages:  x86 and x64.   Also .NET 4.0 also has a requirement for Windows Installer 3.1 and Windows Imagine Component.   See, Microsoft figures that most people will already have these so they didn't include it in the .NET 4.0 bootstrapper.   That won't save your hide though when your customer doesn't have it so along for the ride they must come.

Oh, and did I mention that I have observed that you may have to reboot after installing .NET 4.0 or otherwise VSTOR4 won't install properly?

Finally my client got cute and wrote some C++ code so I had to add the x86 and x64 C++ 2010 Redist packages.  

Here's the final list:

Let's look at our supported configurations and the packages / special notes:

Windows XP SP2 ( x86 )

This is clearly the worst case scenario.  In fact, to support all of this our prereqs folder grows to 92MB. Adding in the Setup.exe and my clients actual MSI and we are at 95MB.    Fortunatly InstallShield can build multiple releases per Product Configuration so I get to give my client choices of CDROM (95MB), Offline EXE (95MB) and Online EXE ( 3MB ).

Windows XP SP3 ( x86 )

MSI 3.1 and WIC can be skipped as these are included in the service pack.

Windows Vista / 7 ( x86 )

MSI 3.1 and WIC can be skipped as can .NET 2.0 as these (or newer)  are all included in Vista / 7 .

Windows Vista/7 (x64)

Now it gets interesting.  Up until now InstallShield 2010 provided all the Setup Prereqs that I needed.  However I couldn't find a VSTO 2010 ( 4 ) x64 prereq so I had to roll one.  Also  the C++ 2010 x86/x64 prereqs only installed on x86/x64 windows respectively.   That doesn't seem correct to me.  The x86 redist will install on either x86 or x64 windows and it seems logical to me that an x86 process on an x64 machine could have a dependency on the x86  C++ runtime.  Also a .NET AnyCPU could go either way and God only knows how an AddIn loaded into Office 2010 x86 might behave differently then an AddIn loaded into Office x64.   So to play it safe I tweaked the InstallShield provided prereq and gave it a condition to install on either platform.

Whew, that was a lot to write for one night and I hope I covered it all.   It seems like to me that Microsoft treats VSTO as this easy ClickOnce deployment story but in reality the deployment story is quite complicated.   The test surface on this one is quite massive (even with the blessing called Hyper-V) but I do have an idea that makes sense to me:

Create an InstallShield 2010LE  Template

The bootstrapper in InstallShield is quite capable of doing all this work. Also it's free with Visual Studio 2010.  This gives it a HUGE leg up on Windows Installer XML.   Also IS 2010 LE is capable of calling EXE CustomActions which is exactly the hack I used to solve my Office 2010 x64 edge case.  I just created an AnyCPU .NET EXE that checks to see if it's running in a 64bit process space and if so, register the AddIn in the 64bit hive.  Same for uninstall.   Evil, I know, but it works.

The other thought that I have is to wrap this all up into a "prereqs only" setup.exe that goes through this process and then quits when it gets to the MSI.    From there you really could do this as a simple and easy ClickOnce installer on a per-user basis with autoupdating from a website of the AddIn.  Unless of course your AddIn was part of a much bigger product.

I'll try to revise this post from time to time. Until then, please leave a comment if you need any clarification or corrections.

Changing Course

I received some news today that came a bit quicker then I was expecting.   Effective tomorrow, I'm going to to ( mostly ) take a break from install lead responsibilities and go work as a .NET developer in one of my company's business areas.  I'm really anxious to attack this new challenge and grow application development skills.  As such,  I'm going to be taking a break from the installer community. I'll continue to work on IsWiX and I owe at least one more blog post on deploying VSTO AddIns.

Wish me luck!

Troubleshooting IIS Problems on Vista SP1

Rod Maupin recently  blogged 'Installations for IIS on Vista Require SP2' :

If you are developing an installation that will install to Internet Information Services 6.0 on Windows Vista, be aware that you must have Service Pack 2. If you don’t, the installation will probably fail in the middle, and roll back any changes that have been made.

Rod's post is light on details and didn't really say why it would (probably) fail so I thought I'd post my observations and experiences on this subject.  I have successfully created Web Installers for Vista SP1 but there are certainly a few gotchas to watch out for:

1)  Make sure you are using an authoring tool with properly behaving IIS Custom Actions.  I highly recommend InstallShield 2010 SP1.  I'm currently withholding judgement on InstallShield 2011 until it's been in the wild for awhile and has it's own SP1.   You need custom actions that can properly handle the various versions of IIS without requiring backwards metabase compatibility shims.  ( Yup, I'm looking at you WiX. )

2) Make sure your web.config is not marked as read-only when you build your installer.  MSI will deploy the file with the read-only attribute set and IIS really, really doesn't like this.

3) Make sure your web.config doesn't have xml namespaces declared.  The IIS API will throw and exception which will bubble back up as a Custom Action error.  In my case it was a namespace declaration added to the web.config when the developer added an Nlog reference.  Once we removed the namespace the installer started working.

Also there's a good read over at the InstallShield community forum:

Vista Enterprise Service Pack 1 IIS 7.0 install problems using Installshield 2010

 If you still have problems or have seen another edge case, please feel free to document it with a comment below.

The Worst Installer I've Ever Seen

I'm going to have to pass on naming the guilty party but recently I received an installer that I needed to add as a prereq to my bootstrapper / chainer.  I started to look at it and here's what I found

1) It's 300+ MB InstallAnywhere installer that presents itself on Windows as a command line installer.  You have to press enter 26 times to page through the EULA and then  type Y to accept it.  Press enter to accept the default installation directory and then watch a progress bar that looks something like:

===============================
Installing...
-----------
[=========|=========|==========|==========|===========]
[-------------|--------------|------------  <- the part that moves

Oh my God, and I though WiX was bad.   This one tops it for me.   Hello!  The 1980's called and they want their INSTALL.EXE back.

Here's where it gets worse though.  This InstallAnywhere is just a wrapper for an MSI installer that it extracts out, calls to and then deletes when it's done.  (  Certainly hiding the installer source is far more important then making it available for repair operations ).

I did some googling ( I have to admit, I haven't ever written an InstallAnywhere package.  The few tarballs I wrote in the 1990's were enough for me. ) and I found the command line switches for UI, Console and Silent.  Guess what?   Yup.  UI and Silent were both intentionally disabled in this installer. 

Finally, the documentation that comes with this installer specifically states "Do Not Use Add/Remove Programs" to uninstall the application.

Wow.  I didn't know to laugh or cry.

InstallSite: Microsoft will retire Visual Studio Installer

According to Windows Installer MVP Stefan Krueger of InstallSite:

Retirement of Visual Studio Installer Projects from future versions of Visual Studio



Candy Chiang MSFT Thursday, July 15, 2010 8:07 PM

In Visual Studio 2010, we have partnered with Flexera, makers of InstallShield, to create InstallShield Limited Edition 2010 just for Visual Studio 2010 customers. The InstallShield Limited Edition 2010 offers comparable functionality to the Visual Studio Installer projects. In addition, you can build your deployment projects using Team Foundation Server and MSBuild. For more information, see http://blogs.msdn.com/b/deployment_technologies/archive/2010/04/20/installshield-limited-edition-is-available-for-download-in-visual-studio-2010.aspx.

With InstallShield available, the Visual Studio Installer project types will not be available in future versions of Visual Studio. To preserve existing customer investments in Visual Studio Installer projects, Microsoft will continue to support the Visual Studio Installer projects feature that shipped with Visual Studio 2010 and below as per our product life-cycle strategy. For more information, see Expanded Microsoft Support Lifecycle Policy for Business & Development Products.

All I can say is:  About Time!

Visual Studio Deployment Projects were horrible and contributed to a great many anti patterns including the extensive and inappropriate use of fragile Installer class custom actions.  I can only hope that InstallUtil is next on the chopping block.

That said, InstallShield 2010LE alone will not fill the void 100% so I hope Microsoft also makes good on getting WiX into a future version of Visual Studio.  Until then, if one is clever, there are ways of making WiX merge modules and merging them into InstallShield 2010LE projects to get IS to do things it wasn't designed to do while following MSI best practices at the same time.