AppX Just Might Fail

In my last post I talked about how AppX might work.   Today I'm going to be a contrarian and look at the other side of the coin:   AppX Just Might Fail

A long time ago, Rob Mensching had a blog post promoting a 100% declarative installation model and lamenting custom actions as an admission of failure.  He then went on to enumerate three general reasons or the need of custom actions.  One of them was:

The setup developer wrote a custom action to configure some platform because the platform technology didn't provide installation primitives for itself.  This one is just sad and, unfortunately, happens more often than not. 

100% declarative sounds great, but you back yourself into the "640K is enough for anyone" corner because one day a the "box" won't be big enough and the platform will be too slow to catch up.

Don't believe me?   Take a look at all the times Windows Installer as "failed" us by not providing us a declarative way of doing something?

Read/Write XML
Read INI other then the Windows Folder
Persisting properties across transactions ( "Remember Property" pattern )
Closing Windows and Killing Processes
Executing SQL Scripts
Configuring IIS
Configuring Reporting Services Reports
Recursively deleting directories
Configuring firewall rules
Configuring Visual Studio AddIns
Granting Users Logon as Service Right
Creating Users and Groups
Configuring COM Plus
DIFx
Game Explorer
MSMQ
NativeImage Generation ( Ngen )
PowerShell Snapins


The list goes on and on.   Now I know,  "But Chris,  Metro Apps aren't intended to do those things."   OK,   but do you *REALLY* know what Metro apps need down the road for?  When the requirements change will AppX be updated fast enough to support the new  requirements?

I know Windows Installer has never been able to prove itself in this area.   So the purists can preach that custom actions are a failure and I'll admit in many cases ( reinventing the wheel and writing sloppy CA's ) they are but in many cases they are the only way to get the job done.

So will AppX work holding the line the way it is? I think Yoda answered it best:

Difficult to see. Always in motion is the future.

AppX Just Might Work

Recently, Rob's been blogging about the new AppX installation technology.  My first initial reaction was to cringe and think "Oh yeah, Microsoft is promoting yet another alternative to MSI.  That's all we need!"

At first it seemed like AppX would be just another ClickOnce and suffer the same fate.

On the other hand it's not that I really love MSI or anything.  It's just that for all the complexity of the Windows platform it takes a really complex service to be able to deploy all the possible combinations.  I've always wished that the complexity could be reduced but every year new layers get built on top of old layers making this impossible.  I  guess that's why I disliked ClickOnce so much.   The world simply wasn't ready for ClickOnce.

Now let's talk about Windows 8,  Metro, the application store and AppX.  The world simply might be ready now.

I'll be honest, I love my iPhone and I'm not really a fan of the app store concept.  However Apple is making a boat load of money so obviously I'm in the minority hear.   Now to fit into the nice simple world of Metro apps and the app store  developers will have to develop within the lines of a box.  And AppX seems perfectly capable of deploying applications that fit that box.

Yes, we've heard the lectures in the past about setup development is a first class activity, design for the container and custom actions are an admission of failure.   That kind of talk always irritated me because I knew out in the real world people didn't listen and then dumped the problem on the install guy at the last second.   But now, the world might be ready to let that sink in.  It might be that Metro and AppX makes sense and if enough people want to get into the app store then critical mass can be achieved.

And if they don't, well there's still MSI and no pretending that AppX can replace it like was implied with ClickOnce and MSDeploy.

Also when I read about AppX the XML/XSD aspects had me thinking about writing an IsWiX designer that could author AppX manifests.  However, now that I've downloaded the developer preview I realize that Microsoft has already done this by making a visual designer built right into the project.   Not a seperate project like a WiX or InstallShield module but a manifest right inside the main project the developer is working on.   Now that's making deployment a first class activity in my book.

Appx huh? Hmmm.  They just might finally have something there.

Deployment Engineering has moved

Welcome to the new home of the former Deployment Engineering blog. I've decided to rebrand myself for a number of reasons. First was that my consulting has really been growing and it was time to form an LLC. The use of the word engineering was suddenly a complication due to Texas state law. The second reason is "deploymentengineering.com" is really a pain in the rear to type. I wish I had thought of that many years ago when I picked it for a domain name. :-) The third reason is I want to consider branching out into both products and services. I really like what the ISWIX name represents in terms of both a tool and a philosophy and since I don't have a marketing budget to come up with something fancier like "Qwikster" ( shrug ), ISWIX it will be!

So welcome to the old new blog. All of the historical content can still be found at this new URL.

Tales of Setup Democratization

