WiX-Users: Exceeding Version Limits

Sohail Somani recently asked on the WiX-Users List:

I'm currently in the middle (or nearing the end, I hope) of porting an installer from the evil that shall not be named to WiX.


Mostly, it's been pretty easy. However, one thing which is sticking out is the version number. The products being ported use the current year as the major version number and this means strings like "2011.foo.bar".


...Is there a  simpler way to exceed the limits...? 

The tool ( let me guess: InstallShield ) Sohail used to use isn't the evil, it's how it was used that is incorrect. Over my many years of writing installs I've seen this situation happen over and over:

(I'll use one real world example to illustrate how absurd this really can get when you let functionals try to drive the decision without consulting technical resources. Seriously.... don't ask )

Release Manager:  I need the product version to be  DMLSS_V3.00.01.A.01.10
Setup Developer: I am sorry, I can only do x.x.x.x with certain upper and lower bounds for each field.
Release Manager:  That's crazy, the install shouldn't dictate what I choose.  You must make it what I say.

However, certain the release manager is about how things must be done to meet his 'special' business needs ( aren't they always? ), the MSI SDK is quite clear on the definition of the ProductVersion property:

The format of the string is as follows:

major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.

The old tool allowed this violation ( usually without much real life harm, perhaps some problems doing Major Upgrades ) but WiX simply doesn't allow it.  I think that's a good thing because it helps the install developer when he needs to tell management:

Setup Developer: I'm sorry, I can display your custom version scheme on the dialog but I cannot possibly assign it to the ProductVersion.

Instead it looks like Sohail is just looking for a way around MSI to make the release manager happy.  I understand that pressure but personally I never tolerate it.  I suppose that's partly why I change jobs so often.    Still, it can get better as evidenced by the fact that I've been at my current employer for nearly two years now when the last time I worked for them I barely made it past a year.    Push back hard enough and provide sound reasoning and eventually it will improve.

IsWiX Stretch Goals

Wilbert van Dolleweerd left a comment on the blog entry IsWiX - Three Great Tastes asking:

We are in the process of migrating away from Installshield to Wix. It is a good tool if you don't mind a bit of commandline work (for the record: I'm a VIM user ;-) 
Would love to see your ideas for IsWix and how you're willing to enhance it. I might even consider contributing to it.

IsWiX is already a very usable tool at my day job as it was designed for our specific needs.  However,  I'd love to grow it into general purpose tool.  With that in mind, here is a short list of stretch goals I have for IsWiX.  I am also very open minded to feedback to see where people would like to see this project go.



User Documentation

I had written a user manual for IsWiX but it used a company confidential template so I left it behind.

Presentation

I'd like to develop a one hour overview of Windows Installer / WiX technologies targeted at traditional developers for use at CodeCamp and DotNet User Group type events. I am somewhat concerned that there might not be much interest in this from developers.

Robust Automation Interface

SDK Documentation and Visual Studio Project Templates to help people write designers and domain objects for Fireworks / IsWiX.

Support for Sharp Develop

Matt Ward was very helpful in coaching me in the use of their XmlEditor control and I know they are WiX fans so I'd like to try to give something back.   Combining SharpDevelop, WiX and IsWiX seems like a no brainer for small companies and developing markets who can't afford Visual Studio / InstallShield.

Improvements to the XML Editor

IsWiX is meant to be used with Votive which already has a decent XML editor.  The XML editor in IsWiX was initially implemented primarily as a  way to preview the changes to the in memory document but it would be nice to mature it to a point of being similar in capabilities of Visual Studio but a lot lighter weight.

