I have head people preach dillegently about the evil of managed custom actions.
Let me just say a few things. Often we need tools such as SMO to better configure a database and the "in-box" custom action in Wix don't do quite what you need. In some of the installs I have worked on, I need to migrate old databases, Restore, Detach, Attach, run very large batch scripts, hook into the batches to echo "Print" SQL statements to the MSI logs. Also, setting up a Web Service in IIS7 is unsupported. In comes .NET in a Custom Action to the rescue. This logic can now be coded in a more affordable way than vast tomes of C++. What I have font to work greatly is to use a Unmanaged C++ harness to load .NET assemblies and run the custom action logic. The C++ harness uses the unmanaged .NET API for setting up the app domain and firing off the .NET code in the assembly. All the .NET code is run as a DLL custom action. NOTE: These are not the "Installer Components" that leave their carcasses in the installed product. They are simple extracted in the install, ran, and then deleted (the DLLs are loaded by the unmanaged C++ in another App Domain so they can be chucked). I realize there may be issues when installing to the GAC on Server 2003, fortunately we don't have to do this. Regards, greenaj ---- Holmgren Mathias <[EMAIL PROTECTED]> wrote: > And BTW, this topic is obviously an old beaten horse... > > http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActio > ns-no-support-on-the-way-and-heres.aspx > > > > /M > > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Holmgren > Mathias > Sent: den 29 april 2008 14:39 > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Managed custom actions in Wix 3 > > > > AFAIK, MSI can not call your managed code directly and there is no > supported way to easily call into custom actions written in managed > code. > > > > But you can use InstallUtilLib.dll from the framework directory to host > an AppDomain and load+call your managed code custom action. I got the > below to work by using dark to reverse engineer what Visual Studio does > with it's own setup projects. > > > > WARNING - As far as I know this is all undocumented and likely very > unsupported stuff. And I might not understand all the implications of > what I did here. > > > > But it works - no C++ or unmanaged code necessary. :-) > > > > <!--<Binary Id="InstallUtil" > SourceFile="$(env.FrameworkDir)/$(env.FrameworkVersion)/InstallUtilLib.d > ll" />--> > > <Binary Id="InstallUtil" > SourceFile="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727/InstallUtilLib > .dll" /> > > <Binary Id="VSDNETCFG" SourceFile="./VSDNETCFG.config" /> > > <Binary Id="MSVBDPCADLL" SourceFile="../../Assemblies/MSVBDPCA.DLL> > > > > [snip] > > > > <!-- DIRCA_CheckFX will check for .NET FW, but also, as a side > effect, set required MSI properties (AFAIK required for using > InstallUtilLib.dll) --> > > <CustomAction Id="DIRCA_CheckFX" BinaryKey="MSVBDPCADLL" > DllEntry="CheckFX" /> > > <CustomAction Id="CAInstall.install" BinaryKey="InstallUtil" > DllEntry="ManagedInstall" Execute="deferred" /> > > <CustomAction Id="CAInstall.install.SetProperty" > Property="CAInstall.install" Value="/installtype=notransaction > /action=install /LogFile= /PS_DEF=[PS_DEF] /PS_ADR="[PS_ADR]" > /PS_BYP=[PS_BYP] "[#ClientEXE]" "[VSDFxConfigFile]"" > /> > > <CustomAction Id="CACommit.commit" BinaryKey="InstallUtil" > DllEntry="ManagedInstall" Execute="commit" /> > > <CustomAction Id="CACommit.commit.SetProperty" > Property="CACommit.commit" Value="/installtype=notransaction > /action=commit /LogFile= "[#ClientEXE]" > "[VSDFxConfigFile]"" /> > > > > [snip] > > > > <InstallExecuteSequence> > > <Custom Action="DIRCA_CheckFX" Sequence="1" /> > > <Custom Action="CAInstall.install.SetProperty" > Before="CAInstall.install">$Executable>2</Custom> > > <Custom Action="CAInstall.install" > Before="CACommit.commit.SetProperty">$Executable>2</Custom> > > <Custom Action="CACommit.commit.SetProperty" > Before="CACommit.commit">$Executable>2</Custom> > > <Custom Action="CACommit.commit" > Before="RegisterUser">$Executable>2</Custom> > > </InstallExecuteSequence> > > > > > > As you can see, you have to explicitly pass in all MSI properties used > by your custom actions for your code to access them. They are not > automatically available. This is an inherit MSI limitation. > > > > The "[#ClientEXE]" param above is a file reference to the > custom action assembly. In our case a <File Id="ClientEXE" ... > > assembly file in one component of the install package. > > > > Note on the dependent files: > > The VSDNETCFG.config is a .net config file (w. lots of assembly > bindingRedirects). You also need MSVBDPCA.DLL. Both these files are > embedded in VS setup project MSI-files as a binary stream. Get them by > darking an existing VS setup project or e-mail me and I'll send the ones > I extracted. > > > > > > PS. If somebody knows a better/recommended way to call managed CAs, > please let me know too. > > > > /Mathias > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
