Windows Installer 10 Year Anniversary

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

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

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?

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

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

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

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

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.

Come to the dark side

As I sit here reflecting upon my day I started thinking about a coworker that I've been interacting with lately for a project involving the creation of a data driven custom action pattern for publishing datasources and reports to a sqlserver reporting services instance. ( Side note: this would really rock as a wix extension )

You see, this person has shown an exceedingly rare (at least where I work) ability to jump in and understand the needs of setup. All on his own, he's started maintaining the wix merge module source that defines the custom tables that drive the custom actions. When we were prototyping the custom actions, we were having difficulties getting the Microsoft web service object model to properly associate the uploaded reports with the shared datasources. This developer jumped into C#/DTF, figured out how I was using the WindowsInstaller interop to read the custom tables into HashTables and then using the data to call the webservice methods to make the configuration changes. Finally he dug into the webservice object model, found the issue and fixed the datasource association bug.

Needless to say, I'm impressed. If all of our developers were like this developer, we'd be along way towards the distributed setup development model that people at Microsoft preach.

At last this developer is primarily a DBA. So I ask my readers, how would you entice a developer like this to consider the world of deployment engineering?

RFC: SQL Scripts Are Almost Declared Evil

So much has been written about the evils of custom actions ( namely of types: script, exe and instalutil ) but I've not read many comments regarding database deployments via sql scripts.

I have an opinion thats been forming over the last decade:

Database dependency injections in setup are evil.

Unfortunatly, I also don't know if they are avoidable since many people expect an application to just work after being installed.

Eitherway, what is the best of class solution? I've not seen one yet.

Back in the 90's I was responsible for putting together 500MB+ tarball packages for a massive Unix based server system. One of the modules in the package deployed a series of Informix databases either from scratch or upgrade from a previous release. Other parts of the system configured the operating system, nightly/weekly/monthly CRON jobs an many other tasks.

Does anyone want to guess which part of the install failed the most often?

Yup, you guessed it... the database updates. Think about it, with over 1300 stored procedures, each one of those sql files was basically an untrusted out of process script which could introduce fragility into the package. On top of that, the sql scripts to deploy and upgrade the databases had even more complexity with all sorts of dependencies that would make the install even more unstable.

The truth is we frequently extracted the package, manually turned off the database updates and then ran the install. After we'd call a DBA on duty and ask them to manually update the database.

Yes, that's a horrible release strategy. But that's what the release manager ordered to keep the schedule.

I recently read a post on in the InstallShield community forum where a user was asking why an install could connect to sql server using localhost but not (local). My thought was to test if other sql clients could connect as (local) and then check the sql configuration. The posters response was:

I don't want our customers to have use any special SQL Server configurations. This software should work out of the box.

Unfortunatly, my opinion is becoming that these statements are mutually exclusive when dealing with datalayer dependency injections. Unfortunatly most developers I come across seem to have this overly simplistic understanding of the challenges of database deployment and maintenance. They want to throw extremly how level requirements along the line of 'The install should just work.' and then throw extremly technical challenges with many possible configuration variations.

I'm sorry, but I just haven't seen it work that way yet.

So I'm very, very interested to know what my readers think on this subject. Have you had the same pain or have you found a better way to deal with the challenges? Also do you have the same problem that I have: People don't seem to understand that when an install breaks because of a sql dependency injection that it wasn't the installs fault. After all, it wasn't the setup engineer who made the decision to inject the custom action and it wasn't the setup engineer who was responsible for developing or testing it.

User Data / Log Files Best Practices

I have a question for my readers, consider this an informal architectural review.

Consider the following conversation, what would your next reply be?

Application Development:

"We need the install to modify the ACL permissions under [ProgramFilesFolder]CompanyName\Logs and set it for all users to have modify."

Installer Development:
"It's not a best practice to store user data /logs in Program Files. You should consider writing your file to another location."

Application Development:

"But I see plenty of companies that write log files under ProgramFiles. I disagree and I think that the install should go ahead and change the permissions."

What would you say next?
What would your response be?

Thanks to InstallSite and Microsoft for the MSDN Subscription

I'd like to say thank you very much to Windows Installer MVP and webmaster of InstallSite Stefan Krueger and to Microsoft for the very generous award of One-year subscription of MSDN Premium with Visual Studio Team Suite . I am very honored and humbled to have been nominated and selected for this promotion that recognized community participation.

For those who follow my blog, I've recently been growing my intrastructure by investing in virtualization hardware. I also now use Microsoft Team Foundation Server and Hyper-V as an integral part of my ever growing consulting business.

.NET, TFS and MSDN rocks! Thank you very much Stefan!

HOWTO: Use Regsvr32.exe with WIX

I was surfing the blogosphere tonight when I came across this interesting blog from a Microsoft employee developer using WiX demonstrating how to use an EXE custom action to call Regsvr32:

