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

June 24, 2007

MSI 4.5 and the `Better Together` Pattern

I once designed for a previous employer a bootstrapper that supported a very complex and seamless story for chaining together dozens of setup prerequisites in different combination to support dozens of different products. They were a Product Line Development shop ( with a whole lot of custom engineering efforts also ) that aimed to bring different assets together to create new solutions very quickly. My readers who still work at this blog know just how far we took that design.

So with Merge Modules and Concurrent Installs being officially dead and evil, and each new Microsoft product needing to integrate the experience of deploying more and more reusable components, it really comes as no sup rise to me that Microsoft is finally tackling this issue.

In the "Agility Trends in Packaged Software" white paper by Robert Flaming (MSFT Windows Installer Program Manager) one little section caught my interest:

Your tools vendor may be your first choice in your Better Together path and could even be your conduit to spectrum of software providers that want to provide you a Better Together experience on their software.


We are in a bold new world, and there is a lot to digest in the white paper, but I'm already wondering what kind of standards will be established ( ICE's, Logo Certifications ectera ) to help ISV's develop micropackages that can easily be composited into a Better Together solution. I also wonder if tools vendors like InstallShield are really the best candidates to establish these practices as it could cause problems when multiple ISV's try to integrate their packages and find out that they are somehow incompatible due to design reccomendations from their competing tools vendors.

I really don't know how this will go down yet.... there is alot of information that has been shared privatly with tools vendors yet deemed to secretive to share with actual front line setup developers. Maybe 4.5 will have a strong enough contract that this problem is mitigated and maybe it'll be too loosely defined as to have the innovation come from the tools vendors and lead to exactly this contract.

Either way, if you find yourself supporting installation stories like I described, or if you see yourself selling software that might be consumed by ISV's that support this story, you really owe it to yourself to start reading over MSI 4.5.

6 comments:

Erik Garcia said...

Darryl Flaming? Is this some secret codename you have for the guy who identifies himself as 'Robert Flaming'?

Christopher Painter said...

Good catch, sorry about that... Daryl Flaming is a former coworker of mine. The wires must have gotten crossed in my brain. Thanks for catching that.

Anonymous said...

yur brain is always messed up goon

Christopher Painter said...

Here is one of those `uninteresting` comments that I previously mentioned. Normally our friend from gateway1.rsasecurity.com doesn't have clean enough language to publish his comments, but today he somehow managed to come up with enough professionalism to make the grade.

Anonymous said...

Hi; i was wondering where could I read up more on MSM's being deprecated?

Christopher Painter said...

`Deprecated` might be a strong word for MSM's but it's very close and Concurrent Installs are certainly deprecated.

Several conversations come along to form this view:

1) WiX no longer suggests making Merge Modules but to do Fragments instead

2) MSI Tao Rule # 43(http://blogs.msdn.com/windows_installer_team/archive/2006/06/27/648447.aspx) talks about Merge Modules still being good for distributed development ( in your own house ) but to use someone elses merge modules has some really serious servicing implications

3) In a Windows Installer chat session the following statement was made:

"Note that most product groups are being encouraged to deliver redistributable software as an msi package rather than merge modules. MSMs have known issues with regard to servicing - a flaw in a merge module cannot needs to be corrected by each consuming application."

(http://community.installshield.com/showpost.php?p=376833&postcount=6)