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.

Office 2010 Bitness Pain

Recently I've been doing some work for a customer who needs an installer for a Office 2007/2010 VSTO 2010 AddIn.  While authoring the actual installer isn't that difficult thanks to the awesome bootstrapper in InstallShield 20xx, the real fun has been on the integration and testing side. 

Making sure this your product and installer will work on Windows XP SP2/SP3 x86 / x64,  Vista x86 / x64 and Windows 7 x86 / x64 in conjunction with Office 2007 and Office 2010 can really take quite a bit of time even with the help of Hyper-V snapshots to make sure that you aren't missing any edge cases.   You have prereqs with prereqs such as VSTO -> .NET 4.0 -> Windows Imaging Components -> MSI 3.1 in the case of Windows XP SP2.  Microsoft doesn't keep it simple but thankfully InstallShield does a good job trying to keep up.

 Somethings have improved as Office 2010 once again behaves like Office 2003 in allowing you to register AddIns in HKEY_LOCAL_MACHINE  (  the hell that is Office 2007 is fodder for another blog post ) but Office 2010 adds a whole new wrinkle that makes me want to pull my hair out:  Bitness Pain

Let's start with the easy bitness pain:   VSTOR40_x86.exe vs VSTOR40_x64.exe.   The VSTO AddIn has a run time dependency that's tied to the platform of Windows that you are running on.   Still, since the setup.exe bootstrapper is handling VSTOR for me, this is a pretty easy problem to solve.

Now for the harder pain:   Your AnyCPU VSTO AddIn has to be registered in HKEY_LOCAL_MACHINE but which hive?    The 64bit or the 32bit?

If you picked 64bit  you are probably wrong.  If you said "use registry reflection you re probably wrong also since this was removed from Windows 7 and considering how much of a flop Vista was your user is probably running Windows 7.

See, it doesn't matter that you are running 64bit Windows, it matters if you are running 64bit Office!  Now for the kicker,   Microsoft has a complicated work flow for recommending if a user should install the x86 Office or the x64 Office.     It basically boils down to  Developers and Hard Core Excel Junkies with spreadsheets larger then 2GB should run x64 and the rest of the world should run x86. In fact, if you stick the disk in and run the setup.exe from the root you are very likely to get x86 Office 2010.

So now you have this AnyCPU AddIn packaged up in MSI which doesn't officially support hybrid installs which means you have to have 2 downloads and hope your user is smart enough to know which one to download.  Or you have to make 2 MSI's and wrap it with a bootstrapper .... something that InstallShield can't do at the moment.

Hmmm... what to do, what to do?  I guess I could just punt and only support x86 Office.  After all the vast vast majority of users will be using it.  But Microsoft really wants to move the community forward and I really don't want to leave my customer taking even 1 support call trying to get their AddIn to work.

So I think I'm going to vote for a Hybrid install on this one.  It's only 4 registry values that I need to write so I'm going to put my nose up in the air at Windows Installer and roll a custom action which fires only on 64 machines to write the values and remove them on uninstall.

If anyone at Microsoft is reading, and I know you are from my http logs,  please, please try to do something to fix this.    This single bitness limitation in MSI is just going to become more and more painful in my opinion.

PS-  I'll probably never get back to the Office 2007 comment so here goes.   2007 only supported registering AddIns in HKEY_CURRENT_USER.  There is a HotFix available along with a registry value to fix this and Microsoft blog articles say 'we fixed it' but here's the catch.   We aren't allowed to redistribute it with our installers.  We have to hope that end users have patched their machines via Microsoft Update.   Well I didnt want my customer to have to get that support call either so I wrote an AppSearch that checks if Office12 MSO.DLL is present that it's atleast a certain version otherwise gate with a LaunchCondition.

.NET 4.0 has 2 Global Assembly Cache (GAC)

Please be sure to read the following article and then come back.   I'll pull up a chair and wait for you.

.NET 4.0 has 2 Global Assembly Cache (GAC)

Wow,  I only recently noticed that .NET 4.0 has a "new GAC" ( BTW, wtf? I guess Global doesn't really mean Global? )


But I'm wondering, what does this mean to me as a Setup guy? Does the MSI support this?   To find out I created a CLR 4 Class Library in Visual Studio 2010 and signed it with an SNK.   I dropped it into an InstallShield Basic MSI targetting the GAC like normal and sure enough the file deployed to [WindowsFolder]Microsoft.NET\assembly\GAC_MSIL\ClassLibrary1\v4.0_1.0.0.0_token.

But, is there anything else I need to know here? My head is just spinning from this design decision ( although I seem to be in good company ) and I really want to make sure I understand all of the implications.

Read the Windows Installer SDK

I have a story that I'd like to share and I ask everyone to please not take it too seriously / literally.   With that out of the way, here goes.

I was at church the other day and they were doing a presentation of Bibles to third graders.  It was really exciting to see these little kids up there unwrapping their new found treasure. 

At some point there was an oath where the children and later the adults promised to read their Bibles. During this a comment was made by the that you won't always understand what you are reading but that you should keep reading it until one day you do.

One of my responsibilities at work is team professional growth.  I do all kinds of activities to keep everyone plugged in and learning but just like anything if life if you only listen for an hour a week you are never really going to get it.

So at the risk of sacrilege, I want to state:

Read your Windows Installer Bible!

Yes, it's a tough read that doesn't always make sense but read it every day anyways.  Apply it to what you do every day and one day soon those obscure notes sprinkled throughout will make sense.

Whenever I get a really hard problem, I am usually able to solve it really quickly because I took the time to read it over and over.  People sometimes look at me with amazement on how fast I fixed a problem but the truth is anyone who takes the time to learn it inside and out should be able to do it.  It just goes to show me that they haven't been reading their MSI SDK.

Try to make a commitment to yourself.  30 minutes a day for the next month.  You might be surprised what you learn.

In Defense of Merge Modules

Neil Sleightholm recently commented:

"Personally I never use merge modules unless I am forced to!"

It's an interesting perspective and I invite Neil to tell more ( as an aside, I'm always interested in guest bloggers on the Deployment Engineering team.  Diversity in Opinion is always a good thing ).  Until then, I wanted to give a few of my thoughts.   

