Windows Installer Team Blog

PingBack from http://www.vevz.com/integration-hurdles-for-exe-custom-actions

The above is very useful and I have linked to it from my documentation but I find it amusing that this page (titled "Specifying the Order of Self Registration") exists in the SDK to tell use to use an EXE CA:

http://msdn2.microsoft.com/en-us/library/aa372020.aspx

And msiexec.exe is particularly bad in any case as it doesn't return a non-zero return code on error (so success can't be determined)...

Robert Flaming has posted a helpful analysis of the issues that need to be considered when using EXEs

<rant>

Well...since we are on the topic of custom actions, how about adding support for managed code custom actions?  I know all the arguments for and against, so spare me the monotony, but this has to be one of the top requested features.  I'd be pleased as pie with real ACL support as well.  The LockPermissions table is laughable at best.

Remember when script installers became archaic and legacy?  What do you think is happening to Windows Installer?  Go ahead and drop ClickOnce and focus on Windows Installer.  ClickOnce was ill-conceived from the start and from what apparently is the current roadmap will never be a viable replacement for Windows Installer.

</rant>

This analysis was almost funny, probably unintentionally.

I agree with AJ :-) on the managed code and YES why do we still after all these years need to use thirdparty ACL solutions.

Funny thing is - for us that makes the applications that sell MS Windows - the WIX people are doing the best work at the moment. -They- are the ones that make it easier to just 'do things right'.

Windows Installer custom actions that launch executables (base custom action type msidbCustomActionTypeExe

I don't consider Custom Action EXEs Bad or Good, I think one simply needs to weight the benefits with the hurdles, and this blog entry is very helpful in that regards. For teams that are simply trying to "push off work", well... that is not a good enough reason. However, there are some cases where benefits outweigh the hurdles, especially in regards to maintenance and packaging options.

I'll give you an example where I recently use an MSI EXE Custom Action.

Originally, we used a Frontend User Interface Chainer to chain an MSI installer (for an application) with a non-MSI Driver Install. But we wanted to get rid of the chainer as some OEMs didn't want it, they wanted an MSI look and feel. We could rewrite the chainer, or just find a way to add drivers directly to the MSI.

Then I experimented with the DiFxApp MergeModule. This integrated the drivers behavior directly into the MSI. However this proved to have maintenance drawbacks. Basically, our application is not tied tightly to the driver INF packages, and various customers will get different driver packages. When I was using DiFxApp, we would need to rebuild the MSI projects with the different driver combinations. These needed to be re-qualified by QA, even if the binaries inside the package (other then the drivers, of course) didn't change.

So I investigated this Custom Action EXE mechanism, and it seems to work pretty well. Originally I was going to simply use DPInst, but then I created my own Driver Installer that does what DPInst does, plus is “MSI Aware”.

This allows one to mix and match drivers at will with the current MSI, so QA can have a warm fuzzy that the MSI didn't change, and only the driver files did.

We can churn out various variations of the app/drivers for various OEM customers in minutes. Oh, and as another value added feature of this implementation, if an OEM doesn’t want the app, they just get the very same directory with the Drivers files and Custom Action EXE, and use the Custom Action EXE in “standalone” mode to install drivers (akin to DPInst.exe).

And packaging the launching logic into a Reconfigurable MergeModule (where a developer can quickly add the relative path to where the Custom Action EXE is on their media) makes integration with new install projects and builds a snap.

I do agree this doesn't make sense for true application components. I definitely wouldn't want to use an external EXE to install app-settings, such as more files, registry keys, shortcuts, etc. That is what MSI is for! But I consider the whole DiFxApp mechanism as a half-hearted attempt at not providing a true external EXE for DPInst.exe, anyway.

Oh, and I have found ways of linking to the MSI progress bar and status text. It would be awesome for one of the MSI team members, or one of you MSI gurus to give an example of how one can find a handle to the ActiveDatabase from an external EXE, to allow a tighter integration with an external EXE Custom Action. I want to do this in my next respin, so I can add full costing support, and support the cancel (right now I simply disable the cancel button when my Custom EXE runs, enabling Cancel after it finishes). I have some ideas on how to do this already, but it would be nice to hear it from the source, so to speak.

I know why I can't just get the handle directly, because each custom action runs in its own server, and the handle will change or disappear based on the scope of its owner. However, it would be cool if there was a way that allowed an external EXE to get the handle to its own server from some property or something that can be appended to the command line to the EXE when the server launches the EXE (via Type 2 or Type 18, or Type 50), so you don't have to always use a CA Type 1 DLL wrapper function just to do this.

Sometimes I get frustrated, with all the custom action types, why-oh-why does it always eventually return to a Type 1 for everything? It seems whenever I venture to another CA base type, it works for 95% of what I need, but there is always some shortcoming which causes me to go back to good-old Type 1.

I would love to hear how a VS2005 tool vendor should handle having to run devenv.exe /setup without an EXE custom action.

I&#39;d like to add my thoughts to the recent discussion about how bad custom actions are, and which

Hey Robert! Great article! I had to make one quick comment though about, "There is no way to debug custom actions in EXE from MSI". True you cannot use MSIBreak but I used to use several methods to get at EXEs through debugging when I was in PSS. You can attach to the custom action server, if this is not out in the field you could do message boxes, or break before the custom action using another custom action, you could do "Image File Execution Options" on MSIExec.exe. But I agree it is much harder to debug.

Adam, you are so right!  Even WiX.MSI calls devenv /setup to install the Votive project and item templates.

BTW, I'm just now starting down the road of deploying VSTO 3.0 addin's for MS Office 2007.  I want to use MSI not ClickOnce because I'm also deploying a bunch of other stuff.   Anyone want to tell me how to install the .VSTO without using an EXE CA to call VstoInstaller.exe ?