Custom Actions

I've been giving thoughts on Custom Actions lately and Nates feedback has prompted me to start publishing them. I'll probably keep updating this entry as my thoughts change.

First of all, I'm sure we all try to avoid custom actions in the first place! It is often best to handle a problem using native MSI standard actions for several reasons which I won't name here. But we all probably also know by now sometimes CA's are needed. So what is my list of requirements when choosing a solution for a CA?

1) Capable: The CA must be able to get the job done. It needs to be able to call Win32 API and COM. Possibly it needs to be able to call .NET services also, although at this point I havn't needed to. Some on the web have argued that alot of the .NET services are just wrappers of existing COM and Win32 interfaces, but I really don't know yet. It also must be able to access the MSI handle for doing things like getting/setting properties and posting messages back to MSI logs and subscribers.

2) Reliable: The implementation needs to have as few points of failure as possible. The less moving parts and dependencies the better.

3) Debugable: When things aren't working you MUST be able to step through line by line and get meaningful data to aid in troubleshooting. You'll pull your hair out if you can't.

4) Ease of Development: This is a subjective requirement. The language used by the CA should be easy to program in. We shouldn't be loads of time developing CAs. This is one reason I love InstallScript over C++. Unfortunatly InstallScript is failing requirement #2 and hence C++ is beggining to trump InstallScript in my mind.

5) Supportable: You won't always be working at Acme Software House. What languages are well understood by your fellow developers who will be stuck with your project when you leave?

6) Compiled: What goes in a CA, stays in a CA! This is important in terms of protecting source. It also aids in requirement #2 since a truely compiled language doesn't require a runtime intepreter.

7) Integrated: Ideally the CA's source would be integrated into the MSI development IDE. This is one thing I really like about InstallScript. It's very easy to author, compile, build and debug the CA from one IDE. Unfortunatly refer to rule #2.


Obviously runtime requirements (gets the job done reliably ) are more important then design time requirements ( easy for the developer) . So where does this leave me? Seriously considering dumping InstallScript and going to a language that can compile to a Native Win32 DLL ( not COM ). Unfortunatly where I work there aren't many C++ programmers and a whole lot of VB programmers. So I'm also considering using the DLL as a wrapper to register and invoke a VB COM object where the real work gets done. But this creates more moving parts and starts to violate rule #2. There are some programs that claim to be able to create true DLL's out of VB6 projects. This also looks very tempting to me. VBAdvance, VBExport and VisualDLL seem promising, but in truth all of this is a hack to get around doing C++ CA's.

My new addition, Emma

Today I have great news! After 9 long months, Baby Girl 2.0 RTM ( code named Emma ) was released at 9:48AM on 3/23/2005. This release includes 21" of 7lb 3oz of joy!


Emma and Daddy

Edit Jan 18, 2007: A couple years have gone by and here Emma is with her big sister Ashley. They sure do grow quickly! :)

In search of perfection

As I sit here I'm watching an SMS 2003 push of an application to 1306 machines. 25 clients never evaluated policy leaving 1281 machines that did.Out of the 1281, 1206 have finished and 26 have failed with error 1603.That leaves me with a push that is 93% successful. If weed out SMS problems and focus on only the ones that ran I'm looking at a success rate of 98% with a 2% error rate of 1603.So is the glass half empty or half full? What kinds of error rates do you guys see? I'd really like to be able to crank up my reliabilty a notch or two because it costs alot of labor to have to track down these machines either physically or remotely and perform a manual installation.

My problems seem to be centering around corrupted MSI runtimes that setup.exe isn't smart enough to fix on startup and DCOM problems starting the ISScript engine. I used to have lots and lots of problems with ISScript until I started tweaking the redist MSI to set both DCOM instances to Launching User instead of Interactive User. That seems to have solved the problem for most of my clients yet a few return. I'm starting to agree more and more with some other leading setup developers that I need to dump the InstallScript and move toward C++ DLL custom actions. Also if I replace setup.exe with my own bootstrap EXE then I can probably cut down on almost all of my errors and get near 100%! Now that would be hard core setup engineering.

What does the future hold?

SKD over on the Wixs-Dev list recently asked a question of how long WiX will be around.
Anytime you include third party technology into a solution you have the issue of what is the expected life cycle of that technology. That technology could be an O/S, a language, an SDK or an application. So without getting caught up into open src / closed src there is the question of how long with WiX and MSI be supported. Robmen had a blog entry where he notes how long microsoft supports products once they are released and it's conclusion to me is that MSI will be around for a very long time. After all you have tons of applications dependant on it for setup. Now the better question to me is why release WiX now? Darwin has been out in the wild for close to 6 years now and Microsoft had until now stayed out of the setup tool game and played in the setup sdk game only. On one hand the fact that Microsoft is now releasing a setup development tool only reenforces to me how long MSI will be around.&n bsp; But then again I wonder what technologies will come with LongHorn and the DSI inititative that might become more appealing to me rather then investing more time in MSI/WiX. Sometimes I really wish there were more hours in the day for me to do more research in this area.