For those of you who don’t recognize this dll, its a required library by Add-in Express, we are using it to ease our development of GhotIt (http://www.ghotit.com) plug-in(s) for Microsoft Office applications.

Now I'm currently too tired to give another `don't believe what you read` article so I'll just leave at where are the setup police when we need them?

Different year, Same Problem...

5 years ago I was working at Continental Airlines learning MSI with Windows Installer 2.0. One of the biggest pain points was troubleshooting why services wouldn't start. Some programs just had horrible COM/ATL issues relating to COM extraction not working and /regsvr having race problems.

One of the more aggravating scenarios was for a program called Gate Reader that had a windows service with a dependency on a active directory service account.

Inevitably one of two things would go wrong: Either someone had locked the account out ( and no installs would work for up to the next 15 minutes ) or the service account had never been assigned the SeServiceLogonRight priv on the machine being installed to.

Now we can talk about eliminating the dependency by eliminating the service account but at the end of the day development typically doesn't give a flying brown mass about deployment/operational problems.

So it's the later that always irritated me. Why in the world is it that Windows Installer has columns in the ServiceInstall table for describing a service account but when it creates the service it doesnt' grant the SeServiceLogonRight priviledge?

A quick hop over to Services and type in the username and password gets you a dialog that says the account has been granted logon as service.

I know I'm not the only one to have this problem because there are many threads where setup developers suggest using the not-quite-redistributable NTRIGHTS.EXE to get around the problem.

So anyways, it's now 2008 and I'm running MSI 4.5 and sure enough, it's still a problem. Ugh. The good thing is I've since learned C# ( Gatereader was a .NET 1.1 application at the time ) and I've got DTF at my disposal. This allows me to make use of a project that was available on CodeProject some five years ago that at the time meant nothing to me:

LsaUtility.SetRight( session.CustomActionData["ServiceAccount"], "SeServiceLogonRight" );

Nice, thank you DTF! Now my real implementation is datadriven using the ServiceInstall table but I wanted to show how simple the problem is to solve with just one line of C# thanks to a freely available class file and DTF.

So while some things stay the same, some things actually do get better.

35 and Counting

Anyone who knows my wife knows that she loves to make a big deal out of birthdays. So when my 35th birthday came around she pulled out all of the stops for me. The trip to Best Buy to let me pick out a new LCD monitor was a real treat not to mention a productivity improvement. The trip to Rudy's BBQ for brisket, sausage, turkey, chicken and all the sides was great also. A Dairy Queen ice cream cake was a prerequisite also. After all of that excitement and food I just had to get an hour and a half massage also.

But the best was having my sister-in-law take care of the girls while Cheryl and I spent the entire day together at Six Flags Fiesta Texas in San Antonio. We had visited back in August as part of our South Padre vacation but today was just two people totally in love with each other having a great time as adults with no kid duties. What a day! It felt like a second honeymoon 11 years in the making.

Generating GUIDs Easily

Bob Arnson (MSFT) recently posted a blog where he provides sound advise about when to use a new UpgradeCode. He also posts a link to a `reputable online retailer` that provides GUIDs.

Now I'm sure Bob was being funny when he says `reputable online retailer`. However, should you really have to go through a multiple step process using an external tool just to generate a GUID? Shouldn't your MSI Editing Tool provide this functionality?

Well, if you are using an Industrial Strength Household Name MSI Editing Tool, it does. Just about every designer in InstallShield will either auto generate a GUID ( like when creating a new component ) or provide a one click button for generating and applying a different one (like when defining multiple product configurations that may or may not share an UpgradeCode as Bob mentions).

Also if you need to do any GUID manipulation at build time there is an automation interface that includes a GUID generator and classes that represents all aspects of the project that you can apply the GUID to.

This may seem like a trivial disagreement, but I work on installs full time and every single feature like this helps me to improve my productivity. Besides, we all know what happens when you don't provide this level of automation and the developer doesn't seek out a `reputable online retailer` of GUIDs.

WixBinaries.2.0.lib {DEADBEEF-DEAD-BEEF-DEAD-BEEFDEAD3010}
WixBinaries.2.0.doc {DEADBEEF-DEAD-BEEF-DEAD-BEEFDEAD3009}
WixBinaries.3.0.doc {DEADBEEF-DEAD-BEEF-DEAD-BEEFDEAD3009}
Templates.UISample {DEADBEEF-DEAD-BEEF-DEAD-BEEFDEAD0014}

Fact Check: InstallAware First and Only to Support SQL Server 2008 and .NET 3.5 Service Pack 1

I received the following boasting claim via email today:

InstallAware 8 is the first and only installation toolkit to support Microsoft's newest technologies released with Visual Studio 2008 Service Pack 1 - Microsoft SQL Server Express 2008, .NET Framework 3.5 with Service Pack 1, and Visual Studio 2008 MFC Runtime with Service Pack 1. We're making this support available in just two weeks after Microsoft released Visual Studio 2008 Service Pack 1 to manufacturing, preserving our tradition of always being[sic] all other vendors to it, including InstallShield!

I found InstallAware's statement very interesting because I've just finished a sprint where I delivered 10 installs in 2 weeks. Each of these installs are components of an SOA based system heavily relying on .NET 3.5 SP1 and SQL Server 2008. It's a brand new product line for our company written by a team that's dedicated to being on the cutting edge of Microsoft technologies.

But how could I have possibly done this work if InstallAware is just now the first vendor ( including InstallShield!! ) to support these technologies?

Easily, I used InstallShield.

As I previously posted, InstallShield has a flexible feature called Prerequisites that allow you to define how to detect and install a component via setup.exe. This is similar to what the WiX team is trying to achieve with burn only InstallShield has had it for years. ( As an aside, burn looks promising, but since it was dropped from WiX release 3.0 due to rosario ship considerations don't expect it to be released for quite a long time to come. ) Using the prerequisite editor, it's a simple 5 minute job to include .NET 3.5 SP1 and the latest MFC runtime ( which we don't use thankfully ) in your install.

Additionally InstallShield's SQL scripts pattern continues to work very well with SQL Server 2008. True, there isn't a dedicated setting that says "Support SQL 2008" but there is a customize checkbox that is far more powerful:



As I've previously posted, don't believe everything you read on the internet.

Microsoft Application Virtualization 4.5 RTMs

I haven't had time to look more closely at this, but I noticed that Microsoft's Application Virtualization 4.5 product ( formerly SoftGrid ) has RTM'd. Until I have a chance to learn more, here's a link to follow.
Pulling this down and playing with it has to be more productive and interesting then playing Setup Police and berating Google for their setup violations.

Google Chrome: Steal this browser

I was reading an interesting article from Ed Burnette at ZDNet:

Google announced a new web browser today called Chrome. Analysts who wonder if this spells “doom” for Firefox, or if it’s an “IE killer” are missing the point. Like Gears, Chrome is Google’s latest attempt to lead by example, and push the envelope of the web experience.

The article includes this comic strip panel from Google:



Now I have such a one track mind sometimes that I couldn't help think about WiX and other setup tools vendors. My observations are that while WiX is open sourced, Rob Mensching tends to get very irritated companies other then Microsoft take his code and turn it into a revenue generating product. Case in point being is his comments aimed at InstallAware when WiXAware was first released. I also happen to know another well known tools vendor is very hesitant to include WiX technology in their product. I also believe that this is not an engineering reason rather a fear of opening a can of worms.

The truth is there are some things in WiX that are very good and it would be really interesting if the Google model could be followed. We'd probably all end up with better tools.

Unwinding after a sprint

Over the years I've noticed that it seems I'm always extremely busy before and after taking time off from work. It's almost pointless to have time off from work since I always end up getting worked so hard that I end up needing the time off instead of just enjoying the time off.

At the beginning of August I found out about a new project at my day job that kicked off an intense week of planning before taking a week off in South Padre. It was suddenly a really bad time to take a vacation but it had been planned for months.

When I returned, I decided to pack up my office and move closer to the developers I'd be supporting. I spent the next two weeks `embedded` with this development team attempting to gain their trust, understand their problem domain, influence their software design choices and ultimately deliver the best build and installer experience possible. When I first started interacting with this team I wasn't sure it was going to go well but it actually turned out really nice. We completed our first sprint and delivered the first 10 of about 40 installs to QA. The ground work has been laid and the remaining 30 installs will just be details over the coming months.

Since then, I've spent the last two days enjoying labor day weekend with my family. It's been so relaxing. I've missed them so much and it's so nice to hear my family say "Daddy, where have you been? We miss you." It feels like I'm back in South Padre spending all day and all night with them once again.

Farewell EDS

I previously blogged early this year that it was going to be An Interesting Year Of Change To Come. At the time I wrote:

I can't help but notice the pendulum swing that's happening and I advise everyone to seek knowledge and apply it to your own personal situation. It seems that change is in the air again ( as it always is ) and it smells like recession driven merger and consolidation. Just about every industry that I've been in is seeing a lot of activity in this area and a few minutes ago I found out that I've been `sold` once again.

At the time, I had worked for a private company (Hart InterCivic) which was sold to a public company (Manatron) which was then sold back to another private company (TCB) who just happened to have also bought a software division (InstallShield) from another public company ( Macrovision ) to form a new company (Acresso). Then there was another private company I worked for ( Austin Information Systems ) which aquired private equity to become another company ( Overwatch Systems ) and finally sold to a public company ( Textron ). I didn't stick around for that deal to finish though.


Add in some contracting agencies, dot bombs and airlines ( which almost merged ) and my work history becomes somewhat confusing. Ohwell, at least there will always be a United States Marine Corps! Red and Gold baby, forget purple.

Anyways back to my original reason for posting. Today HP closes on the EDS deal for some $13.9 billion USD.

Wow. There were always rumors of a sale when I worked there (1996-1999,2000-2005) but today is finally the day. I always liked the teams I worked on for EDS but the company as a whole never really seemed like a real winner as evidenced by their really low profit margins over the year.

Well I yanked my 401K out last year and here's hoping that my pension fares well.

Farewel, EDS. You opened a world of opportunity for a young former Marine. I learned a lot from you and this eagle will miss you.

Don't Believe Everything You Read

While I've been a dedicated build/install guy for about 12 years now, I still spend a lot of time on the internet researching and honing my craft. During this time, I often come across posts from otherwise seemingly competent Software Engineers who grossly underestimate the complexity of setup. They frequently post messages in an expert voice that outline solutions that are far from best practice.

Tonight I read a message thread where someone was having a problem getting a WiX DTF Managed Custom Action to display a MessageBox. Another developer quickly replied with the traditional `Managed Custom Actions are Evil` mantra:

Using C# is the problem. You have to use a native Win32 DLL for a custom action, not managed .NET code. This is an ongoing debate because more and more programmers are .NET-only (which is, but this is strictly my personal opinion, a very big problem, programmers have to know several languages, including C, C++ and Pascal and similar to call themselves programmers but I digress) and .NET does offer a nice, cosy environment to do things in. Still, this is not an arbitrary limitation, it has it reasons. See http://www.tramontana.co.hu/wix/lesson3.php#3.5 for a short description and a link to Rob's blog detailing the issue.

Wow. This is simply not true... the debate is dead.

Anyone with more then a passing interest in Windows Installer knows that three months ago MSFT/WiX/Rob/et al did a 180 degree, ABOUT-FACE!, flip/flop and started supporting managed code custom actions when they released Deployment Tools Foundation (DTF). Rob's blogged it, Justin's blogged it, I've blogged it repeatedly ( with tutorials ), InstallSite has covered it, it gets discussed in the WiX list, the Platform SDK newsgroup and even the InstallShield Community forum. You simply can not be a Wi/Wix/IS/Setup Expert and not know about DTF. Period!

The interesting part is that the person who made this comment also runs the Tramontana WiX tutorial site which is often cited by beginning WiX developers as `I'd never gotten it done without this tutorial!`.

A quick review of that tutorial shows that the topic on managed code custom actions is full of out dated information citing outdated references.

Another interesting observation in my mind is this developers bias in implying that real developers should be able to code Win32 DLL's in multiple languages such as C, C++, Basic (what version? VB6 couldn't natively export Win32), D, Eiffel and Pascal in order to claim that they are real programmers. All of this while eschewing the .NET framework.

