InstallScript Custom Actions are GOOD

We've long heard the rants against Script based CA's, Managed Code CA's and CA's in general. Lately Microsoft has begun blogging about the horrors of even EXE CA's.

IMO when talking about CA problems, is isn't really the CA that is the problem. The problem is in the CA hosting models and therefore it's really MSI that is the problem. And when preaching against CA's in general, yes it is true, somewhere north of 90% of the CA's written by developers truly aren't needed. However the other 10% is really a result of MSI not being `feature complete` as defined by the customer instead of as defined by Microsoft. Unfortunately there doesn't seem to be any change coming in the near future.

So where does that leave us? Type 1 DLL standard call CA's:

Ultimately, avoiding CAs is the best approach but, when necessary, you should develop DLL CAs. Immediate DLL CAs can read from the installer package database and should be data driven, making it easier to service that data and providing perhaps some transparency to what your CA does. Those immediate CAs can then schedule deferred, rollback, and commit CAs as necessary based on that data and the current state of the machine. -Heath Stewart

But wait, who says they have to be written in C++? Well, no one does really. You see, as I previously blogged, starting with InstallShield 12 InstallScript CA's are really just unmanaged Type 1 CA's.

While there are a couple downsides ( mainly larger package size and slightly slower execution ), I think the upsides far outweigh them.

InstallScript is:

Not based on ActiveScript / Windows Scripting Host.

A C like language that is easier to code in then C++.

A domain specific language that has many proven functions for tackling setup related problems. This results in increased reliability as you aren't making stupid mistakes trying to roll your own everything and reinventing the wheel in C++.

Integrated into InstallShield. This makes it easier to develop, build and test in one easy to use IDE.

Doesn't add additional dependencies to your install. You won't need setup.exe to deploy some runtime to run your CA. You also won't find broken installs because someone built the debug C++ bits or didn't include some C++ runtime dll.

Can be transplanted into other installs. Stream out of one binary table and into another. It'll even work when writing transforms for packages made in other authoring tools.

Can easily use MSI API's to create data driven CA's.

I'm sure I could go on and on but I'll stop right there. InstallScript has really come a long way and is the right tool for the right job.

Some Good News

We received some good news on Saturday. Cheryl's MRI came back and there is no cancer in her brain. We are so relieved as that's not a road that we want to go down.

Still, we do face some new challenges now that Cheryl has a history of seizures. The neurologist has started her on some medication that takes awhile to adjust to. Basically I'll be taking the next week off of work to be with her and the girls until her parents arrive.

And to make life as interesting as possible, Ashley came down with the stomach bug in the middle of the night and Emma had a swollen and purple finger from an infection caused by a splinter. I just love running to three different Dr's offices in 24 hours!!!

Here's praying for better health in the days, months and years to come. Thank you everyone who's been there for me.

Exhausted from Cancer

Today was a very trying day that started with a call to 911 at 4am followed by 15 hours at a local hospital. I'm so mentally and physically exhausted right now that it's easier to just share my wife's perspective ( made possible by laptops and hospital WiFI ). My perspective would be too disturbing to post since I actually witnessed and responded to the seizure.

Early this morning we had a horrible scare. I had a grand mal seizure occur around 4:00 am. Chris was able to get me on my side, make sure I wasn't choking, and called the ambulance. All I remember is waking up to several paramedics in our room.
At this point, we are at Seton NW Hospital. They have already done an X-ray, CT scan to see if there was anything. They are planning to admit me for 1-2 days. During that time I'll have a spinal tap and an MRI done to see if there is anything happening in my brain. I will probably be put on anti-seizure medicine.

I am so grateful my in-laws are in town to help with the girls. My sister and Chris are with me right now. Please pray they find nothing in my brain, specifically no new tumours, and that this is just a 'fluke'.

I guess I should be grateful for the first aid / first responder training that I've had over the years. One of my personal hobbies is Scuba Diving and in the Rescue Diver and Nitrox courses we discussed handling O2 toxicity problems including grand mal seizures. I just never imagined that I'd be dealing with it on dry land while waking up from sleep.

WiX Code Is Pretty

I know that I frequently express my frustration with the WiX development experience. But there is one thing that I really like about WiX: How darn pretty the XML is. The declarative nature of MSI and the way the data is stored in multiple tables really makes it hard to describe an implementation detail in writing.

For example, I can describe an EXE CA stored in the binary table, scheduled in the execute sequence after InstallInitiatize with no impersonation and deferred execution.

If you have a solid MSI background, you probably have enough information to proceed. But if you are new at MSI and you need me to SHOW you how that all works it can be interesting trying to write it down.

One approach might be to try to describe the table relationships:

Binary Table
NewBinary1 stream in Notepad.exe data here

CustomAction Table
NewCustomAction1 3074 NewBinary1

InstallExecuteSequence Table
NewCustomAction1 1501

I might also try to express the relationships in .IDT format or perhaps MSI2XML ( which InstallShield uses ) but the end result is data that's hard to read and understand. After all, just what the heck is 3074 and 1501 without digging in to understand? Worse, it's not `code` that can be easily stolen ( umm, I mean copy and pasted hehehe ).

<Binary Id="Notepad.exe" SourceFile="notepad.exe"/>

<CustomAction Id="CustomAction1"
Return="check" HideTarget="no" Execute="deferred" Impersonate="no"
TerminalServerAware="no" ExeCommand="" BinaryKey="Notepad.exe"/>
<InstallExecuteSequence>
<Custom Action="CustomAction1" After="InstallInitialize" />
</InstallExecuteSequence>