VIM Text Editor
OK, this is somewhat a gag feature ( but I'm actually serious here ) but it would be interesting to somehow host VIM in a Winforms control.  Imagine switching from designer mode to editor mode and using all the VIM tricks you are used to and then switching back to designer mode.
Refactor Files and Folders

I need to clean this up to use proper domain objects and allow it to exist in Product's, Fragments or Modules.  It currently only supports Modules since that was the easiest path to supporting our use case.

COM Extraction

Add the ability for the Files and Folders designer to interact with Heat to perform COM harvesting and authoring.  Currently I use a utility that serves as a front end to heat to author the COM snippets and then manually integrate them using the text editor.

Additional Designers

Finish work on Custom Tables Schema Editor and implement Services, Registry and ShortCuts Designers

IsWiX - Three Great Tastes

WiX vs InstallShield has long been a Red vs Blue debate. Some people believe that setup source is code and should be edited as such while others are in the camp that it's just a document that should have visual designers to automate the workflow.  Finally there are others who need to also be able to programatically update source files from time to time.
Each of these approaches have pros and cons so with IsWiX I decided to support them all.    After all what's garbage to one developer might be a treasure to another. Let's look at these three great tastes:

Graphical Designers

Many of us live in the land of  Windows and use tools like Visual Studio. We like to be able to point, click, drag and drop and cleanly visualize the results of our labor.  Drag a tree of files from the Source view to the Destination view and let someone else do the work of writing the XML for us.  As they say in Jamaica- No Problem Mon!   You can create really nice UI's with rich client side validation such  a constraint for Module@Platform that provides a list list of  types or maybe preventing a user from adding the same file twice.  Properly designed UI's and Domain Objects can generate code as clean as hand written code only you didn't have to spend all day slaving over the computer to write it.  Detractors will claim that it's a crutch that prevents you from learning what is really happening behind the scenes but the same argument could be made of copy and paste and assuming all is well when it seemed to work.  At the end of the day it's up to the developer to turn on the curiosity gene and really understand the entire technology stack.

Text Editors

Some developers just hate reaching for the mouse.  Give them a command line interface and VI and that's all they need or want.  Interestingly, many of these people work on Windows and DevDiv / Visual Studio @ Microsoft and that in itself is a life mystery that I will never quiet grok.  Personally I think it's some form of super-geek 'I'm smarter then you.' cult philosophy but that's just a theory with no hard evidence. While I'm no stranger to the command line, ( My resume includes CPM, AmigaDOS, MS-DOS and various flavors of Unix ) I just don't enjoy typing large amounts of XML. Still, it's nice to be able to look behind the scenes and read what the visual designer actually did.  It's nice to get the XSD validation ( although not as protecting as client side validation ) and it's nice to be able to make hand tweaks to generated code.  After all, there's always an edge case out there and graphical designers and code generators should never stand in your way of getting the job done.  At the end of the day, you are smarter then the computer.

Automation Interfaces

Finally, there are times ( for whatever reason ) when you just need to be able to inject a little magic into the process.  You shouldn't have to use raw XML DOM's to manipulate the source nor should can you possibly use a graphical designer.  Therefore, anything a graphical designer can do must also be possible programtically through an automation interface.   Additionally, a well thought out automation interface can help create an ecosystem of tools that are currently unimagined.

Summary and Invitation

So that basically sums up the three great tastes of IsWiX.  In thinking this over, it's now clear to me that a best in breed solution should borrow ideas from both WiX ( XSD is wonderful ) and InstallShield ( Designers and Automation Interfaces Rock ).   InstallShield is a wonderful product but I have several major concerns:

1) InstallShield's use of DTD in it's project format is dead to me.  It's barely readable/editable and is a nightmare once you get into branching and merging situations.

2) InstallShield needs to be rewritten.  I can only imagine the hell it must be maintaining 10+ year old C++ code.  It's time for a reboot.  Just as InstallShield embraced Windows Installer over a decade ago, it's time for them to embrace the .NET framework and some form of XSD based document format.  I vote for WiX.

3) In the area of Agile Software Development, InstallShield's build automation story is really good but it falls really short in the area of Distributed Development.  The Collaboration piece simply isn't powerful enough and the pricing model and learning curve of the main IDE just doesn't make it a good tool choice.
3) InstallShield's Automation Interface is lacking in terms of API coverage.  You have to resort to raw manipulation of the underlying tables every time you hit a wall. Additionally using it from .NET is a horrible excercise in COM Interop with no factory pattern or interfaces to allow you to easily switch your code from one version of the API to another.  This beast was made for VBScript ( see #2 ).

4) I was reading about Paternerships vs Dependencies the other day and it made me realize: When pay up to $9500 per seat for InstallShield with maintenance and then do the activation dance, you are dealing with the latter.  You are at their mercy to even use the software with no promises that they will actually fix their bugs or release features that are important to you.   That's probably fine for a lot of shops but I've been increasingly concerned by it.  That's saying a lot since I used to think of this as a parnoia argument.

WiX on the other hand has some clear technology advantages but continues to suffer from severe underfunding and narrow user stories.  I'm convinced they are some very smart people and that most of choices that they have made that I've disagreed with in the past are really just a result of the realities of the available resources.