Very interesting. Anyways, I'm not meaning to hurt anyones feelings. I just wanted to point out that you should be very careful what you read on the internet. This site excepted of course. :) ( Seriously, when I make mistakes, please leave a comment.)

So Much Testing, So Little Time

A year ago, I shared both my love of Hatch Green Chili Peppers and my favorite dip recipe. Well, it's that time of the year again to stock up on more of these lovely peppers. You see, I didn't plan well enough last year... I ran out of peppers near the end of January. Sadly, the Hatch Green Chili with Asadero cheese pork sausages and Hatch flour tortillas were gone even sooner.

So this year I've tripled my stockpiling to make sure that I won't be running out! While I was at it, I picked up this really interesting new recipe book from Central Market. The story behind this cookbook is foodies were asked to contribute recipes and a sample as part of a cook off. The recipes were then published without ever being edited or tested in any way. To me that just won't do so there is only one thing I can do about it....

So much testing, so little time!

Concurrent vs Consecutive Build Performance

Lately I've been working on integrating BuildForge with TFS Team Build. One feature missing in Team Build v2 is the ability to automatically load balance build servers. Hey Microsoft, DefaultBuildAgent=FirstAvailable would be REALLY cool!

Fortunately BuildForge has a useful ability to define a pool of build machines that meet a set of criteria ( Selectors and Collectors ) and then specify how many concurrent builds can run at a time ( _MAXJOBS=xx). With a little bit of plumbing I can use BuildForge as a bootstrapper to kick off Team Build's across a build farm.

