The good, the bad, and the ugly - custom action types

Internet Explorer Script Error » Blog Archive » The good, the bad, and the ugly - custom action types

Mon, 24 Dec 2007 05:45:03 GMT

Pingback from Internet Explorer Script Error » Blog Archive » The good, the bad, and the ugly - custom action types

re: The good, the bad, and the ugly - custom action types

Christopher Painter — Sun, 25 Nov 2007 03:17:40 GMT

I don't condone using legacy InstallScript functions to intentionally reinvent the wheel instead of using native MSI patterns. I also try to always leverage vendor provided quasi-standard action patterns ( for example InstallShield XML Search/Modify, SQL, IIS and so on).

I also recognize that including an InstallScript CA takes about a 2mb hit on a package ( last time I checked ). That may be an important consideration for very small packages. However for the large packages that I tend to work on, the package bloat is nominal and will never be a real issue.

The reason I like InstallScript is it does have a large repository of built-in functions for dealing with setup related tasks, the MSI API, Win32 API, COM and .NET Interop.

I also believe in writing data driven transactional custom action patterns and all of this built in robustness really helps. I sometimes read newsgroup snippets of equivilant C++ functionality and I really have to laugh at how much simpler InstallScript is. Then again, I also agree with Stefan, that it's probably just a matter of the posters being more comfortable in C++ and I'm more comfortable in InstallScript and C#.

re: The good, the bad, and the ugly - custom action types

Richard — Wed, 21 Nov 2007 23:42:41 GMT

Carl, the main problem I have with VBScript for scripted custom actions (besides what Stefan mentioned about AV software marking it as potentially malicious) is the error handling. Unwinding all the way out of a nested call chain to be able to return the appropriate error code to Windows Installer is tedious (but doable) in VBScript. It requires that you daisy-chain the return value out of every called function that you write. JScript has an exception handling mechanism that allows this to function much cleaner.

One thing that hasn't been mentioned in any of the discussions of custom actions is unit testing. I think unit testing is going to be the best way to test all the nooks and crannies of your custom action, particularly in exercising all the error paths. I'm not sure how you would do that in VBScript; for instance, how do you create a "fake" or "mock" object for vbscript functions that immitates the global Session variable? You could probably do it by passing an object as the first parameter to all of your vbscript code, but its too easy to access Session in the middle and destroy that carefully laid groundwork.

There are mechanisms for doing this with C++ in such a manner that its transparent to you code -- your code never knows if you're talking to the "real" MSI API as in a production environment or if you're talking to a fake MSI API as in a testing environment. I am working on an example in the context of updating the DirectX runtime and plan on publishing a white paper/blog entry on this in the next few months.

With adequate unit testing, I think you can avoid the unexpected pitfalls of custom actions, but that doesn't make them any easier to write properly. It just gives you more chances to find your bugs before your product ships.

re: The good, the bad, and the ugly - custom action types

stefan — Wed, 21 Nov 2007 16:33:27 GMT

carl - yes, the "InstallScript MSI" (or "Standard" as it was called originally) project type has been causing lots of trouble and should be avoided. However Christopher talks about "Basic MSI" projects that may include call custom actions written in InstallScript. This can be useful, if you keep in mind that you shouldn't use it to replace native functionality. But you have to consider the overhead (and potential for bugs in the engine) opposed to a DLL written in C for instance. As I said, it will also depend on your knowledge and experience in other programming languages.

re: The good, the bad, and the ugly - custom action types

carl — Wed, 21 Nov 2007 16:16:54 GMT

I completely agree with what you have said above.

Christopher Painter is wrong. InstallScript MSIs are never appropriate. Leveraging the language into MSIs was dreamed up by InstallShield's marketing team to con people into 'upgrading' to InstallShield 7 saying that "you can upgrade to MSI and your old scripted package will still work"

It had no place in an MSI then, and it has none now.

Personally I like VBScript. It has the advantages of being easy to read, open source and can be debugged from within the MSI using the MSOffice debugger.