At my last job, the .NET developers and InstallShield developers embarked on a collaboration excercise that we called 'setup democratization'.  We used a blend of InstallShield and Windows Installer XML.   Most developers used Industrial Strength Windows Installer XML ( IsWiX ) to author their WiX code.

I've asked my former colleagues to post their observations.  Let's see what candid and anonymous comments they have to share.

Farewell Overwatch Systems

The last three years have really flown by.  Two really wonderful things happened:   First, my wife has continued to be cancer free and second, I climbed the Mt Everest of installation complexity and won!   None the less, it's time to move on.
I will miss all of my friends at Overwatch Systems. We really accomplished a lot together but alas it's time for new challenges. So after a week to decompress I'll be starting a new job.  Details to follow.

Farewell Jedi Matt

Two and a half years ago I met an individual by the name of Matthew Tan who inspired me to post the article Come to the dark side.  I had sensed that the force was strong in this one so I gave him as much advice and training  as I could until a month later I left the company to accept the Install Lead position with a former employer.

Six months went by and we were swamped so we needed to hire another setup developer.  I reached out to Matt and asked if he'd be willing to apply.  He did and one day I went downstairs to the HR interview room to meet him.  I wanted to get a sense of how he had grown on his own.  After speaking with him for about 10 minutes it became very clear to me that he was 'getting it' and doing well.  At this moment I felt good that I had found my next minion not to mention a handsome referral bonus.

Matt and another developer named Ray joined us right after the time that I was created our Setup Democratization road map and sold it to executive leadership.  The three of us formed a small development team and started working on an internal tool code named `WiXShield`.  This tool would later be renamed `IsWiX` and released to the community as open source.

Matt did a great job working on this project and over time learned all of our patterns so that he could back me up in case I ever got hit by a bus.  That day came about a year later when I was pulled off the team to do a 3 month stint as a developer on one of our products.  Normally I would have given some notice that I was leaving the team except that the cat got our of the bag early.  I remember pulling Matt into a conference room and telling him that effective immediately he was the new team lead.   To say he was shocked would be an understatement.

Well he did just fine so when I returned to the team three months later I decided to have him remain as the team lead and I took on an unofficial elder statesman role.  The inside joke around the office is that I've done too good of a job indoctrinating him with my world view.  It's amazing how eye to eye we see things.

Anyways to get to the point, you can't (and you shouldn't) keep a guy like that forever.  He's found a new place for himself over at Charles Schwabb and while I'm really going to miss him,  I'm wishing him well.

Matt-  I wish you well and here's to seeing you again one day soon. Perhaps this time you'll get the referral bonus.



From Left to Right: Matthew Tan, Ray Dise and Christopher Painter
 celebrate the release of IsWiX (May 2010)



Lack of IIS Support in IS Automation Interface

In a previous blog entry I talked about how a couple of InstallScript UAC bugs went uncorrected for several years.  "Anonymous" left a comment saying "it wasn't a big deal".

So today I'd like to leave a little bread crumb for something that IS a really BIG deal.

InstallShield markets itself as having an Automation Interface and not just a big fat IDE.  That is correct and I make extensive use of it in my blending WiX with InstallShield designs.

InstallShield markets itself as having Native IIS 7 support.  That is correct and it's one of the big reasons I continue to use InstallShield.  WiX 3.5 is supposed to be up to that level but for now I've stuck with IS.

However, recently I discovered that InstallShield's automation interface has 0% coverage of the IIS functionality.  That is a huge omission as IIS changes represents a major component of the InstallShield tool.  

Now I wasn't in any of the meetings but it doesn't take a rocket scientist to figure out what probably happened.     Marketing and Engineering probably realized the need for a revamped IIS subsystem to deal with the latest versions of Windows / IIS.   They probably scoped it out and somewhere along the lines decided to drop automation support from the roadmap so they could keep their ship date and announce a new feature.

So there you go, sure they have automation and sure they have IIS but they don't have automation for IIS which in my book means they don't really have automation.  It simply is not feature complete.   This isn't the first, second or third time I noticed glaring holes in the automation interface but it's the most significant IMO.  I can kind of ( not really ) understand a property here or there missing but for an entirely new/rewritten feature to be omitted tells me that the automation interface isn't really a priority and that it's a false feature.   That it's only there for marketing purposes so that InstallTalk can blog it's usefulness.

Sure, I can "hack" around this problem as has been suggested to me  but I don't considering saving and closing the project object  then hitting it with a DTF SQL Query or  XML DOM to be "automation".  This is raw data layer access.

No doubt some at InstallShield will read this and say "he's spot on" and some will read this and say "oh Chris is off his rocker again... this is really no big deal.". 

So let's see how many years it takes for InstallShield to fix this one.