The root issue is that the Windows Installer does not save Property values for you. That means if the user enters values in the install UI or passes them on the command-line, those values will be not be present during repair, upgrade nor uninstall. That last one, uninstall, catches people all the time. So let's solve the problem simply then solve it completely.
I was poking through my email this morning while waiting for a couple long running processes to complete, when an email popped in pointing me to a Stackoverflow question. Typically, I redirect such inquiries to my support page. But it was a slow day at FireGiant Support so I thought I'd take a look.
I was poking around in the Services management console the other day. Every time I do this, I'm reminded that there are a lot of services registered by default on Windows. The descriptions provided for the services in the management console are pretty good but yesterday I found a page in TechNet that provided additional information about many of the default Windows services.
I've been so heads down running FireGiant that my attendance on StackOverflow has decreased signifcantly. However, someone who answers a fair number of MSI related questions on StackOverflow asked me a question to clarify his understanding.
A name, or if you prefer identity, is a profoundly important concept in pretty much everything. In software deployment identities serve as the foundation for versioning and dependencies which are pretty much everything for us. In ancient Egyptian mythology, Isis was granted power over the all powerful sun god, Ra, when he told her his true name.
My interview with Carl Franklin and Richard Campbell at .NET Rocks went up yesterday. Like all interviews or public speaking gigs, I had some butterflies before the show. But when Carl Skype'd me the world just floated away and I on! The whole interview was tons of fun but there were a couple things that I thought went particularly well.
I joined the Developer Division almost 2 years ago. When I announced the move I spoke about my new focus on the short and long term of setup on Windows. In the Windows 8 keynote and the Developer Preview bits available now you can see the results of both. It all starts in the keynote when Antoine Leblond comes on stage and fires up Visual Studio.
There is a property in Add/Remove Programs (called "Programs and Features" in Vista+ but setup developers in the know call it "ARP") that can specify the install location for your application. Like most properties in ARP, it's questionable what value InstallLocation provides. However, it's there and some things look for it and the Windows Installer provides a standard way to set it, so let's talk about how to do so with the WiX Toolset.
If you've dealt with the Windows Installer at all, you know the fastest way to figure out what went wrong is to look at a verbose log file. The normal log file doesn't provide enough information to really diagnose things going wrong, so I always generate a verbose log file.
I am officially launching RobMensching.com LLC today, Labor Day 2009. This new business will begin by offering software installation consulting services for the Windows Installer and WiX toolset. You can read more details about the business on my consulting page.
Last night I was looking around to see how ASP.NET MVC was doing and noticed Phil Haack posted that ASP.NET MVC RC2 was available. I was disappointed that the RC2 was basically all setup work.
This question just floated by and I had a similar question recently so I thought I'd capture it here to point search engines in the right direction.
In my original dissection of Google Chrome's setup I noted that the Google Updater was left running after I uninstalled. After a pretty smooth installation experience, that partial uninstall left a bad impression on me. Well, it turns out that my observation was only half correct.
Last time I took apart the Google Chrome setup experience and came away disappointed that the Google Updater got left behind. This morning the Google Updater had another surprise. Well, it isn't so much a surprise as it is a departure from the norm and I'm curious what you all think about it.
I thought the next installation package I would evaluate from the inside out would be the Windows Live Writer Tech Preview. However, before I got around to that, lots of noise was made about Google Chrome's release so I thought I'd pile on and dig in. As usual, I found a few interesting things.
As I noted a few months ago, the Windows Installer is a declarative installation engine not a procedural installation engine. That means if you are going to extend the installation engine (which is what custom actions essentially do) then you should follow the same principles the engine follows. Namely, your custom action should read data out of a table and act based on those declarative instructions.
The title of this blog entry is a concept that I kept trying to sneak into one of my earlier posts on this "Zen and the Art of Custom Actions" thread. I finally gave up trying to make it a bullet point and now here we are. What convinced me that there was a full topic to be covered was when I realized I meant two things when I said "Custom actions are (generally/typically) an admission of failure."
I've been working my way through the book The Second Coming of Steve Jobs that Peter Torr left behind when he moved out (when I got married). The book is a bit sensationalistic so I'm constantly questioning how much of it is really real but there are parts that I find amusing. This particular passage sticks out in my mind that talks about Steve Jobs's amazing ability to sell.
A while ago, I saw this blog post about creating an uninstall shortcut using the WiX toolset. My first reaction was, "Uhh, I thought the Logo says you're not supposed to create uninstall shortcuts." But as the blog author noted clients are clients (especially if they are paying the bills). My second reaction to the blog entry was, "Jeez, those CustomActions don't seem like they should be necessary."
I was recently pinged by a triumvirate of individuals asking me about using managed code to write CustomActions. This is a hot topic that comes up about every other month on the wix-users mailing list at SourceForge. Those of you that hang out on that mailing list know that I've repeatedly stated that the WiX toolset does not support managed code CustomActions because the Windows Installer team does not support managed code CustomActions.
This is a topic that I planned to cover a long time ago. Later I realized that it takes quite a bit of explanation and code to demonstrate why advertising COM information is such a bad idea. Recently, I've had a number of people all ask about this topic again, so I thought I'd sit down for a few hours and put the example together.
Last one for the night then I'm going to go drop dead in bed for a few hours. Today, I met with David Aiken about the possibility of doing a presentation on the WiX toolset at his Designed for Operations Workshop.
Tonight I was late to the Thursday night WiX Working Group (where a bunch of us get together and slam out some code for WiX) because Zac and I were rolling out the first half of our changes to the live Windows Marketplace site. We split them in two because we start in the early evening and don't want to be up too late. Of course, I'm up all night Thursday anyway... but I was supposed to be writing WiX features.
The Windows Installer team blog has a picture laden blog entry that explains why primary keys in an MSI database must not change from build to build. I suggest taking a read through it because it provides a nice example of why I caution people when they are writing tools to autogenerate WiX source files. Those identifiers are not trivial pieces of data.
We just did the curly-cue take off from San Jose on my way to Seattle by way of Portland (don't ask). The captain just informed us that the second pass over San Jose Airport is used to climb above the incoming traffic to SFO. That makes an amazing amount of sense and provides a nice view of the whole bay area. I just hope I don't miss my connection in Portland.
This little tip for those of you trying to do a small update or minor upgrade has been sitting in my "to blog" box for a long while. If you are developing a small update or minor upgrade for your MSI product, I encourage you to set the MSIENFORCEUPGRADECOMPONENTRULES Property to "1".
I've been working on revamping the Windows Marketplace build system for the last month or so. Just yesterday I had to make the decision how we were going to version our binaries. Versioning is a very important of software engineering and it can be very disruptive if you get it wrong. Getting versioning right is also quite often overlooked so I was pleasantly surprised to see two pages dedicated to the topic in the help for our build system.
I have some philosophies about how to build software and setup for software that I've never posted here. So, I thought I'd share those philosophies today.
Far and away the most popular blog entry I have written to date is the entry where I discussed some of the inner details of the MSI file format. I find this slightly amusing since there is so little actionable information in that blog entry. I consider the blog entries about Windows Installer Components and the Component Rules far more useful to people working with setup.
I was asked a very good questions in a previous blog entry about the yet to be released toolset, "Will the toolset make it possible to get rid of some expensive install tools if I don't need their sophisticated user interfaces but want to automate all?" I thought this was a question lots of people might start asking so here's a response.
I've sat down to write this blog no less than four times in the last week. Each time something has come up that has pulled me away from actually getting far enough into writing that it becomes basically self-propelled. Now tonight, I know there is at least one person out there focused on getting her homework done so I thought I'd buckle down and plow through a bit of writing myself.
I find the list of referrers to my blog fascinating. Today the referrers list contained several hits from people searching for Orca (or more explicitly orca.exe) on Google. I can only figure that Google snagged one of my earliest blog entries with its reference to orca.exe and was sending people there. Since, I've been in something of a storytelling mood the last couple days I thought I'd go back to 1998 and tell the story of Orca.
I actually have the better part of two pages started into another blog entry about Windows Installer Components when I realized that I had never talked about the "Two Axioms of Setup". These two axioms I'm about to present serve as the foundation for everything I do in the setup domain. I'll refer back to one or both of these axioms often.