ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

April 28, 2006

InstallShield 12 Beta2

In previous postings I've rambled on about the search for the Holy Grail of Custom Actions. I do believe that I've found it. Buried in the "what's new" for IS12 (Beta) is this little blurb:

`InstallScript design enhancements`

Ok, I know, you might be saying 'Yuck, InstallScript' or 'Yuck, Script!' But give me a second here to explain. I think you'll like it enough to pass it along to other developers who have lost faith in InstallShield.

The 2 biggest problems with InstallScript have been:

1) The need to bootstrap a scripting runtime. setup.exe != pure .msi
2) The ISScript engine had so many bugs in it that it spawned a support website of its own.

I am pleased to report that both of these problems are HISTORY! InstallScript CustomActions now compile to Type 1 Custom Actions. These means the only real difference between a C++ custom action created in VS6.0 and an InstallScript Custom Action is how much time and effort to took to write it.

Imagine all of the glory of InstallScript.... a Domain Specific C-like scripting language ( I'm not sure why they call it script anymore, it doesn't really have a scripting engine! ) that gives you an integrated IDE, Compiler, Linker, Debugger, a host of functions, simplistic datatypes, and the ability to easily invoke Native Win32API, COM and Managed Code all in one package with easy access to the MSIHANDLE.

A couple versions back InstallScript added the CoCreateDotNet() function. It basically works like this: Your write a class in VB.NET/C# and declarate it with [assembly: ComVisible(true) ]. After building the assembly you simply drop this assembly in your SUPPORTDIR view ( No COM Registration Required! ) And call it from our InstallScript:

export prototype ExampleCA( HWND );

function ExampleCA( handleInstaller )
STRING supportDir;
NUMBER bufferSize;
OBJECT myClass;
begin
MsiGetProperty( handleInstaller, "CustomActionData", supportDir, bufferSize );
set myClass = CoCreateObjectDotNet( supportDir ^ "myassembly.dll", "myNameSpace.myClass" );
myClass.myMethod();
set myClass = NOTHING;

return 0;
end;

More detailed examples can be found here

How easy could that be? No ActiveScript to blow 1720 error messages at you. No C++ to write, no CLR to invoke, no configuration of the system such as COM registration or putting assemblies in the GAC needed to call your managed code.

Now that's what I call Hard Core Setup Engineering.

Congratulations InstallShield. I only hope that Setup Developers will give InstallScript a second chance.

9 comments:

Anonymous said...

I wont believe it until I see it and it wont be until this tuesday. :-)

bob said...

Thanks for the kind words, Chris. Keep the feedback flowing.

Troy Phillips said...

This is very good news for those that manage enterprise deployments of packages - the installshield installscript dependency has been a definate pain to manage (especially since by default it runs custom actions as the interactive user - not usually useful in a locked down environment).

Anonymous said...

I guess this is good if you already have a large investment in InstallScript code.
However InstallScript is very lacking as a language (domain specific or otherwise) and one should seriously consider using a more capable language such as C++,C#, or VB.net for custom actions.

Christopher Painter said...

C++ has a proven track record of custom actions but it takes a heck of a lot more work to get the job done then it does in InstallScript. After all, time IS money.

C#/VB.NET ( Managed Code ) poses a wide variety of problems that have been discussed elsewhere. First is the need to redistribute the Framework ( not all installs are for products that use .Net ) and the second is the only mechanism provided by Microsoft to invoke MC custom actions ( InstallUtil ) only supports out-of-context invocation which means there is no direct access to the MSI handle. Also InstallUtil has a nasty habit of throwing up modal dialogs when a failure occurs. This is certainly not good for unattended silent installs.

In the sample I provided I showed a very easy way to invoke Managed Code from InstallScript to get around these limitations if so desired. On Vagmi's blog he shows a way to do it in C++ and InstallScript is incredibly more simpler. However I would argue that 1) Most CA's shouldn't even be CA's if MSI is implemented correctly and 2) Most CA's can be solved using InstallScript and 3) What remaining CA's that can't be solved using pure InstallScript can be solved using interop to Win32/COM/MC.


I'd also be curious to know where you think InstallScript is lacking? The only thing I complain about now is the lack of a simple vb style collection enumerator. Currently you have to walk the Item() property ( if the collection has one ) or use the solution provided on the InstallScript site.

Anonymous said...

Welcome to the world of no setup engines, InstallShield. InstallAware has been there for over two years now. You say its the holy grail of custom actions. Well, InstallAware makes custom actions obsolete altogether! You get an actually human readable script with no confusing sequences and bizzare timing interactions. Another two years, you'll have figured that out too :)

Christopher Painter said...

Such enthusiasm for InstallAware! Personally I'm not very impressed with `MSICode Scripting. Take this example from the web:

---

Get System Setting Windows 98 into CHECKOS

if Variable not Equals TRUE
MessageBox: $TITLE$ Setup Error, This product cannot be installed
Terminate Installation
end

---

Ok, so I'll admit that making the transition from old-school script based installs to pure Windows Installer relational authoring is challenging at first. But is it really that hard that you have to invent a new script language to describe the functionality of a LaunchCondition and then transform it into MSI data? Is it really that hard to create one Setup Condition / LaunchCondition using the Version9X property?

When InstallAware people compare scripting and custom actions to InstallShield, they really aren't making an accurate comparison. Eitherway I certainly don't see how it's `embracing` WindowsInstaller methodology to hide the underlying table relationships in a custom scripting language.


---

Anonymous said...

WiX is the future of installer technology...

InstallShield, Wise, and the others are becoming deprecated.

Anonymous said...

IMHO XML should be used to describe data, not functional action.