DeploymentEngineering.com - The Blog

Austin meets Heat

2009-07-10T18:55:00.003-05:00

Whew it's been hot in Texas lately. AFAIK it's been 100f+ for the last several weeks with no end in sight. Accordign to weather data, the max temp for last month was 106f with an average of 99f and a min of 90f. This month we are tracking for 106f, 102f and 93f. Whew.

So what does this have to do with setup? Well, I've been playing with WiX's Heat a lot lately. I got tired of running heat from a command prompt and then repeating my same cleanup tasks over and over so I decided to automate it a little with a C# winforms application. While I was at it, I added an interesting feature that I thought was a bit gimmicky at first until I started getting feedback on how cool it was.

What did I add? Simple: a FileSystemWatcher that monitors a directory for updates and then dynamically regenerates the wix document, cleans it up and then refreshes the display to show the new WiX code. With multiple monitors you just stage the dirctory on one screen while watching the program write the code for you on the other screen.

It's really a simple concept but everyone finds it quite informative. Once you have what you want you just cut and paste it into your Votive project.

So I was going to call this new tool "Blow Torch" but when I asked a coworker who is also named Chris how he liked the name he just said that he'd call it Austin.

Austin? Hmmm.... Sure, Why not? I like the sound of it.

So the hear finally destroyed our HVAC plant at work and everyone was sent home for the weekend early. This gave me a few hours to work and now I have Austin built and packaged. For now I'm just going to tease everyone with a screenshot but hopefully in a week or so I'll pass all of quality checks and release this tool for others to play with. That process might go faster if people actually bug me for a copy. ( Hint Hint! )

BTW, in case your wondering why the screenshot has a refresh button, I'm working on making it a feature to scan automatically or manually.

WiX 3.0 Ships

2009-07-04T14:41:00.004-05:00

Wix 3.0.5419 has been promoted to Production Stable quality on SourceForge.net and can be downloaded here.

I've been fairly critical of WiX over the years but today marks a turning point in that believe. With the release of 3.0, many features are now in place that begin to make a really strong case for seriously considering the use of WiX over legacy tools. While WiX still lacks a 1st class bootstrapper/chainer and proper IDE GUI design tools that other tools have, I believe that the core foundation of WiX is much better positioned for the future.

Hopefully we'll see WiX 3.5 ( featuring Burn )in 6-12 months to address these concerns. I also hope to see Votive explode into a fully featured visual studio add-in. Finally, I expect a market of WiX based designer tools to appear. Hopefully WiXAware 3.0 will be released ( and even more hopefully that it actually work! ) and I also anticipate InstallShield will eventually bring tools to market based on WiX. IMO it is inevitable and the InstallShield brand as a packaging tool will not survive if they do not.

So there it is: WiX 3.0 is shipped and I now see the road that I will travel towards over the coming months. With dozens of installers composed from hundreds of merge modules and tens of thousands of files, it'll take us awhile to get there from sure. But I am no convinced that the effort will be worthwhile.

Two Blog Articles on Windows 7 Compatibility Shims Every Install Developer Should Be Aware Of

2009-06-25T09:45:00.002-05:00

Both of these were referenced on Stefan's InstallSite blog but I thought I'd reference them too. Both blog articles are on Chris Jackson's Semantic Consonance blog:

DRM Activation Question

2009-06-24T15:07:00.002-05:00

ShadowWolf recently commented:

Activation ( and reactivation ) are pretty par for the course in the business tool world from what I've seen. I don't know that anyone really "likes" it, but it definitely serves a legitimate purpose.

This comment made me wonder, is this true? I work in an environment with airgaps around our network connections for security purposes and I can't think of a single tool that we use besides InstallShield that requires activation and/or reactivation.

Sure, Windows does (once) but they also offer a volume license key that doesn't require activation. Microsoft Office works the same way. Visual Studio, TFS and so on. Even our IBM/Rational products don't give us this problem and trust me, those are some pretty darn expensive tools. The only product that we use that I can think of is Robohelp.

So I'm curious, what are some of the products my readers use that require activation?

InstallShield 2010 vs WiX 3.0

2009-06-18T22:56:00.002-05:00

It's been no secret that I've favored InstallShield over WiX for many years. I've used InstallShield products since 1997 and I've shipped hundreds of installers using this versatile tool. InstallScript, XML Locator, Setup Prerequisites, Multiple Instance Support, COM Extraction, MySQL, Dialog/Control editors, Product/Release configurations and Component authoring wizards/views have made me a very productive and profitable person over the years.

