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