Let's begin by reviewing Windows Installer Tao Rule # 43

Rule 43: Think carefully about Merge Module Patching

Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. Since the setup author who owns the MSI doesn’t own the merge module, they have no way to deliver fixes to issues that are found in the merge module, unless the merge module owner makes them available. On the other hand, the owner of the merge module has no way of delivering the fixes directly to the clients who installed the MSI built after consuming his/her merge module. The bottom-line of the story here is:

•Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive

•Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup

Let's begin with a little history lesson. Microsoft used to use Concurrent / Nested Installs and Merge Modules as a deployment option for Microsoft SQL Server Desktop Engine. Then along came some really nasty security vulnerabilities that exposed a glaring problem in servicing these products that were embedded in other products. Network / Systems Administrators simply couldn't patch there production systems easily to eliminate these worms. Then Microsoft started telling developers to not use these technologies and instead use Micro-Packages to deliver them. After awhile, the message mutated into something along the lines of "merge modules are evil".   Then there was the little problem that MSI doesn't actually provide a decent bootstrapper / chainer to put all these packages together and the proliferation of packages has made Add/Remove Programs look like total chaos.  

Now let's go back and re-read Rule #43 with a little emphasis on the parts that I find interesting:

Rule 43: Think carefully about Merge Module Patching

Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. Since the setup author who owns the MSI doesn’t own the merge module, they have no way to deliver fixes to issues that are found in the merge module, unless the merge module owner makes them available. On the other hand, the owner of the merge module has no way of delivering the fixes directly to the clients who installed the MSI built after consuming his/her merge module. The bottom-line of the story here is:

•Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive

•Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup

OK, so what am I getting at?   Yes, it's true that when I put merge modules in my installs from third parties ( typically Microsoft .. how ironic )  that the quality of my installs go down.   And it's true that Microsoft doesn't promise to provide fixes and updates to these modules and in many instances they don't provide MicroPackages to redistribute either.    So what's my alternative?  Break the component rules and author my own components for another companies  resources?   Yup, this is an ugly problem that's never solved except by not taking dependencies on those components and moving to newer technologies that get more love from third party vendors.  Still, I'm writing the install not the application so I don't typically get to make that call.

However,  I am certain that using merge modules internally  to distribute setup development is a good thing.   Comparable and even better in some situations then using  WiX Fragments / Libraries /  Binary Libraries or InstallShield Developer Installation Manifests.

First, Merge Modules are STANDARD and can be consumed by installers ranging from InstallShield to WiX.   Try consuming an InstallShield DIM in WiX or a WiX Fragment in InstallShield. 

Second, merge modules are atomic collections of components and setup logic.  This is actually fairly similar to WiX Fragments which according to their own documentation are also atomic and immutable.  WiX Binary Libraries and MSI Merge Modules both aim to solve similar problems.

Sure, using Fragments can speed up your build and give you a bit more flexibility ( like including two components in a fragment but Referencing them into two different features ).    However, you can do the same thing with merge modules by creating multiple merge modules with module dependencies to describe component / feature relationships.  With a little bit of creativity, Merge Modules can even be used to encapsulate AppSearches, CustomActions, Dialogs and more.

Over the last five years I've developed an architecture where I use an InstallShield Basic MSI project to describe a feature tree and product configurations to describe which features to consume.  This serves as a fishbone that I then flesh out with dozens to hundreds of merge modules and create dozens of product installers with.   I use Major Upgrades as my servicing strategy and the result is I've never had any problems that were caused by the use of Merge Modules.

In summary, you don't have to have a monolithic InstallShield project for each of the installs you own.  You can split it out and reuse components and logic through merge modules and not increase the fragility of your install.   In fact, you can realize considerable savings by eliminating wasted effort and decreasing the frequency of bugs in your baseline.

Yes, I will admit it:   I use Merge Modules and I'm OK with that.   Still,  I will be working on Fragment support for IsWiX.

InstallShield KB Q207265 Critique

I was browsing InstallSite today when I noticed a link to InstallShield KB Q207265:

HOWTO: Implement an InstallScript Custom Action to Detect and Display Message About Whether a Directory Exists

I'm a little suprised by this article for several reasons.  The first reason is that it suggests writing InstallScript custom actions for functionality that already exists in the Windows Installer.   The AppSearch pattern ( InstallShield calls it System Search ) is more then capable of resolving if a directory exists by using the DrLocator table.  Also you can easily create a modal dialog with a text control that displays exists / not exists messages based on the results of the first search.

Finally the article suggests scheduling the custom action in the execute sequence with a condition of  REMOVE <> "ALL" to prevent execution during an uninstall.    However, this means that the message will be displayed during a silent install since the CA is in the execute sequence and there is nothing that takes UILevel into consideration.

Overall I'm really surprised by the lack of quality in this article.  I know InstallShield has some extremely talented and experienced experts such as Robert Dickau  so I'm not sure where this article came from.