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!