Unfortunatly, there are also things I dislike about InstallShield. The DRM activation ( and now reactivation with IS2010 ) is horrible, difficulty in trying to get updates in an offline scenario (which we always are for security purposes), the random crashes, the horrible DTD/XML transformation, sequenced primary keys and of course, the removal of the stand alone build from Professional and totally useless collaboration tool combined with the really high price of the product.

If I'm hurting anyones feelings, I'm sorry. It's hard for me too since I've used this tool for so long and I do believe it's still a very good tool for many development shops. Just not for mine.

At my day job, I lead a team of 4 ( going on 6! ) setup developers. We collectively maintain dozens of installs that generate and consume hundreds of merge modules from a software product line. Our typical installer ships 10,000 - 15,000 files and includes countless databases, services, webservices and many chained packages of programs that we integrate with. All of this occurs on many active branches.

Unfortunatly InstallShield with it's DTD XML and incremented primary keys just doesn't work well in this environment. Merging branches back together in clearcase is a nightmare since you always end up with unresolved conflicts. Enter WiX. The XSD XML is 95% smaller then DTD XML and is way more expressive. Also thanks to deterministically unique primary keys and guids, changes done on multiple branches can actually merge back together easily.

The problem with WiX of course is the lack of gui designer abstractions and visualizations. Fortunatly I finally have a solution for that. I've recently had an internal tools developer assigned to me to come up with our own collaboration tools to sit on top of votive. Once complete we are hoping to once again try decentralized setup development. I'm not sure it'll work ( it didn't last time ) but we are going to give it a try again. The reality is our environment is growing so fast that we need to retool and try new strategies to keep up. Hiring more and more people just doesn't seem to work anymore.

Now Hiring - Austin, TX

2009-05-28T21:39:00.003-05:00

I'm looking for an experienced InstallShield / MSI / WiX / BuildForge / TFS / C# software engineer to join my team in Southwest Austin, TX. The engineer will be part of a Build and Install team that currently consists of 8 members with 3 more on the way to meet our ever growing needs.

Please contact me at chrpai@deploymentengineering.com if you are interested.

Please note, due to customer requirements, all applicants must be a US citizen. Ability to obtain and maintain a US Security Clearance is required; an active clearance is highly desirable.

Trip Down Memory Lane

2009-04-27T22:23:00.005-05:00

I don't talk about this much these days, but before my career in computers I was once a musician. From 1993 to 1996, I was assigned for duty with "The Commandant's Own" United States Marine Drum and Bugle Corps. It was quite an honor to have earned the privilege to tour with such an outstanding group.

Those were some really great years of my life. Thanks to Facebook, I'm able to keep in touch with my former fellow Marines and in June we'll be having a 75th anniversary reunion in Washington, DC.

So turn up your speakers and press play for a trip down memory lane.

WiX DTF Mystery Solved

2009-04-17T20:04:00.002-05:00

Last October a (then) former ( and now current ) coworker also named Chris asked me the following in an email:

I am running into a problem with a DTF custom action. When the action tries to run I get:

"SFXCA: Failed to create new CA process via RUNDLL32."

This on is weird because I am using the exact same module in another product on the same machine and it works like a champ. Bizarre.

My initial reply was:

Are any CA's running before it?

I hadn't seen this error before and I was a little concerned because I was such a proponent of DTF and managed custom actions I was afraid that perhaps DTF had an Achilles' heel. I also knew that where my friend worked was the home of a very restrictive environment so if anyone would find a problem with DTF, it would be him!

I introduced Chris to the creator of DTF, Jason Ginchereau, and the two attempted to troubleshoot the problem with little progress. I didn't really follow up on it because at the time I was busy cranking through sprints for a new product at Multimedia Games.

Fast forward five months and I'm working with Chris again refactoring build automation, creating installation tools and writing custom actions for installs. Suddenly the ugly RUNDLL problem rears it's head again only this time it's MY problem because I'm now the install team lead and I'm always saying how good DTF is.

Rats.

So I email Jason again and log a bug (SF210297) at SourceForge to make sure it gets proper attention this time. This time Jason sees some problems on the unmanaged side of DTF. He was assuming that the current working directory of the recycled process hadn't been mucked with ( remember my comment about other CA's scheduled prior? ) when he made his call to RUNDLL32.

So to make a long story short, I just completed an effort with the build team today to update 30 some virtual machines to have WiX 3.0.5210.0. Between this bug fix and many others related to DTF, I really suggest that anyone using DTF custom actions in builds prior to 5210 upgrade ASAP and don't ship your product until you do. You might never come across this problem but I know I sleep better knowing I won't either now also.

InstallAware Email Thread ... Is this for real?

2009-04-15T22:14:00.003-05:00

I came across a very interesting email thread that is really far out there. I almost want to believe it's a fake but having dealt with InstallAware and Michael Nesmith in the past, I can only conclude that it's legit.