It's with this in mind that I've decided to set out on creating IsWiX.

I'm throwing the gauntlet down: 

Who will help me?

PS-  IsWiX is intentionally released under the MS-PL license to enable anyone to take the ball and run with it.  I'm under no illusions of grandeur or wealth - I just hope that my little contribution can somehow spark thought and improve this little domain we call deployment engineering / setup authoring.  Regardless of what happens,  it's been a wonderful opportunity to develop my .NET skills while working in a domain that made sense to me.  No doubt this will help prepare me for the inevitable day that I retire from writing installs.

InstallShield Stand Alone Build Error -1131

I was just reading this InstallShield KB article and it really makes me scratch my head.   Basically what it is saying is that the SAB has a dependency on the MS C++ 2005 SP1 Redist but that the SAB installer doesn't actually install it and hence an installer failure becomes a runtime/  failure.

Are you serious?  InstallShield has the best setup bootstrapper / chainer on the market.   Did no one notice they needed to add a C++ redist prereq?   Did they know but just not want to add the 2.3MB to the package?  Did they not know to use an AppSearch/LaunchCondition to gate the install?

But the part that really gets me is:

This unlikely situation is apt to appear on clean Windows/XP or Windows 2003 Server images.

Isn't the point of the SAB to enable *CLEAN* build machines?  If customers are following proper CM practices there should be alot of people with build machines that don't resemble the magical build machine antipattern.  I run my build machines lean and mean and I just looked - no C++ runtime on them.   No Visual Studio either.

Researcher: Code-execution bug affects 200 Windows apps

I just got back from my annual week at the the beach and came across this news:

About 200 Windows applications are vulnerable to remote code-execution attacks that exploit a bug in the way the programs load binary files for the Microsoft operating system, a security researcher said Thursday.

The critical vulnerability, which has already been patched in Apple's iTunes media player for Windows and VMware Tools, will be especially challenging to fix, because each application will ultimately need to receive its own patch, Mitja Kolesk, CEO of application security consultancy Acros Security, told The Register.

This remind me of problems in the past such as the GDI+ problems from years past and other situations where maybe you deployed a DLL privately, via a Merge Module ( that you must service but who knows if the vendor will provide an update ) or perhaps even a statically linked C++ library that has a problem.

Anyways, does anyone know which library is the problem here? I haven't actually found any public disclosure at this level yet but I'll be sure to update this blog if I do.

InstallShield 2011 Released

I'm on vacation so I only have enough time for a few quick observations.  InstallShield 2011 has been released and I noticed the following in the press release:

InstallShield 2011: Microsoft’s Installation Solution of Choice for Visual Studio 2010 Applications

It’s no surprise that Microsoft recommends their Visual Studio customers standardize on InstallShield 2011.

Hmmm, now I know that InstallShield 2010LE was introduced as a free download, but has anyone ever read or heard Microsoft formally recommend VS customers standardize on InstallShield 2011?  Maybe I'm not hitting the trade show circuit enough but it sure would be a surprise to me since Microsoft is all over the road in terms of their use of build and install/deployment tools.

Assuming it's true, I wonder how the WiX guys must be feeling considering they were dumped from Rosario and now this.

In other news, I see InstallShield has given a little bit of ground in the Stand Alone Build war.   They are once again including 1 license with Professional which pretty much gets us back to where we were with InstallShield 12. It's about time and I can only say that they *FINALLY* heard their customers.  Additionally, they are also now selling the SAB individually for $500 per seat.   Well, I actually hoped it would be free like MSBuild is but this is progress.   Now here's hoping that they haven't gone off the deep end and introduced DRM activation as that would be a huge ( as in Godzilla ) problem where I work.

I didn't participate in the beta nor have I see the detailed release notes yet so I'm pretty much just skimming the high level notes that can be found here.  There's some interesting things in their but not much that jumps out as 'must have's'  for my particular set of needs.  I'll be back in the office soon and I'll be sure to follow up if I find anything more interesting.

WiX Needs an Automation Interface

When I first started writing IsWiX, I intentionally decided to keep it simple and keep the bar low for would be contributors. I decided to expose the in memory document as a raw XDocument to the designer (UI).  This has worked out well but now I'm starting to realize what is really needed.

