1

I have an ISAPI DLL, an add-on to IIS. I build the installer for it using WIX 3.0.

In the installer project, I have a number of custom actions implemented in Javascript. One of them, run at the initiation of the install, stops any IIS websites that are running. Another starts the IIS websites at the end of the install. This stuff works, the CA's get invoked at the right times and under the right conditions. but the logic is naive. It stops all websites in the beginning (even if they are already stopped) and starts all websites at the end (even if they were previously stopped). This is obviously wrong.

What I'd like to do is keep track in the session of which websites required a stop at the beginning, and then, at the end, only try to restart those websites. Getting the state of a website is easy using the ServerState property on the CIM object. The question I have is, how should I store this information in the MSI session?

It's easy to stuff a single piece of information into a session Property, but what's the best way to store a set of N pieces of information, one for each website? In some cases there can be 1 website, in some cases, 51 websites.

I suppose I could use each distinct website name to create a distinct property name. Just not sure that is the best, most-efficient, most efficacious way to do things. Also, is it legal to use slashes in the name of an MSI Session property? (the website names will have slashes in them)

Suggestions?

Cheeso
  • 189,189
  • 101
  • 473
  • 713

2 Answers2

0

You might want to check out:

VBScript (and Jscript) MSI CustomActions suck

C++ or C# is a much better choice. If your application already has dependencies on the framework then adding dependencies in your installer is a good logical choice. WiX has Deployment Tools Foundation ( DTF ) that has a custom action pattern that feels a lot jscript. You could then create a dictionary of websites and their run state and serialize it out to a single property. On the back side you could reconsitute that collection and then act upon it.

Not to mention the debugging story is MUCH better in DTF.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • I have checked out that article, and I don't agree. http://stackoverflow.com/questions/471424/wix-tricks-and-tips/1801532#1801532. C# is a bad choice for me because I cannot rely on .NET being available. I'm going to take part of your suggestion - I'll use the javascript join/split functions and put all necessary information into a single property. I'll see how it goes. – Cheeso Jan 10 '11 at 20:34
  • 1
    Well, Rob does know what he's talking about. Personally I have witnessed script custom actions fail and will never do it again. – Christopher Painter Jan 10 '11 at 20:43
  • 1
    I agree, I never use anything but C++ for custom actions and avoid them entirely if possible. – saschabeaumont Jan 10 '11 at 21:42
  • Yeah, and I tend to use C# a lot because my environment allows it. I understanding disagreeing with Rob ( Who me? hehe ) but on this point I concede that his opinion is 100% spot on and in line with every Windows Installer expert that I know. – Christopher Painter Jan 11 '11 at 00:13
0

There's a simple solution. I was having a brain cramp.

All of the items I needed to store were strings - actually the names of websites that had been stopped during the installation. I just used the Javascript String.join method to create a single string, and the stuffed that into the session variable. Like this: 

Session.Property("CA_STOPPEDSITES") = sitesThatWereStopped.join(",");

Then to retrieve that information later in another custom action, I do 

var stoppedSites = Session.Property("CA_STOPPEDSITES");
if (stoppedSites != null) {
    var sitesToStart = stoppedSites.split(",");
    ....

Simple, easy.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
  • Downvoting because you are using the property "CA_STOPPEDSITES" when you retrieve the data. This tells me your custom action isn't running in Deferred Execution which violates Windows Installer best practices. You really should read about custom action scheduling considerations. – Christopher Painter Feb 04 '11 at 00:58
  • 2
    Thanks for the link. Whoops! No link! – Cheeso Feb 04 '11 at 14:54