You can read the exchange here at CodeProject.com.

When You Wish Upon A Star

2009-04-01T07:10:00.008-05:00

When you wish upon a star
Makes no difference who you are
Anything your heart desires
Will come to you

Wow, have they grown fast! It seems like just yesterday that Ashley and Emma was born.

When you have a 4 year old and a 6 year old who both are princesses, there's only place you can go for vacation... it's simply time to visit the mouse.

Anyone have tips for a first-timer? We'll be going in May before Memorial day.

Wish me luck! :-)

Interesting Tweet

2009-03-27T16:35:00.003-05:00

I just saw this tweet on Twitter:

I don't know the whole back story, and I'm sorry Jim feels that his work is going down the drain, but I only have one thing to say to this:

Hip Hip Hooray!!!!!

SQL Server 2005 SP3 Horrible Setup Experience Results in BSOD

2009-03-20T08:24:00.004-05:00

I maintain a bootstrapper at work and recently we were asked to update SQL Server 2005 SP2 to SQL Server 2005 SP3.

Not a big deal, right?

Wrong!

When installing SQL 2005 SP3 the setup just blows chunks and reboots the computer via blue screen of death!

Worse, the machine goes into an infinite reboot because the installation is an incomplete state and everytime the SQL services try to start the machine BSODS again.

You can boot safe mode and disable the services and then reboot again. But if you attempt to uninstall SQL server you get an error message saying it can't be accomplished.

Wow, thank you Microsoft, you've outdone yourself yet again.

So in digging into this problem it seems that the SQL team is punting to the Windows team. They are saying that they manifested PE files for Vista/2008 in SP3 and that due to a bug in Windows SXS on SP2 ( hotfix available for SP2 or otherwise update to SP3 ) that there is nothing the SQL team can due to solve this.

Um, they could at least put an AppSearch/LaunchCondition into their install so that my machine doesn't turn into a burning pile of dung!

Anyways here's my official warning. Avoid SP3 like the plague and if you must go there, make sure you provide your own prereq check for SP3 or SxS hotfix level in and as always make sure you integration test your installs on the lowest platform configuration possible. I'd hate for some ISV to test on SP3, never see this problem and then ship a product that embeds SQL to a customer. I'd hate even more to have to be taking that BSOD support call.

Records Being Dropped From Merge Module Projects When Built Using the InstallShield 2009 Standalone Build

2009-03-09T11:14:00.003-05:00

---------------------------------------------------------------
[Update/Retraction 3/16/09]
I like to think I'm a big enough man to admit when I'm wrong, so here goes...
The problem reported in this post is fixed by updating to the SP2 version of IS 2009 Standalone Build. Now in my defense, I didn't know there was an SP2 until I reported this problem because the Software Manager doesn't properly identify the update (so I thought I already had "Standalone Build" installed). Anyway, I'm going to leave the original post up (below) in case any readers have the same problem.
---------------------------------------------------------------

I thought I'd post information about another bug I found in InstallShield 2009 merge module projects that I found while comparing output from a merge module project built using the standalone builds for IS 12 and IS 2009.

Records entered into the ProgId or Registry tables in the merge module source project do not get created in the output merge module file (.msm).

Acresso support has duplicated this behavior and I am currently working with them to find a work around (my incident number is SIOA-000143195).