I've been getting irritated with InstallShield lately because I keep finding gaps in their automation interface.  Now that I'm getting really serious with WiX, I've come to realize that WiX is practically lacking an automation interface. ( The .NET 1.1 CodeDomReader isn't very helpful.) WiX is a pretty decent schema and compiler but the fetish for NotePad++ has left some pretty big holes up the stack.  While I understand my UI designers for WiX aren't for everyone, I'm pretty sure more people would be interested in a decent automation interface.

So I'm going to pause my development on IsWiX until I can come up with a good design that allows me to expose an automation interface for WiX separate from IsWiX and also work with Fireworks through some form of dependency injecting.

I have some technical debt to work off here. I'll get working on the automation interface so that the UI can follow.  Course it would be really cool if the WiX team would write one themselves that way they could influence the authoring decisions made by third party tools.

Using Linq to XML to Clean up ISString Tables

I was recently doing some cleanup work on an install that was getting a little long in the tooth and I noticed that it had a lot of pesky orphaned InstallShield String Table entries. Now if you are like me you always want to clean these up but first you need to be able to answer the question: Is this entry being used?

Fortunately with the help of .NET 3.5, C# and LINQ to XML it's a piece of cake to find out. I was recently able to whip up this small little utility in less time then it'll take me to blog about it.



Basically it's a simple layout of all entries, used entries and orphaned entries. Let's look at how easy .NET makes it to figure out which is which:

   1:  private void Process( string documentPath )

   2:  {

   3:    var document = XDocument.Load(documentPath);

   4:    var entries = from row in document.Descendants("row")

   5:                  where row.Parent.Attribute("name").Value == "ISString"

   6:                  select row.Elements().First().Value;

   7:   

   8:    List<string> stringEntries = entries.ToList();

   9:    document.Descendants("table").Where(w => w.Attribute("name").Value == "ISString").Remove();

  10:    string documentText = document.ToString();

  11:   

  12:    foreach (var entry in stringEntries)

  13:    {

  14:      listBoxAll.Items.Add( entry );

  15:      if( documentText.Contains( entry ))

  16:        listBoxUsed.Items.Add( entry );

  17:      else

  18:        listBoxOrphaned.Items.Add(entry);

  19:    }

  20:  }

The process is fairly straight forward. Load the ISM into the DOM; Query a list of ISString entry names; remove the ISString table from the DOM and then finally iterate through the list of names to see if the document contains a reference. It wouldn't take but a few additional lines of code to let you select the entries to remove and automate the rest.

It takes a little time getting used to LINQ to XML but it really rocks once you get the hang of it.

Note: The above example doesn't take into consideration entries that might be used by InstallScript as I don't use InstallScript anymore.

Retiring from InstallShield Community

Over the last 7 years I've racked up over 4,000 posts on InstallShield Community helping out fellow setup developers. I did it mostly for my own benefit as I operate on the theory that if I help solve other people's problems I am really solving my own future problems. This has proven to be true in my experience as nearly every day I am able to snap solve problems while my peers just stare at me and ask "How in the world did you already know that?"

I also helped out over the years in the hope that I would build a personal brand and profit from it. This approach has worked but I always knew the effect would be marginal because when you help users on InstallShield Community you are helping fellow setup developers who are ( to put it simply ) your competition. At the same time, participation in InstallShield Community is ignored by Microsoft in terms of being recognized as a Windows Installer Expert.

While I won't go into the details, Flexera Software has recently contacted me with instructions to not discuss non-Flexera products in their forums. Well, that's their right to do so. However, as the saying goes: We all have a vote.

I don't blog to promote InstallShield, Microsoft, InstallAware or any other organization. I cover the good, bad and the ugly of all technologies and products interest me. Sometimes people love what I have to say and heap praise upon me and sometimes they don't want to hear what I have to say and instead make personal attacks in an attempt to marginalize my opinion. But in the end, I will always call it the way I see it.

So based on my diverse interests and my insatiable cravings to learn and help others it's time to move on. To put it simply, it's time for a bigger fish bowl.

You'll now find me at StackOverflow.com.

One Piece at a Time

It's a good thing that I don't keep time cards when I work at home because I probably don't want to know how many hours I spent coding this weekend on IsWiX for the latest release. Lately I've been taking Fridays off to work from home ( I really wish I could say it's my 20% time but I guess that's the price I pay to own the copyright! Thanks to my nameless employer who transferred the original IP to me! )

Anyways IsWiX now has an unofficial theme song:

One Piece at a Time by Johnny Cash.

Now I know Mr. Cash might not be your cup of tea so let's mix it up with some lego action.