Way Cool! But how's the performance? The numbers above were taken using an HP DL-380 G5 with 3.0GHZ Xeon, 16GB of RAM and a SAS RAD5 storage running Server 2008 Hyper-V. Not the fastest machine in the world but it'll do. Each build represent a small .NET 3.5 Windows Services project that also builds an InstallShield Merge Module and Product Installer.

As you can see, when running consecutively each individual build is about 30% faster. However when you compare the overall throughput the concurrent builds are nearly 3x faster!

Of course the real beauty is that this system is now scalable to N number of virtual build servers. Just drop another hypervisor in the rack, fire up some VM's and add them to the collectors.

How's that for a little zoom zoom zoom?

As an aside, I was monitoring the performance and I could see that I was DISK I/O bound. CPU and memory was fine.

Here we come Kindergarten!

It's hard to believe it was only 5 1/2 years ago that I was endlessly shoveling snow in a futile attempt to be able to get out of the drive way in case my wife was to go into labor. Soon, Ashley will be going to Kindergarten.

Wow.

I just spent the last week with my family in South Padre Island and it amazes me how grown up she is becoming. Only a few months ago she could barely pass her swim test at the YMCA and now I watch her swim and tread water in the deep without her floaties. I watch her make friends on the beach and go out to the surf zone on her boogie board. We do all of the rides at Schlitterbahn and a REAL roller coaster at Six Flags. Although I think she reconsidered that decision since she didn't want to ride it a second time. She sings all of the songs from our latest Laurie Berkner CD and she sounds out and recognizes words.

Wow, we are so proud to be her parents. I hope letting her go to school isn't too rough on us.

.NET 3.5 SP1 - 231MB 255.5MB - Ya, It's Really That Big!!!!

I've been enjoying my time in South Padre but tonight I noticed a couple things about the newly RTM'd .NET 3.5 SP1 release. As I've previouly blogged the framework is huge and it's only getting bigger and bigger and bigger.

1) The full package is a 231MB download. .NET 3.5 RTM weighed in at 197MB so that's a 17.26% increase. Christ, I really wish my 401K would do that instead.

2) The .NET 3.5 SP1 `Client Profile` is now a 255.5MB download. Huh? Why is it bigger then the full package? I thought it was supposed to be about 26-30MB?

[Edit: The client profile download is now a broken URL.]

3) If you want to use the (initially) tiny web download / bootstrapper version (2.8mb) don't expect it to actually work if your customer is using a firewall. Then again, that's probably a good thing considering if I ran a network I wouldn't want dozens of clients pulling down a quarter of a terabyte (edit: oops Gigabyte!) in data just to run a program written in managed code.

Now I'm a huge fan of .NET, C#, VSTS, TFS, et al but I'm really at a loss for this one.

Standing by for DTF Release

A little birdie has recently mentioned to me that today's WiX release will include a version of DTF that supports the MSI 4.5 Embedded UI Story.

Rock On!

I go on vacation for a week tomorrow and now I know what I'm going to be doing at night for fun. :-)

So hopefully in a few more hours it'll be here for download.

I'll be blogging about it once I have my arms around how to make it all work. As a teaser, here's where I plan on going with it: Imagine an InstallShield 2009 Basic MSI project stripped of it's UI sequence and driven by Winforms with a setup.exe bootstrapper uses setup prerequisites to install MSI 4.5 and .NET 2.0. Finally imagine a feature tree that merely has references to chained installs as feature prerequistes.

I have a new product line at work that I'm supporting that's going to be creating about 10 installs chaining different combinations of about 70 micropackages. All of the code is written in VS2008 so it should be very interesting. I'm thinking of trying to make this look as slick as the Visual Studio 2008 install.

InstallSite Swag Give Away

Windows Installer MVP Stefan Krueger recently announced that he's going to give away a 1 Yr Not-For-Resale MSDN Premium Subscription. He's accepting nominations from his readers.

Official Google Blog: We knew the web was big...

I noticed today that a new search engine was born. I tried it and didn't like it. It seems that everyone wants to try to be in the search business. Well, really they want to be in the advertisement business but that's another story.

I recently read an article where Steve Ballmer was mentioned:

"Earlier in the day Ballmer referred to the situation as a circular conundrum because advertisers don’t want to sell on Live Search unless there’s more people using the site, and people don’t want to search on the site unless there are more relevant ads."

Well, call me stupid but I don't get that reference. People don't visit search engines to see relevant ads, they visit it to see relevant search results which happen to have ads snuck into the result set.

Anyways Microsoft is pointlessly spending big money in this area IMO. Take a look at my StatCounter logs and you'll see that literally 92.27% of my search engine related pageloads come from Google. 6.87% come from Yahoo! and a mere .86% come from Windows Live.

I guess those were the idiots that didn't change the search provider once they upgraded to IE 7.

Anyways, here's a nice read from Google today:


Official Google Blog: We knew the web was big...: "up of one trillion intersections. So multiple times every day, we do the computational"

ack/nak: phillips medical: installation developer job opening

I noticed a help wanted post over on my friend Bob Corrigan's website. Anyone feel like looking into a new opportunity in sunny Boca Raton, FL and helping Bob get a ham for thanskgiving?

ack/nak: phillips medical: installation developer job opening

Entity Framework - No Confidence

In the .NET circles I always here comments regarding EF. I usually stay clear of them since I'm an Installation Developer not an Application Developer. Recently I was asked to write an install for a program that had a dependency on ADO.NET EF Beta3. I downloaded the EFB3SETUPX86.EXE package and tried to install it.

The keyword is TRIED.

The first error message informs met hat I must have .NET 3.5 installed. Funny, it is installed. Then I get a fatal crash. Ohwell, atleast the MSI is using the ubber-cool Red motif!

