I don't feel so bad about my managed CA when I hear about InstallShield supporting them.
Thanks for the quote, I read and voted. I did have some fat finger and spelling errors. It used to be you could just write managed CA in managed C++ in .NET 1.1. With 2.0, there is the DLL dependency on the C++ runtime. With that we get the C++ harness with the C#/VB.NET dlls to be loaded. I guess one could use managed C++, but they would have to place the CRT manifext in the directory where the custom actions are run (c:\windows\installer or something like that). I guess if people have enough time and money, they can always stick to native C++, but then there is so much code to maintain and test. Regards, Aris ---- Christopher Painter <[EMAIL PROTECTED]> wrote: > InstallShield creates a DLL with a bunch of exported functions like > m1,m2,m3...... Then there is table data that the function queries to know > enough to fire everything up and invoke it. One really cool thing is > dependency rows ( Direct Editor... GUI doesn't expose it yet ) where if > assembly 1 has a dependency on some file/assembly it'll get extracted out and > made available to the process. Very useful.... > > I leaned ANSI C on Solaris back in the 90's and never did a whole lot on > Windows. C++/MFC/ATL is foreign to me. I moved on to RAD languages like > PowerBuilder/Delphi/VB before finally moving to .NET. A lot of people today > have only ever done .NET. It's all great if you happen to be a DirectX/C++ > MS-MVP but for the rest of the world, there is a disconnect. > > BTW, hope you don't mind that I quoted you: > http://blog.deploymentengineering.com/2008/04/you-cant-escape-net.html > > > [EMAIL PROTECTED] wrote: > I am doing something similar, but in Wix. I had to write the > "CoCreateObjectDotNet()" stuff myself. I'll bet the InstallShield created a > more generic, reusable functionality. > > I write my .NET CA's in VB.NET so I can use late binding to do stuff with > ADSI, etc. I don't need interop. > > I think that the issue people are worred about is that with .NET loaded in > the immediate/deferred processes, there may be issues with things like > installing assemblies into the GAC. We don't need to do this with this > install. > > The point is clear in the blog link you sent, there is more familiarity with > .NET than unmanaged C++ for doing something like creating a random number. > > I can do the native C++ coding, but compared to .NET, its like moving a pile > of sand with a small spoon as opposed to a shovel and a wheelbarrow. > > Regards, > Aris Green > > > ---- Christopher Painter wrote: > > > > > > Read this and let me know what you think: > > > > http://blog.deploymentengineering.com/2008/03/installshield-2009-beta-part-ii-managed.html > > > > > > [EMAIL PROTECTED] wrote: > > 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 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. :-) > > > > > > > > > > > > > SourceFile="$(env.FrameworkDir)/$(env.FrameworkVersion)/InstallUtilLib.d > > > ll" />--> > > > > > > > SourceFile="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727/InstallUtilLib > > > .dll" /> > > > > > > > > > > > > > > > > > > > > > > > > [snip] > > > > > > > > > > > > > effect, set required MSI properties (AFAIK required for using > > > InstallUtilLib.dll) --> > > > > > > > DllEntry="CheckFX" /> > > > > > > > DllEntry="ManagedInstall" Execute="deferred" /> > > > > > > > Property="CAInstall.install" Value="/installtype=notransaction > > > /action=install /LogFile= /PS_DEF=[PS_DEF] /PS_ADR="[PS_ADR]" > > > /PS_BYP=[PS_BYP] "[#ClientEXE]" "[VSDFxConfigFile]"" > > > /> > > > > > > > DllEntry="ManagedInstall" Execute="commit" /> > > > > > > > Property="CACommit.commit" Value="/installtype=notransaction > > > /action=commit /LogFile= "[#ClientEXE]" > > > "[VSDFxConfigFile]"" /> > > > > > > > > > > > > [snip] > > > > > > > > > > > > > > > > > > > > > > > > > Before="CAInstall.install">$Executable>2 > > > > > > > Before="CACommit.commit.SetProperty">$Executable>2 > > > > > > > Before="CACommit.commit">$Executable>2 > > > > > > > Before="RegisterUser">$Executable>2 > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > 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 > > > > > > > > --------------------------------- > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > > now. > > > > > --------------------------------- > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. ------------------------------------------------------------------------- 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