Still, don't expect me to be reading/writing installs like Neo in the Matrix. IMO this is all great, but designers still rule in authoring the majority of my installation logic because of the productivity and reliability gains achieved in automating the authoring.

IEAK 7 - Another `Fake` MSI using WiX

MSI Expert Stefan Krueger recently blogged that Microsoft has released an updated IEAK 7 that now creates MSI files. I've had a chance to look at it and I can't help notice a few things. But first, let's go back in time a bit to Feb 2006 when Rob Mensching once blogged:

Google Toolbar Beta for Enterprise includes a Microsoft Windows Installer package that makes organization-wide distribution a snap.

Cool. So, I downloaded the .zip file and popped open the GoogleToolbarInstaller.msi and what should I find? Yep, you guessed it. The GoogleToolbarInstaller.msi file was created by the WiX toolset. Woohoo! How cool is that? Google uses the WiX toolset.

After calming down, I decided to look around and see how well the MSI was actually put together. Then my excitement dropped. The GoogleToolbarInstaller MSI package is a total fake. Their MSI file is nothing more than a wrapper around the old GoogleToolbarInstaller.exe. The Google Toolbar Beta for Enterprise does not use the Windows Installer to actually install the files (I'm not sure what install technology they are using). That means the Google Toolbar Beta for Enterprise does not get all of the transaction guarantees and other administrative/repair features that a true Windows Installer package would provide.

If you are an administrator looking to deploy this package, don't be surprised when you find that this MSI package doesn't behave exactly like real Windows Installer packages. The Google Toolbar Beta for Enterprise MSI package is really just a "Trojan horse" carrying their custom installation system. I really wish Google had used the Windows Installer technology more appropriately.

At the time I commented:

Rob- I'm usually nodding my head with you, but come on, Microsoft did the EXACT same thing with the Windows Media Player 9 Administratios Deployment kit that we talked about a couple blogs ago. Perhaps if AD GPO wasn't so restrictive in only understanding MSI people wouldn't feel the need to wrap legacy installer in a pseudo-msi package.

Well let's get back to the recent IEAK 7 release. Yes, you guessed it: Microsoft has once again done the exact same thing as Google. If you run the IEAK 7 wizard and build the MSI you'll notice that Microsoft ignored their very own setup expert and took a play straight out out of the Google playbook. They made a fake MSI package that doesn't publish the package and instead goes out of process to Setup.Exe to get the job done. All of this to get around the limitations of GPO without actually making the investment in MSI.

And of course the funniest thing is they used Windows Installer XML v2.0.3620.0 (candle/light) to get the job done. Just like Google.

Deployment AntiPatterns

I recently came across a blog post from ScottGuthrie (MSFT) titled Tip/Trick: Automating Dev, QA, Staging, and Production Web.Config Settings with VS 2005. In his tip, Scott uses his build automation to produce multiple product configurations that stage different servers with different web.config files. He then gets dozens of ataboys comments from readers including one who wonders if this could be done for Winforms applications to which Scott replies

Yes - you should be able to use the same approach with winforms projects.

Now I'm sure Scott is a smart .NET developer, but this type of `xcopy deployment` that is tightly coupled to build automation is crazy. Furthermore, I know he's not alone in this thinking since if you pick up practically any .NET book you won't find deployment covered until the end of the book and even then it's a cursory look at VDPROJ as if deployment is that simple.

Build ( Core Code and Installer Packages ), Installation and Configuration are NOT the same thing. They are distinct steps in an overall process of deploying an application.

You may very well need to do all three of these steps within a single transaction ( for example automatically deploying an application to a Dev Integration Lab as part of a CI process ) but the steps are still separate.

Now some people disagree on whether an Install should actually configure a product or not. Regardless the build output should consist of a setup package. If you want to automate the deployment the build should then call staging automation to apply the package. If the package contains configuration logic, the staging automaton should pass those values to the package. If not, the staging automation should call an external utility and pass the values so that the product is ready to be used. In this way the staging automation could be invoked multiple times to stage Dev, QA, Production, whatever.

Scott's solution might be `OK` for an in house application that only gets `deployed` to a limited no of locations, but if you are working on a real `Product` that gets sold and given to customers all over the world you will really want to make a proper investment in automation.

Using TFS and PowerGen to build PowerBuilder

Over 10 years ago, I cut my OO teeth on a language called PowerBuilder. It had a really cool object called the DataWindow which was very similar to .NET's DataGridView class. This was back in the heyday of waterfall, CMM, big hunking fat clients and script based procedural installs as Windows Installer wasn't invented yet. At some point I became the Build/Install lead on a very large military client/server system and I was introduced to a wonderful tool called PowerGen. You see, natively PowerBuilder only had a `project object` for interactivly building your code. There was also an API called ORCA that you could use ( and later OrcaScript ) but that really sucks. PowerGen had a project file, GUI editor and command line interface that turns it all into child's play.

To make a long story short, I thought I was done with PowerBuilder back in 2003. Then I took a job about a year ago that involved Build/Install work for a TFS/.NET SOA system that was headed in the SaaS direction. After taking care of that I was asked to see what could be done with their legacy PowerBuilder system. I was somewhat shocked to see that they were checking PBL's ( PowerBuilder Libraries... large binary source files that consume tons of space, slow down the VSS client and can't be diff'd ). Worse, they had a completly manual build process.

Fortunately PowerGen once again came to the rescue. After a little custom wiring along the lines of going out of process to build a VDPROJ project, I was able to come up with a solution that incorporated TFS and TeamBuild as the source control repository and build platform. I've since contributed a set of sample scripts that should be able to help point other PowerBuilder/TFS users in the right direction.