Either way I did some poking around and I found this launch condition to be the culprit:

Installed OR
(DP_NETFX35_INSTALLED_VERSION >= "3.5.20904.00") and (DP_NETFX35_INSTALLED_VERSION <= "3.5.21203.00")

I seem to have .NET 3.5 SP1 ( BETA ) 3.5.30428.01. Funny, EF BETA 3 package seems to be hardwired to not run against a beta version of the framework when it's a beta package itself. The part that really threw me off is the way the externalUI is used it looked like the LaunchCondition was information and something else blew up later.

Windows 98 on Hyper-V

I was goofing around the other day trying to get MSDOS 6.22 and Windows for Workgroups 3.11 working on Hyper-V. It's amazing how much I still remember about optimizing upper memory blocks. Either way, I did get WFW to go through setup but when I typed WIN it hung after the splash screen.

All fun aside, I was recently contacted by a potential client who needs an install created and tested on Windows 98! I don't know about you, but I haven't used Windows 98 in a good 6 or 7 years.

Now lately a lot has been made about Microsoft trying to kill of Windows XP, but has any one noticed how many operating systems have been killed over at MSDN Subscriber Dowloads? Windows 98 is *GONE* allegedly due to the Sun vs Microsoft Java war.

Then there is the problem that Hyper-V doesn't support Windows 98 integration components. Virtual Server 2005 is probably a better choice since it emulates an Intel 440BX/82371AB South Bridge with S3 Trio 64 video card. This is hardware that Windows 98 should be very comfortable with.

Well, here's hoping for the best. We'll see how far I get before I want to just go find an old computer off of Craigslist for this one time project.


However I'm going to give Hyper-V a try for now. I've hunted around and found a copy of Windows 98 so here's hoping for the best.

Virtual Brownbag - Installation Testing with Hyper-V

I've been giving a lot of informal brown bag presentations at work lately so I thought why not try to do it online? The size and quality of the video isn't really what I'm going for so I'll probably try to find a better hosting service and then relink the video at a future date.

This video discusses how to use Windows Server 2008 Hyper-V on inexpensive white-box hardware to provide a robust installation test environment. Future videos will show how this system can also provide all of the other services needed in a stand alone development environment.

The video is merely a capture of my desktop with voice overlay. Let's face it, what's going on in the presentation is what is important, not what the author looks like.

Note: Be sure to check out other videos on Hyper-V that You Tube suggests by clicking the icon in the lower right hand corner. Also, the video uploaded is small so here is a detailed screenshot of what the snapshot tree looks like (I suggest opening it in a new tab and referring to it):

Multiple Language Resource Files - Quick & Dirty

Chris recently forwarded me a message from a reader asking for help installing language resource files via MSI and InstallShield. My response ended up being a lot more involved than I had originally planned so I thought I would blog about the topic.

First, a couple of notes:

1. The information below is probably the easiest method for a few resource files with different names only. That does not mean it is a best practice. In fact, it isn't a best practice - if you have a lot of resource files or all the resource files have the same name, then you'll want to review MSDN topic Localizing a Windows Installer Package and the available Localization Example and author the MSI accordingly (to NOT use component conditions to control what files get installed).
2. If you're using merge modules, you should review the MSDN topic Authoring Multiple Language Merge Modules AND review the InstallShield topics (because IS doesn't support authoring multi-language merge modules so if you need to exclude languages at MSI build time then you would need to create a different module for each language).
3. If your MSI package has UI text streams that are localized, make sure the default code page property is set appropriately, that InstallShield is set up to generate multiple language transforms (1033.mst, 1036.mst, etc.) for each language you will support, and that the database summary information stream properties for the Template Summary and Codepage Summary are set correctly.

If you do need to only install one resource file depending on the OS language, then you need to add each resource file to the merge module as a separate component and then use a component condition to evaluate the SystemLanguageID property. Another advantage of this approach is that you can localize your shortcuts, registry entries, etc. because the records in those tables are tied to a particular component. So, if you had a shortcut with French text you would assign the shortcut table record to the component with resource-fr.xml as the key file and the shortcut would only be installed when the resource-fr.xml is installed.

If having multiple resource-??.xml files on your system is a problem, you need to do the following two things:

1. Go smack the application developer upside the head. S/he should have coded the application to detect the language and load the approprate resource at run time.
2. Make sure that the grouping of components is conditioned such that they are all mutually exclusive. IOW, only one of the components can possibly be installed at one time.

For example, to install only the French resource file, add a component with key file resource-fr.xml and set the component condition to:

SystemLanguageID=1036

The component will only be installed on systems where the System Locale Identifier Constant indicates French (0x040c hex - 1036 decimal).

If you need to install the French resource on other French locales (such as Belgium, Canada, Monaco, etc.) you would need to expand the condition to:

SystemLanguageID=1036 OR SystemLanguageID=2060 OR SystemLanguageID=3084 OR SystemLanaguageID=6156

Also, whatever your default language should be (English?) then you want the condition for the component that contains that resource file to evaluate so that it installs on all systems that don't match any of the conditions for the other resource components. So if you only had French (with the previously mentioned locales) and English and you wanted English to be the default then you would set the condition for the English component to:

SystemLanguageID<>1036 AND SystemLanguageID<>2060 AND SystemLanguageID<>3084 AND SystemLanguageID<>6156

...and NOT to:

SystemLanguageID=1033

...since the latter will only install on systems where the local is set to English-US (IOW, any other system not covered by the other component conditions would never get any resource file installed).

A couple of other issues to consider:

1. If your MSI can be installed per-user, you will also want to consider conditioning the components using the UserLanguageID property as that can be different from the SystemLanguageID (a user can set their user locale to 'French' when the system locale is set English so they see French and other users of the same system see English).
2. To cover the scenario where your user installs under one language, changes the language settings, and then run's 'repair'. Make sure you set the msidbComponentAttributesTransitive attribute flags for your components with conditional statements so the conditions get reevaluated during a maintenance mode installation. This would allow the originally installed language component to be removed and the new language component installed for this scenario.

Horrible Patching (no)Strategy

