Tuesday, September 27, 2005
Visual Studio 2003 doest sucketh
What the hell were the guys at Microsoft on when they build the Setup and Deployment Project code for VS2003? To say that is sucks would be some of the biggest understatement ever. All I wanted was for my application to delete some intermediate files when it uninstalls. You'd expect to be able to do that from the File System settings of the install project, but you'd be dead wrong; of course, the next logical step is to interject a script of some sort into the uninstall chain. Simple enough.

I wrote a 7-line batch script to do the work for me (batch files are crappy scripting tools, but you'd be surprised what you can do with them with enough patience) only to find out that, well, you can't add bloody batch files as custom actions; you can only add DLLs, EXEs and VBScript/JScript files. So I spent an hour teaching myself the basics of VBScript (I already have a solid handle of VB6, just needed a look at the WSH reference and some turorials about FileSystemObject) and moved on.

Only to find out that the script doesn't work; it's run from a god-knows-which working directory, meaning you have to do some extra fussing around to get to the right directory. After a little reading I found the Session.TargetPath property, which apparently doesn't do the trick. To make a long story short, I found a tutorial on The Code Project which showed me how to do it:

  • Add [TARGETDIR] to the CustomActionData property of your custom action
  • The property is accessible with Session.Property( "CustomActionData" )

Why the hell is the simplest thing with MSI so goddamn convoluted?

Development
Tuesday, September 27, 2005 11:54:27 AM (Jerusalem Standard Time, UTC+02:00)  #    Comments [5]  |  Related posts:
Java "qualified this" with generic enclosing types
Scripting Lucene with Python
Java language caveat: autoboxing and generics
Improve Your Life With ReSharper
Lightweight web server for testing purposes
Beginner's Guide to Web Development (or, Getting Eclipse, WTP, Tomcat and Maven to play along)
Wednesday, September 28, 2005 2:56:21 AM (Jerusalem Standard Time, UTC+02:00)
1. Scripting in MSI is deemed harmful. If you did scripting, you should've picked JScript since it sucks less, but ultimately the Windows Installer team discourages you from scripting.
2. Have you looked into WiX? After using all kinds of setup-creating software, I'm definite that on the Windows platform I'll be using Windows Installer, created using WiX. I've used:
- Nullsoft Installer
Pros: free software
Cons: self-extracting Zip on steroids -- a *weird* scripting language creating procedural installers
- InstallShield
Pros: easy to use, hack up stuff fast
Cons: stores your project in a proprietary format; it crashes and you cannot figure out heads and tails, it encourages procedural installers with a proprietary InstallScript language; it encourages non-standard MSIs

WiX is free software (pretty much all C# -- though Windows Installer is still not free software so you might have some cans of worms there), represents the Windows Installer concepts pretty faithfully in its XML schema, has human-readable and editable projects (XML files)... does very little non-straightforward things.
It doesn't sport any GUI (like you come to expect from InstallShield and likes) but if you install its' XSD schema into VS2003's schemas directory, you can pretty comfortably edit it (Intellisense and all...).

I suggest you check within WiX' help files whether there's such an action already -- perhaps there's a simple FileRemove component, or a FileRemove Custom Action.
Ilya
Thursday, September 29, 2005 8:41:12 AM (Jerusalem Standard Time, UTC+02:00)
There are several reasons we've used VS2003's setup projects: primarily, it's easy to learn, free of charge and I've used it before. The project in question has very simple deployment requirements so it seemed like 'the right thing to do'.

As for scripting being discouraged, since this is an installer, or rather an application being run by a user, as long as the script is being run with the user's privileges I don't any reason why it shouldn't be used to its fullest extent. A lot of things simply cannot be done without scripting, at least not comfortably so.

I'll have a look at WiX though, seems interesting.
Tomer Gabel | tomerAT NOSPAMtomergabel dot com
Thursday, September 29, 2005 12:54:22 PM (Jerusalem Standard Time, UTC+02:00)
Actually, the scripts in CustomActions are run with the privileges of whoever is set to execute the msiexec service. But that's not the point. That's the point:
http://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx

Of course, scripts make your installer procedural whereas the rest of Windows Installer is declarative tables, so that's another reason to avoid them wherever possible.

Then again, sometimes there's no better way. Just like they discourage nested installations while sometimes there's simply no better way.

Another thing for WiX: While it's free software, it's Microsoft-subsidized and written by Microsoft employees who have close access to the Windows Installer team (or are *in* the team? Not sure). It's used across Microsoft, for Office, SQL Server, MSN Desktop Search -- see http://msdn.microsoft.com/chats/transcripts/windows/windows_110904a.aspx .
Ilya
Sunday, October 16, 2005 10:37:22 PM (Jerusalem Standard Time, UTC+02:00)
Here are a few random attempts at answers

1. Ilya, thank you for such positive comments on the WiX toolset (http://wix.sourceforge.net). We have worked hard to have a very clean interface on top of the Windows Installer (which can sometimes be a beast).

2. Tomer, as Ilya notes, scripts make an installation procedural. The problem with procedural is that you (without a lot of work) lose the compensating transaction the Windows Installer engine provides. Thus, if your user hits cancel or something goes wrong during the install the machine could end up in a dirty/bad state.

3. Ilya, CustomActions (a batch file script in this case) can execute in either system or user context. The CustomAction/@Impersonate attribute controls this in WiX.

4. Ilya, Only Robert Flaming (http://blogs.msdn.com/rflaming) who works on the WiX decompiler actually works on the Windows Installer team (as a PM). The rest of the people all have worked on actual setup teams for groups like Office and Windows.

5. Finally, "subsidized* is an interesting word. The WiX toolset is a community project. The code is available under Open Source and there are many people on the mailling lists to answer questions and help out.

We have fun with it. Hopefully, it is useful for you too.
Rob Mensching | robmenAT NOSPAMmicrosoft dot com
Monday, October 17, 2005 1:28:31 AM (Jerusalem Standard Time, UTC+02:00)
Hey Rob, thanks for the thorough response (out of curiousity, how'd you come by this post in the first place?)

I like the concept of declerative programming in general as it can save a lot of time and effort, particularly for an installer. I do not have much experience coding installers of any sort really, so I can't say how powerful Windows Installer (regardless of front-end) is; I have found VS2003's built-in setup projects to be horribly limiting to the point where you can't do squat without external scripts. I'm definitely giving WiX a try for my future projects (possibly even for phase II of this particular project, but that remains to be seen), so you'll probably be hearing my feedback one way or another :-)
Tomer Gabel | tomergAT NOSPAMbigmail dot co dot il
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Live Comment Preview