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 didn't plan to start my discussion about the new installation technology in Windows 8, AppX, with this topic. However, a quick scan through this morning's email from wix-users prompted me to start here.
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.
Two weekends ago, Windows 7 beta builds were made available. That meant the new MSI SDK was available on MSDN with all the information about what's new in MSI 5.0.aspx). In turn, that meant we had some work to do to teach the WiX toolset some new tricks.
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.
Last night I noticed this blog entry about the lack of Windows Installer Training courses.
Some of you may be wondering why I went MIA for for about 8 weeks. Obviously, I got busy. There were two forces sucking up all my time over the last couple months.
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.
If you follow the world of the Windows Installer at all, I'm sure you have noticed that the Windows Installer 4.5 Beta was made available last week.
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."
Continuing the Zen and the Art of Custom Actions thread, I thought I'd post a mostly formed thought. When I'm presented with the need to write a custom action I often mentally classify the work into one of three or so different buckets.
David Aiken has an interesting blog post about adopting TDD (Test Driven Development, for those of you have been living in a cave) for his next project. In said blog post, David suggests that before even writing tests that one should write the setup logic.
I have been asked a great many times to talk about how to create Windows Installer custom actions. Each time I've dismissed the request noting that it would take tons of time to organize my thoughts on the topic and actually write them all down.
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.
In the last week there were three RSS feeds I follow that mentioned the new Restart Manager service in Windows Vista.
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've been debating with myself for the last week whether I really wanted to write this blog entry about the Component Rules.aspx). The Windows Installer SDK.aspx) has some decent documentation.aspx) about what can go wrong when the rules are broken.
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.
To understand why Merge Modules were created you need to know about the Component Rules. To understand the Component Rules, I probably need to explain what Components are with respect to the Windows Installer.
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.
Setup is, in its simplest form, the process of getting the resources (such as files and registry keys) that make up a software program transferred from a source (such as a CD or web server) and configured on a target machine.
What does one say when one shows up late to a party where everyone else seems to be happily chatting away at each other? Hello? How are you doing? This is quite a nice rug don't you think? Something of a medium shag, I do believe.