Edit: Some blogs are now reporting that this KB consumes 1GB of disk space, crashes machines and reports your machine as `unsafe` if you defer it.


I was browsing tweets out of boredom when I came across this funny tweet:

okay the latest windows vista update 955020 is 56mb, to add 5 words to the windows dictionary

So I followed the link to KB955020 and sure enough Microsoft released today a patch that adds the words Friendster, Klum, Nazr, Obama and Racicot to the English dictionary in Vista and Server 2008. They have 5 separate downloads for the different platforms and the Vista x86 download ( Genuine Validation Required ) is 56.4 MB. x64 clocks in at 63MB!

Wow

It seems that the system stores all of it's keywords in dll's. There is a Custom.dic file for augmenting user provided words but there is no concept of extending the pattern with additional layers of keywords from Microsoft. So large dll's have to be sent over the wire to fix the problem.

Who wants to take a guess that the person who designed this system never didn't' really care about deployment?

And I thought the .NET Framework was getting huge...

Five Years of Windows Installer and Texas

It just occurred to me that 5 years ago ( yesterday ) was my first day on the Continental Airlines account in Houston, TX. Wow, time flies.

This also marks a second anniversary for me: 5 years of Windows Installer

I'd been writing InstallScript installs since 1997 for various beltway bandits in Northern Virginia but I had intentionally shunned Windows Installer due to my perception that it was slow, buggy, rigid and entirely over engineered. Frankly my installs WERE Bullet Proof and I didn't need Microsoft jumping into the setup space like they had with web browsers, 3D API's and office suits.

I recall doing a PVCS Version Manager deployment and watching how slow it installed on a Pentium 200. The endless repeating of the progress bar was not entirely unlike the scene from Office Space. In the summer of 1999 I had played with InstallShield for Windows Installer beta prior to Windows 2000 being released and I remember being completely unimpressed with Windows Installer.

Anyways, one day Cheryl wanted to move to Texas and before I knew it I was speaking to an IT Director who wanted to repackage his applications into MSI format and deploy them with SMS. Learning MSI suddenly became a priority.

Many, many hours would be spent reading everything that I could on the subject trying to get a firm understanding. A good six months would pass before I started to see light at the end of the tunnel and believe that Windows Installer was actually a better way to roll. A full 18 months of learning, doing and helping would pass before I decided that I was ready to blog on the subject.

As an aside, it's interesting that I was actually originally inspired to blog by Rob Mensching.

After my 6 month contract at Continental turned into 2+ years, we decided that it was time for a change again. ( Seriously, who in the world can work for one company for years and years these days? Developers need cross polination to keep it fresh. ) Before we knew it, we landed in Austin and we really love it here. For anyone who's never been here, it's a really great place to live and work as a .Net/MSI junkie.

Reasons DTF is Better

I've found myself repeatedly answering emails on this subject so I thought it would be a good idea to officially publish my reccomendation.

As much as I appreciate the work Acresso did on Managed CA's, DTF is clearly the better direction to go.

1) DTF solves the problem of tatooing the msi process with a fixed version of the CLR.
2) MakeSfxCa is more flexible and intuitive when dependencies.
3) The MSI interop object model is simply better from a C# coders perspective.
4) The hosting process has an easy debugging story.
5) Being open source it's easier to see problems and get resolutions to issues even if that means doing it yourself.
6) There is no vendor lockin. You can build and consume custom actions in a variety of ways including integration with InstallShield. (That's the way I roll.)

Dynamic Windows Installer UI

I was reading a discussion on Dynamic UI for Windows Installer recently and I came across a post where there was some confusion over what MSI can internally do without the help of an external UI handler. I know in the past I've written custom actions to dynamically generate content for ListBoxes so I thought, why not be able to do it for other UI controls?

Fortunately DTF makes this kind of coding really, really easy. Here is a quick example:

using System;

using Microsoft.Deployment.WindowsInstaller;

namespace dynamicui

{

    public class CustomActions

    {

        [CustomAction]

        public static ActionResult DynamicUI(Session session)

        {

           InsertRecord(session, "CheckBox", new object[] { "DYNAMICPROPERTY", "1"});

           InsertRecord(session, "Control", new object[] { "CustomerInformation", "CheckBox1", "CheckBox",

                                                           144, 181, 198, 22, 3, "DYNAMICPROPERTY",

                                                           "Dynamic CheckBox", "", "" });

           return ActionResult.Success;

        }

        private static void InsertRecord( Session session, string tableName, Object[] objects)

        {

            Database db = session.Database;

            string sqlInsertSring = db.Tables[tableName].SqlInsertString + " TEMPORARY";

            View view = db.OpenView(sqlInsertSring );

            view.Execute(new Record(objects));

            view.Close();

        }

    }

}

In this example we insert 2 temp records into the MSI tables prior to displaying the CustomerInformation dialog. One record defines a CheckBox control on the CustomerInformation and associates it to the public property DYNAMICPROPERTY. Another record says that when the CheckBox is checked, that the property should have the value of 1. Otherwise it has a value of not-set.



Now I should note that in real life this would be a little more complicated. I intentionally did not subscribe to a tab order because I would have to do additional queries to be able to know how to inject myself into the tab order. Caution would also be highly advised since my new table records haven't gone through ICE validation processing. The normal way of doing things here is to have a bunch of static/disabled controls that you dynamically enable at runtime using ControlConditions. However, I could see a scenario where more flexibility is required so this pattern could be of help one day.

For additional fun, here is a half baked - off the cuff thought: This example is like reflection emitting (.NET IL ) instad of CodeDom ( language aware ). It would be interesting if DTF had a pattern that was aware of WiX XSD schema and could dynamically generate temporary MSI records based on WiX source inputs.

DeploymentEngineering.com Buzz

I'm not sure who I have to thank, but it seems that DeploymentEngineering.com was nominated in ComputerWeekly.com's IT Blog Awards 08 in the Programming, development and technical blogs catagory.

Now we didn't make the `short list` but I think it's pretty cool that a blog about deployment topics would even make the list at all considering what little respect this space gets in the first place.

Pretty cool, thanks readers!

No Evidence Of Disease

I wanted to share some good news with everyone today. Over the past few days Cheryl has had various tests performed including a colonoscopy, CT scan and blood work. After countless medical treatments that would seem cruel and unusual punishment by almost any standard, I'm very happy to report that at this point she is currently considered `No Evidence of Disease`!

While we aren't out of the woods yet ( I don't want to dwell on that aspect), we certainly have enough reason to go out and celebrate tonight.