This can be a serious issue if you are not using [or cannot use] the "COM Extract At Build" option to populate the appropriate MSI tables with COM interfaces when the module contains COM binaries. An example of this (that I'm stuck with at the moment) is if the install contains 64-bit COM binaries but is actually built on an x86 machine. In this case, the "COM Extract At Build" option doesn't work so we use the "REG File To Merge At Build" option to add the required interfaces directly to the MSI Registry table.

I suspect (but have not confirmed) that this may also occur for any records added to the Class or TypeLib tables in a merge module source project file. There may also be others.

MSI Tip: How to Reuse a CustomAction for Deferred and Rollback

2009-02-19T06:27:00.004-06:00

Neil Sleightholm recently asked how to tell if your in a rollback custom action using C#/DTF. The answer is simple.

Let's suppose we want to export one custom action method and make it multipurposed. In other words, if we call into while deferred execution we should do one thing but if we call into it for rollback execution we should do another.

How would we do that? The answer is in the BOOL MsiGetMode( __in MSIHANDLE hInstall, __in MSIRUNMODE iRunMode) Windows Installer function exposed by the Session.GetMode( InstallRunMode installRunMode ) DTF method.

Consider the following WiX Code:

    <Binary Id="CustomActionModeTest"

            SourceFile="PATH_TO_DLL.CA.dll "

    </Binary>

    <CustomAction Id="RollbackCA"

                  BinaryKey="CustomActionModeTest"

                  DllEntry="CustomAction1"

                  Execute="rollback"

                  Impersonate="yes">

    </CustomAction>

    <CustomAction Id="DeferredCA"

                  BinaryKey="CustomActionModeTest"

                  DllEntry="CustomAction1"

                  Execute="deferred"

                  Impersonate="yes">

    </CustomAction>

    <InstallExecuteSequence>

      <Custom Action="RollbackCA"

              After="InstallInitialize">

      </Custom>

      <Custom Action="DeferredCA"

              After="RollbackCA">

      </Custom>

    </InstallExecuteSequence>

You'll notice we have 2 custom actions pointing to the same exported function in the binary table. Also notice that one custom action is scheduled as deferred and the other rollback. The deferred is scheduled right after the rollback. This results in Windows Installer scheduling RollbackCA after InstallInitialize and DeferredCA after RollbackCA.

Now let's look at the code inside of that Custom Action.

using System;

using System.Windows.Forms;

using Microsoft.Deployment.WindowsInstaller;

namespace CustomActionModeTest

    public class CustomActions

        [CustomAction]

        public static ActionResult CustomAction1(Session session)

            ActionResult result = ActionResult.Success;

            if (session.GetMode(InstallRunMode.Scheduled))

                MessageBox.Show("I'm not in rollback, let's cause one to occur!");

                result = ActionResult.Failure;

            if (session.GetMode(InstallRunMode.Rollback))

                MessageBox.Show("We are now in a rollback." );

            return result;

At runtime, RollbackCA is skipped and DeferredCA is executed. The CustomAction1 method will be executed by the DeferredCA and it will detect that it's scheduled in deferred mode and display a message saying that it's not in rollback and that it'll cause one. It does so by returning a failure to Windows Installer. Now MSI starts walking the script backwards executing any rollback CA it finds. This causes it to run RollbackCA and once again we are inside of the CustomAction1 method.

This time we will evaluate that we are in rollback, display a message stating so and quit gracefully. At this point the product is not installed.

This pattern can be extended so that CustomAction1 also handles immediate execution, implicit scheduling of the deferred custom actions and CustomActionData serialization/deserialization. But I'll leave that for another blog.

MSI Tip: Authoring an ICE using C# / DTF

2009-02-15T15:16:00.008-06:00

I once wrote an article for InstallShield entitled "MSI Tip: Authoring a Custom ICE using InstallShield 2008". The article can be found here. [Warning: PDF]
In the article, I demonstrated how to write a unit test that could find evil script custom actions. While there is value and humor in doing so, the real point of the article was to demonstrate how InstallShield's refactored InstallScript language could be used to write ICEs.

While InstallScript is certainly an improvement over C++ in terms of cutting down on the line noise and complexity, the difference between C++/InstallScript and C# is nothing short of amazing. As such, I've created a sample project demonstrating how to author ICE's using C#/DTF and Stefan Krueger of InstallSite.org is kind enough to host it for me here.

Consider the following snippet from an MSDN sample demonstrating how to write an ICE in C++:

#include <windows.h>

#include <stdio.h>

#include <tchar.h>

#include <strsafe.h>

#include <MsiQuery.h>

///////////////////////////////////////////////////////////

// ICE01 - simple ICE that does not test anything

UINT __stdcall ICE01(MSIHANDLE hInstall)

// setup the record to describe owner and date created

PMSIHANDLE hRecCreated = ::MsiCreateRecord(1);

::MsiRecordSetString(hRecCreated, 0, TEXT("ICE01\t3\tCreated 04/29/1998 by <insert author's name here>"));

// post the owner message

::MsiProcessMessage(hInstall, INSTALLMESSAGE(INSTALLMESSAGE_USER), hRecCreated);

// setup the record to describe the last time the ICE was modified

::MsiRecordSetString(hRecCreated, 0, TEXT("ICE01\t3\tLast modified 05/06/1998 by <insert author's name here>"));

// post the last modification message

::MsiProcessMessage(hInstall, INSTALLMESSAGE(INSTALLMESSAGE_USER), hRecCreated);

// setup the record to describe what the ICE evaluates

::MsiRecordSetString(hRecCreated, 0, TEXT("ICE01\t3\tSimple ICE illustrating the ICE concept"));

// post the description of evaluation message

::MsiProcessMessage(hInstall, INSTALLMESSAGE(INSTALLMESSAGE_USER), hRecCreated);

// time value to be sent on

TCHAR szValue[200];

DWORD cchValue = sizeof(szValue)/sizeof(TCHAR);

// try to get the time of this call

if (MsiGetProperty(hInstall, TEXT("Time"), szValue, &cchValue) != ERROR_SUCCESS)

StringCchCopy(szValue,  sizeof("(none)")/sizeof(TCHAR)+1, TEXT("none"));// no time available

// setup the record to be sent as a message

PMSIHANDLE hRecTime = ::MsiCreateRecord(2);

::MsiRecordSetString(hRecTime, 0, TEXT("ICE01\t3\tCalled at [1]."));

::MsiRecordSetString(hRecTime, 1, szValue);

// send the time

::MsiProcessMessage(hInstall, INSTALLMESSAGE(INSTALLMESSAGE_USER), hRecTime);

return ERROR_SUCCESS; // allows other ICEs will continue

With DTF and a little OOP ( Object Oriented Programming ) this can be reduced to the following snippet in C# / DTF:

using DE.TestFramework;

using Microsoft.Deployment.WindowsInstaller;

namespace DE.Tests

    partial class ICE01 : TestBase

        [ICETest]

        public void TestExample()

            Publish( ICELevel.Information, "Created 04/29/1998 by <insert author's name here>");

            Publish( ICELevel.Information, "Last modified 05/06/1998 by <insert author's name here>");

            Publish( ICELevel.Information, "Simple ICE illustrating the ICE concept");

            Publish( ICELevel.Information, "Called at " + Session["Time"] );

That may not seem like a big deal but consider the flexibity a few overloads can provide:

public void Publish(ICELevel iceLevel, string Description)

public void Publish(ICELevel iceLevel, string Description, string HelpLocation )

public void Publish(ICELevel iceLevel, string Description, string HelpLocation, string Table, string Column, string PrimaryKey)

public void Publish(ICELevel iceLevel, string Description, string HelpLocation, string Table, string Column, string[] PrimaryKeys)

Of course the real power comes from DTF's awesome interop classes. Going back to example the of detecting script custom actions in InstallScript, here is what it would look like in C# / DTF:

using DE.TestFramework;

using Microsoft.Deployment.WindowsInstaller;

using System;

namespace DE.Tests

    partial class ICE_DE_10

        [ICETest]

        public void TestForScriptCustomActionsAreEvil()

            Publish(ICELevel.Information, "Searching for Evil Script Custom Actions...");

            using (View view = Session.Database.OpenView("SELECT `CustomAction`.`Action`, `CustomAction`.`Type` FROM `CustomAction`"))

                view.Execute();

                foreach (var record in view)

                    string customActionName = record.GetString("Action");

                    int type = record.GetInteger("Type") & 0x00000007;

                    CustomActionTypes customActionType = (CustomActionTypes)type;

                    if (customActionType.Equals(CustomActionTypes.VBScript) || customActionType.Equals(CustomActionTypes.JScript))

                        Publish(ICELevel.Error,

                            "Found Evil " + customActionType.ToString() + " Custom Action " + customActionName,

                            "http://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx",

                            "CustomAction",

                            "Action",

                            customActionName );

                    else

                        Publish(ICELevel.Information, "Found Nice Custom Action: " + customActionName + " Type: " + customActionType.ToString());

IS 2009 Bug - Patch Optimization & Custom CAB Names Mutually Exclusive

2009-01-22T11:02:00.002-06:00

I realize this is a very unique scenario, but I thought I would post it in case you find yourself in this scenario. The bug only applies if you use InstallShield 2009 to build a ‘Basic MSI’ installation and you use ALL of the build options specified below:

You specify custom CAB names (by editing the ISFeatureCabName column of the custom InstallShield Feature table).
You specify the “One .cab per Feature” option on the Custom Compression Settings dialog of the Release Wizard.
You sync file IDs with a previous build using the “Previous package” option on the Advanced Settings dialog of the Release Wizard.

If you do build under the scenario described above, then you should be aware that the options appear to be mutually exclusive and the custom CAB names you specified will NOT be generated correctly by InstallShield at build time.

Below is a description of the problem I reported to Acresso support yesterday (incident #SIOA-000140045):

I have a serious problem with the IsCmdBld.exe in InstallShield 2009 Premier that I need a fix for ASAP.

We are in the process of upgrading our build environment to use IS 2009 to build our primary application installation and are seeing different behavior during the build between the IsSABld.exe we used with previous versions of IS (both IS 12 Premier and IS 2008 Premier) and the behavior seen using IsCmdBld.exe in IS 2009 Premier.

Our primary application installation is a very complex and large MSI installation. Since we must control the names of the CAB files we generate at build time, we use the InstallShield Direct Editor to modify the Feature table in the InstallShield source project and specify a different CAB name for each defined feature (using the ISFeatureCabName field). Using the Release Wizard, we also set the Release Configuration to 'Custom' and select the "One .cab per Feature" option ("Custom Compression Settings" dialog of the Release Wizard). In addition, we specify the fully qualified path and name of a previous MSI package build (by setting the "Previous package" option on the "Advanced Settings" dialog of the Release Wizard. The only other configuration information that may be relevant to this issue is the fact that we have multiple merge modules in the project and each defined feature has one or more merge modules associated with it (no merge module is associated with more than one feature).

When we build the installation (with NO CHANGES other than upgrading the project to IS 2009 schema format) using the IsCmdBld.exe command line utility from IS 2009 the CAB files are not generated correctly. In other words, the files associated with feature A are not being placed into the CAB file specified in the ISFeatureCabName for feature A. However, if I remove the option to point the build to a previous package and then build the project then the CAB files are generated correctly (the files associated with feature A are being correctly placed into the CAB file specified in the ISFeatureCabName for feature A.

In other words, the options to specify the CAB file name for each feature (ISFeatureCabName column of the Feature table) and the Release Wizard option for Patch optimization ("Previous package" option) ARE MUTUALLY EXCLUSIVE IN IS 2009.

I have confirmed this behavior by building under the different scenarios described below:

Build A: IS 12 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsSABld.exe used to build the project.
Build B: IS 12 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsSABld.exe used to build the project.
Build C: IS 2008 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsSABld.exe used to build the project.
Build D: IS 2008 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsSABld.exe used to build the project.
Build E: IS 2009 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsCmdBld.exe used to build the project.
Build F: IS 2009 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsCmdBld.exe used to build the project.

In all scenarios specified above EXCEPT "Build E", the CAB files are correctly generated during the build. In other words, in each of the scenarios EXCEPT "Build E", the files associated with feature A are correctly placed into the CAB file whose name is specified in the ISFeatureCabName column of the Feature table.It is absolutely critical that this be fixed or we cannot use IS 2009 without completely redesigning our MSI installation packaging.

Please, Just One More Miracle

2009-01-16T06:30:00.003-06:00

I know it's been awhile since I posted an update. I've been incredibly swamped by life and my new work. I sit here this morning reading about United 1549 which went down in the Hudson river. Miraculously, no one perished.

I mention this because I'm praying for one more miracle. Cheryl had her quarterly CT scan on Monday and in a couple of hours we'll visit her oncologist to see if she remains no evidence of disease.

[Update]

The CT Scan looks perfect! Thank You God!!

Windows Installer 10 Year Anniversary

2008-12-30T00:31:00.005-06:00

I'm sorry that I haven't posted in awhile. Frankly I'm starting to wonder if there is actually anything new to ever talk about in the MSI world. After all, it's an aging platform SDK that has changed very little over the last 10 years. ( For example, here's a thread between Stefan Krueger (InstallSite had long been around) and Heath Stewart in what seems to be his pre-Microsoft days.)

(Interesting aside: In the above thread, Heath says he's had "Great Success" with InstallShield. Later in September 2000 you'll find threads where's promoting Wise and bashing InstallShield saying that it "sucks". Hmmm... anyways, I remember trying the InstallShield for Windows Installer back in the summer of 1999 and thinking both ISWI and MSI in general sucked. I would continue to use InstallShield 5 for the next 4 years! )

Back to my original thought: Some day soon will mark the official 10 year anniversary of Windows Installer. The problem is, I'm not sure what date exactly. I suppose it'll be Jan 27, 2009 since Wikipedia says this is the ship date of Office 2000. I was searching the usenet archives and I came across the very first thread to ever refer to windows installer on this date 10 years ago. I think you'll find it a fitting:

From: "Tom Savage"
Subject: Office 2000 install error 1601!
Date: 1998/12/30
Message-ID: #1/1
X-Deja-AN: 427080025
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Newsgroups: microsoft.public.msdn.general

Can't install the msdn version of Office 2000 on two test machines. Install
updated the Windows installer and asked me to reboot. Now it stops almost
immediately with an "install error 1601".
Could it be related to my previous installation of Frontpage 2000 B1
(removed it before the current install, but uninstall mentioned a registry
write error)? I removed all Frontpage references I could find from the
registry, and it didn't help.
Would really appreciate any help you could give me on this one. I had grown
very comfortable with Frontpage2000 despite its quirks.
thanks,
ts

From: "Steven Toney"
Subject: Re: Office 2000 install error 1601!
Date: 1998/12/30
Message-ID: <#soTrZEN#GA.255@uppssnewspub04.moswest.msn.net>#1/1
X-Deja-AN: 427260501
References:
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
X-MSMail-Priority: Normal
Newsgroups: microsoft.public.msdn.general

I think the new windows installer sucks!!

much to busy ,, difficult to tell plainly what is being installed and what
is not

install programs should be simple with clear choices and feedback on what
will be installed or removed.

this new program is none of these

steve

From: "Tom Savage"
Subject: Re: Office 2000 install error 1601!
Date: 1998/12/31
Message-ID: #1/1
X-Deja-AN: 427449318
References:
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
X-MSMail-Priority: Normal
Reply-To: "Tom Savage"
Newsgroups: microsoft.public.msdn.general

_Lucky for me_ I found that c:\winnt\system32\msi.dll had not
self-registered during my repeated installations and uninstallations. I
registered it and the installation worked fine.
Well... almost fine. Now I have to get the Office2000 server extensions SQL
Server database to work right. "Version incompatibilities prevent
communication with the database". I'm using a hopelessly out-of-date and
incompatible SQL Server (v6.5 SP3)

The Day The Earth Stood Still Comments

2008-12-13T14:23:00.002-06:00

I took yesterday off from work to hang out with my wife. After sending our kids off to school, dropping by the doctors office for some blood work and eating breakfast at Kerbey Lane Cafe, we decided that we could squeeze a movie in before having to pick Emma up from school.

We decided to see The Day The Earth Stood still since it was starting at 11am and the previews looked good. Unfortunately I hadn't picked up on how disappointing the movie was until we were sitting in the theater.

I have several issues with the politics of the movie, and I found the following comment on the Internet that says it better then I can:

Spoilers… (Or “Savers” if you don’t want to waste $10)

The aliens arrive in the usual idiotic fashion that makes the Conquistadors arrival in the new world look like a well planned diplomatic mission. The response by the Americans is predictable and right out of the Hollywood cliche’ handbook of STOOPID Americanism. The military’s lack of common sense is matched only by the oblivious idiocy of the enlightened Klatu who only realizes that killing 6 billion people is a bad idea when he sees a child crying about his dead daddy. Than the whole movie wraps up with an unexplained sudden ending as Klatu turns off all the lights and leaves. So now what? Are we left in the dark ages forever? Is the blackout a temporary measure to teach us a lesson or can we look forward to a Mad Max style sequel where humanity splits up into tribes and starts killing each other while they all starve to death in famine in a new enlightened more green style of misery?

Avoid this turd. Word of mouth should kill it off in a matter of weeks. But on the bright side the Wolverine preview looked pretty cool.

-Michael

On the bright side, I actually had decent service at Kerbey Lane Cafe for a change. :-) Usually I have such a horrible experience. I really don't understand what Austinites see in that restaurant.

Back with old friends

2008-11-18T21:02:00.002-06:00

From time to time my stomach tells me that it's time for a change. This recently happened again ( darn build/install guys always keep getting hit by a bus... ) and on November 17Th, 2008 I left MultiMedia Games and returned to Overwatch Textron Systems, Tactical Operations to be with old and new friends.

So after having both the TFS/BuildForge role and the InstallShield/MSI role for the last couple years, I've put my build engineering hat back in the closet and settled in to focus on the installation side of the house.

Our group is growing like crazy! So, if you live in the Austin, TX area and you are an upstanding and unquestionably loyal US Citizen, then please look us up. We are hiring all the time.

Client Profile Configuration Designer Source Code: Where's the Beef?

2008-11-03T15:21:00.004-06:00

In a previous blog I mentioned the horrible setup experience that I had with the Client Profile Configuration Designer setup. I really wanted to work around the problem so I went to CodePlex and downloaded the source files.

The good news is that the build process is exactly the way I like to roll. It just worked!

The bad news is I didn't see any of the source or binaries in the solution tree.

As the old commercial says, Where's the beef?

Horrible Setup Experience for Client Profile Configuration Designer

2008-11-03T14:37:00.007-06:00

I was reading a blog from Windows Installer Expert Stefan Krueger talking about a new setup tool from Microsoft:

At 0:31:15 Tyler introduces the Client Profile Configuration Designer which has just been made available as beta. It's essentially a tool that can chain multiple packages such as the .NET Framework and other prerequisites, as well as ClickOnce packages, MSI based setups or even scripts. It provides a seamless and ustomizable user interface with one progress bar across all the packages, and can either defer reboots requests until the end, or handle reboots between packages gracefully. Optionally it can also create a combined uninstall experience instead of separate entries in the Add/Remove Programs control panel. The Client Profile Configuration Designer can be downloaded from windowsclient.net/wpf/ in the Deployment section.

So I downloaded the program, double clicked the EXE and the install just flashed on by. Oh great, I thought, another one of those WiX based UI-less installs that I've complained about for years. This is sort of odd considering this is supposed to be a fancy WPF chainer.

This left a very unfavorable taste in my mouth as I hate it when an install doesn't announce itself and ask me if it's ok to proceed.

But the real joy was to be had when I tried to run the actual application:

Crash!

Debug!

I then started troubleshooting and found all sorts of interesting things. For example, despite touting itself as a WPF based chainer, the package installs itself Per-User and doesn't cache it's package source. It also *SEEMS* to be using the IExpress bootstrapper. Odd Again.

I eventually got my hands on the actual MSI ( sure enough, Windows Installer XML Windows Installer XML v3.0.2921.0 ) and couldn't find any reference to the missing assembly. Hmmm, I guess it's another case of it worked on my machine!

So while I'd like to give this new tool a spin, it seems Acresso's lead in this space remains completely unchallenged. After all, when is Burn going to be done, 2012?

Big Swinging Developer Test

2008-10-26T14:43:00.003-05:00

I recently came across these three websites that are a much read:

http://www.buildsonmymachine.com/
http://www.wheresthebuild.com/
http://www.youbrokethebuild.com/

The pictures rock in the way they make humor out of the things us deployment engineers have to deal with. Then I moved onto the blog behind it all:

http://blog.bigswingingdeveloper.com/

It's a really good read so let me sign off and leave you to reading it. :-)

What I use WiX for Today

2008-10-23T09:38:00.002-05:00

In a recent blog, Holger asked the question:

"With regard to your automation framework...what for do you make use of WiX (instead of using IS)?"

First a little humor. I'm guessing what many would really say ask is:

"OMG, the big trolling WiX hater actually uses WiX? Has hell frozen over? What do you do with WiX?"

I'm working on an SOA product line that has about 40 builds/installs... micropackages in a sense. I have an InstallShield `common installer` that has a feature tree of all of our known features and product configurations of all of our packages. This allows me to build the different installs while attempting code reuse in the only way InstallShield can really do it. Fragments would be helpful here.

All of my custom actions are written in C# using DTF. This includes the ability to publish SQL services reports using a series of custom tables. ( This needs to be refactored into a WiX extension pattern and possibly shared with the community. )

The features reference merge modules. For some assets where the developer has told me they don't want to worry about setup, I use InstallShield merge modules. For other features where the developer wants to play a role in setup development (rare), I use WiX merge modules.

These products are built individually because they intend to release to QA/PROD that way when servicing. There is also a bootstrapper in the works that will join all of these products together to allow for a variety of setup stores ( site datalayer, site application layer, central datalayer, central datalayer, client 1, client 2 and also sql server reporting services reports ).

Along the lines of red, green, refactor... I'm at green right now. Eventually when better designer tools and bootstrappers are available I'll start refactoring the remaining InstallShield components to WiX fragments. The problem is WiX just isn't there yet IMO and it doesn't make good business sense to do it yet.

InstallShield might be taking away the SAB and raising prices and generally not caring about customers but I'll still get a few years out of IS2009. One day though, WiX will eventually be the answer. Who knows, maybe InstallShield will find a way to stay in that world.

How to build WiX

2008-10-22T18:40:00.003-05:00

Neil Sleightholm has an excellent write up on how to create a WiX build machine.

I've tried to build WiX and all I could think of at the time is YUCK.

Now before someone gets all rude and calls me a troll, relax guys, I'm dogging the build process not any one megalomaniac in particularly.

Seriously, I do build automation day in and day out and there's an anti-pattern that I try to resist with a fury. The Magic Machine AntiPattern... it looks something like this:

Now I know I've read Rob write tomes of opinion about eliminating dependencies and complexity from setup, why not build automation? That's what I do.

At my day job I write build automation frameworks that are responsible for building hundreds of products. I try to get as much re usability as possible out of them and keep the build machine as simple as possible. Ideally**, I use nothing but Windows Server 2003, .NET Framework 3.5SP1, TFS TeamBuild, WiX, InstallShield 2009 Stand Alone Build, MSBuild Community Tasks, AssemblyInfo task and my build automation scripts which get published to the build machines automatically whenever a check in occurs (CI). I am able to sysprep/deploy that image out to any number of virtual machines for scalability and rebuild that image programatically which is also stored in source control and in build automation.

In other words, a very simple, scalable, repeatable environment. Builds should be easy... I should be able to pull a tree of source, throw it to an outside party ( via code escrow for example ) and they shouldn't have to bang their head against the wall to figure out how to build it.

Well eitherway, my hats off to Neil for doing this ( I haven't tested it yet ) and I'm sure some of my readers will be very interested in his HOW-TO article.

**Unfortunately, Microsoft requires that certain project types have Visual Studio installed and other components such as VSTS Test Tools. Yuck... I wish everything was msbuild based.