ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

September 20, 2011

Changing Domains

The Deployment Engineering blog has moved to http://blog.iswix.com. All 351 previous articles from 2003 - 2011 will remain at this URL to make sure the content can be linked to from all over the web.

Christopher Painter's email address is also changing to chrpai@iswix.com.

Sincerely,

Christopher Painter
ISWIX, LLC.

August 30, 2011

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.

August 10, 2011

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.

June 18, 2011

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)


April 08, 2011

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. 

April 06, 2011

Interesting Thoughts for Today

I just came across two interesting blog posts today that I thought I would share.  The first is from The Agile Warrior:

Wherever you are working, pretend you are going to be there for ever.


This is especially important if you are a contractor.


When you act like you are going to be somewhere forever (and that it’s YOU who is going to be maintaining this software) you behave differently.

You start to write more tests.
You don’t mind creating the occasional support document.
You clean up as you go.
And you are less likely to sweep things under the rug.
You are nicer to people (you are going to be here forever after all).
And you start to care.

Making this attitude a habit isn’t just good for the soul. It’s good for the bottom line.
Contractors who don’t care don’t get asked back.
And nowhere is the world more small than your local IT community.

So start caring. Pretend you are going to be there forever and you’ll naturally act accordingly.
The second is from Joe Homs

What works equally well is to pretend you are leaving tomorrow. It’s a great exercise if you really do think you’ll be at your company for a long time and will have to maintain the software you create. If you’re leaving tomorrow, what would you fix, document, clean up, or write tests for? Who would you be nice to? We used to call this the “Hit by a bus” effect, but some people liked to use “the lottery winner” effect as the name. It really helped people get that they had to maintain their systems better and not become bottlenecks and share information.

Joe then goes on to quote Carl Gustav Jacob Jacobi  with:

“Invert, always invert.”  - Carl Gustav Jacob Jacobi 
Continuing, Joe says:

If you haven’t heard of Jacobi, you should check him out. Anyway, basically, all you have to do is think of the opposite of whatever position you are in. Have lots of time? Now pretend you have little. Have lots of people? What if you only had a few? Have only a little money? What if you had a lot? Stretching the constraints in your projects can really help you see new solutions. It’s helped me solve problems countless times for myself and my clients.


Fascinating thoughts if you ask me.

April 04, 2011

InstallShield Bug Backlog

I was reading through the InstallShield 2011 release notes from August 2010 when I noticed the following:

InstallScript Functions ServiceExistsService and ServiceGetServiceState No Longer Require Elevated Privileges

The InstallScript functions ServiceExistsService and ServiceGetServiceState no longer require elevated privileges. Therefore, installations can now call these functions when end users have limited privileges, such as in the Install UI sequence of a Basic MSI installation. This enhancement resolves issue IOC-000059857.

I then remebered blogging about that problem back in May of 2007. ( See: Vista UAC implications of ServiceControlManager API calls )

As I recall, this fix couldn't have been more then one or two lines of code.  Basically you just had to open the SCM API requesting less privs when you were only checking the status of a service.  I remember this because I had posted a workaround on the forums myself.

This bug was found in IS12. 

Was it fixed in IS2008?  Nope.
Was it fixed in IS2009?  Nope.
Was it fixed in IS2010?  Nope.

It was finally fixed in IS2011 which was released in August of 2010.  That's 39 months to fix a simple defect.  Surely all of those maintenance dollars from support contracts could have sped that up a tad.  Instead InstallShield continues to live up to their reputation of shipping new features but not fixing existing issues.

I'm going to be keeping that fact in my mind when I think about how long it takes WiX to ship a new release and how InstallShield now loves to throw the "Agile" word around in their marketing.