I sincerely thank everyone who has helped us with support and prayers. We are very grateful for all of the help and friendship that has been given.

Hyper-V running Fedora

I don't talk about this much, but I wasn't always a Windows GUI guy. In fact I spent many years programming Commodore 64's and Apple II's. My first shell was CPM on a Commodore 128 and of course I spent many years on Amigas back in my FidoNet BBS days. I used to be raving nut case when expressing my hatred for Bill Gates and Microsoft. Of course that was the proper thing for any self respecting Amiga fan-boy back in those days. Let's face it, MS-DOS/Windows 3.1 really did suck compared AmigaDOS/WorkBench. Back then I had a GVP GeForce040-33 board and I ran MSDOS/Windows via PC-Task and had an Emplant board for MacOS so I was no stranger to emulation/virtualization.

Then one day I realized it was time to get out of the Marine Corps and go pro. I built my own 486DX-120 and loaded Slackware on it. Over the following few years I actually spent quite a bit of time on various Linux and Unix OS's ( Slackware, Mandrake, Redhat, DGUX, HPUX, Solaris ) doing back end ANSI C programming and shell scripting for various Department of Defense Client/Server systems. It's amazing how many vi commands I still remember. But for the last few years I've really gravitated away from that world and into a GUI world of NT and .NET. I still remember all the old stuff, but for the life of me I can't imaging why anyone would actually prefer to write code with such primitive tools.

Lately I've been playing with Hyper-V a lot and I thought it was really cool that not only could it run Windows but it can just as easily run Linux.

So I fired up a torrent to pull down the latest Fedora 9 and decided to install it. I haven't really done much with it yet but I've got to admit, it has a wonderful blue motif logon screen.

Phenomenal cosmic powers! Itty bitty living space.

For those who remember the movie Aladdin, "Phenomenal cosmic powers! Itty bitty living space." is a perfect quote for my new server that I have been working on for the past week or so.

It's unbelievable what a 2.4 ghz quad core, 8GB of memory and terabytes of RAID storage can accomplish. Thanks to Hyper-V I've set up an entire network of virtual machines that provide every function needed for the proper development and testing of applications and installers. It really rocks!

As an aside, I saw yet another red motif troll post so here's a plug for blue just for fun.

Three Reasons it's a Great Day

1) After nearly 70 years of silence, the Supreme Court of the United States of America has finally ruled that gun ownership is an INDIVIDUAL right and struck down the District of Columbia's ban on hand guns. Way back when I was in the United States Marine Corps, I lived in a row house in South East DC ... 6Th ward. I had bars and locks on all of my doors and windows and would routinely hear gun fire at night while working on my FidoNet BBS. I couldn't believe that as a trained marksman in the US Armed Services that I couldn't have a weapon in my very own home while all of the violent criminals in the nearby areas were packed to their teeth. Texan leaders played a huge roll in this case and to them I say THANK YOU. Everyday ( and today in particular ) is a great day to be a Texan.

2) Hyper-V is RTM!!!!! ( Of course this would happen as soon as I build my server. I hope it's an easy upgrade!) VMware should be afraid, very afraid.

3) After being out of service for two days, our HVAC is finally working. Whew, damn it's hot in Texas!

Ask the readers...

I need some suggestions from everyone out there.

We are considering moving away from our current install product to a new one. I need some suggestions on what should be put on our short list for evaluation.

Here is a little information about our environment and requirements:

• Integration with PVCS would be a definite plus
• We support multiple languages (FIGS, Turkish, Japanese, Chinese, Portuguese, et al)
• Support over 40 products with multiple branches (~150 projects in all, conversion will be a factor)
• Support for Windows 2000 SP3 (Pro and Server), XP, Vista, Server 2003, Server 2008, IIS5 and above, SQL 2000 and above, Oracle 9i and above
• We have a homegrown automated build application so OLE automation /COM support is an absolute must
• x86 & x64 support

I think those are major factors for consideration. I would be interested to not only hear from users but also Product Managers if they wouldn't mind hearing from a squeaky wheel.

InstallShield 2009 SP1 Released

Windows Installer Expert Stefan Krueger reports that InstallShield 2009 SP1 is now available. In case you are wondering why an RTM product would need a Service Pack in 15 short days, well it basically has to do with decisions that were made to ship 2009 with MSI 4.5 Beta 2 support in time for TechEd 2008. So in my mind, this is the `REAL` InstallShield 2009 and hopefully Acresso will continue to release service packs to address problems found.

Like Riding a Bike

Lately I've been realizing that I needed to upgrade by build/install/test infrastructure at the house. For the past few years, I've been buying laptops and a quick review of Newegg revealed that I hadn't built a machine since 2003. Wow, had it really been that long?

I've always been a hardware geek. My first hard drive was a Xetec Lt Kernal 40MB for a Commodore 128D. Installation required that I make certain modifications to the motherboard. Later I'd have various Amigas where I'd replace the OCS chipset with an ECS chipset, install a Fat Agnus, upgrade Kickstart ROMS and of course install ZIP DRAM modules. Wow, that's going back aways... 15 years?

I've built many machines since then. When I lived in NoVA I'd reguarly take clients shopping and build up a rig for them. So much time would be spent studying the current sweet spot and features/limitations of all the products available. My skills were so well trusted that I was actually allowed to build white box build servers for a large government contract that normally played it very safe. One day we had some fried caps ( it really smelled ) and within 2 hours I'd gone to the local vendor, picked up another motherboard for a very cheap cost, and brought the build box back up. Anyways, it's really funny to see what Virtual Server 2005 emulates since I knew the 440BX, Trio64 configuration very well.

So what did I buy? I went with an Antec NSK4480 case with a 380Watt 80+ PS. An Intel DG35EC uATX motherboard with integrated video, audio, usb, firewire, SATA-II, PATA and GigE, an Intel Q6600 2.4G Quad Core and 8GB of DDR2-800 memory. Frys had some good deals for a change so all of this inc tax and same day pickup was $550. Not too bad.

I'm going to reuse some hard drives for now but soon I'll be picking up a couple WD 300GB Raptors. Those really look like nice drives.

I'm currently loading it up with Server 2008 and Hyper-V. I also want to setup SqlServer 2005, TFS 2008 Workgroup Edition, TeamBuild, a development VM and a bunch of test VM's for integration. Man, it's going to be so much fun. :-)

InstallShield Stand Alone Build Announcement

Two weeks ago, I blogged about Acresso's decision to finalize the removal of the Stand Alone Build Engine from InstallShield 2009 Professional. This decision adversely effected certain long-term, loyal customers who had purchased maintenance agreements with the expectation that this core feature would remain. While I disagreed with the notion of InstallShield Professional not coming with a build box component for new customers, I found it utterly revolting that existing customers would loose this critical piece of functionality for which they had prepaid. Windows Installer Expert Stefan Krueger also shared his thoughts but a link to his blog ( InstallShield 2009 Caveats) is currently not available. Additionally many of my readers stood in solidarity and expressed their opinions to Acresso.

Over the past two weeks I've had back channel conversations with employees of Acresso and other members of the community. Today I have some progress to report: Jeff Greenwald, Director of Enterprise Product Management, has formerly announced that these customers will be taken care for this release. However, future versions of InstallShield will have the Stand Alone Build moved to Premiere so this fact should be considered when deciding your future purchasing options. I've also expressed some ideas on additional ways to sell the Stand Alone Build and Acresso will attempt to work out a business model that makes sense for all.



Below is the post from Jeff:

We recognize that their may have been some confusion regarding the availability of the Standalone build with the release of InstallShield 2009. To assist our longtime loyal customers in this transition, we are granting access to the Standalone build functionality under the following criteria. Specifically, InstallShield 2008 Professional customers on active maintenance who also licensed InstallShield Professional 10.x or InstallShield Professional 11.x will be granted access to the Standalone build functionality.

For future releases of InstallShield, the Standalone Build functionality will continue to be packaged exclusively with the Premier Edition as announced with the release of InstallShield 12 in 2006. InstallShield Professional customers looking to leverage the Standalone Build module will need to upgrade to the InstallShield Premier edition. Each full license of InstallShield Premier Edition includes 10 Standalone Build modules.Efforts are currently underway to update the Standalone build installer to support the model described above. Additional information will be posted to this community once these efforts are completed.

Thanks,

Jeff Greenwald
Director, Product Management

1500 Hard Drives

Maybe it's just been a long week, but this one really cracked me up today. I know it's made it's way around the internet, so please forgive me advance...

Btw, nice house. Perhaps I should be modding consoles instead of writing installs.

Maybe I Should Roll My Own

I've been wondering, maybe I should just roll my own WiX designer.

Yes, I'm serious.


Sure, I'll wait for you to pick yourself up from the floor.


OK, seriously. Can it really be that hard? Let me share with you a screenshot of a program that yours truly (who happens to be a very, very junior .NET developer ) was able to throw together in just a few hours thanks to a few pointers from an experienced .NET developer that I work for:





So let's assume I'm not trying to write a full blown authoring tool. My requirements and needs are fairly straight forward. I use InstallShield in a product line development environment to consume merge modules to build multiple product configurations with various setup.exe requirements. The merge modules come from upstream builds and could easily be broken out further into WiX fragments. Therefore, much of the integration work could still be done in InstallShield while splitting out much of the remaining component authoring to WiX.


I currently have the infrastructure in place to bring all of this together as TFS/TeamBuild can just call Votive/WiX and InstallShield projects to build the fragments, merge modules and installer packages.


The problem I face is that Votive only comes with a simple text editor with basic IntelliSense support. I find it to be very clumsy to use and now I understand why. I read a few articles yesterday on External Domain Specific Languages in XML and one comment that really stuck with me was that XML can be an easy language to read by domain experts but much more difficult to author.


What if I could just have a simple designer without a lot of heavy abstraction to help me bring against the code?


Well, I've just realized that it really wouldn't be that hard to do. I'm sure the .NET developers reading this are laughing but remember, I write installers for a living, not applications. My skill sets and experiences are generally optimized for a different purpose. For those who aren't laughing, let me explain what I learned today.


WiX distributes an XSD schema ( and others for various extensions ) called WiX.xsd. You can run the XSD files through a utility called from Microsoft called XSD.EXE and get a class file that contain classes describing your schema. There are ways to bind these classes to a XML document that allow you to then import and export valid XML. You can also associate the classes to various WinForms controls to give you a visual representation of your document.


If a rank .NET amateur can do something this simple in a day, I can only imagine what a group of experts could do if only given the right user story and resources.

So now I have a decision to make, should I try to organize and take this any further? I read all over that there is demand for this type of tool, but I keep wishing that Microsoft, InstallAware or Acresso would just fill the void with a top quality and affordable tool.

WiXAware is a good start but it's based on WiX v2, is buggy as hell and is incorrect in certain areas. For example, WiXAware makes you define a feature before you can define a component when authoring a fragment. This is clearly incorrect and a simple exercise in reflection reveals that each element class has an Items property that has custom XmlElementAttributes describing the allowable child elements.

Perhaps Microsoft will wow the world with Rosario.

Either way the future is becoming very clear to me, if someone would just take the time to make it happen.

Debugging Legacy InstallScript Engine Problems

I just read an article from ParanoidMike (Installshield – great for developers, sucks ass for victims (aka everyone else) where he does an excellent job of debugging an uninstall issue. He also rips InstallShield during the process.

Some of his conclusions are wrong, but that's not the point. It doesn't matter that it isn't InstallShield's job to support him ( Intel, where he happens to work, wrote the package ) . It only matters that when you are a company like InstallShield, it's always your fault. So while InstallShield 12 was a step in the right direction, it'll take years to be free of the legacy.