PDA

View Full Version : Custom Action DLL



bruno_k
06-19-2006, 12:52 PM
I'm trying to convert a Visual Studio install to IS12. The VS install has a custom action on Install that simply has an Installer class DLL and no condition, customactiondata or entry point. How would a custom action have to be configured in IS12 in order to achieve the same results. Is there a default function found in installer dlls (an entry point must be provided for IS12)

Thanks

bruno_k
06-19-2006, 01:06 PM
I forgot to mention that the dll is a dotNet managed component that extends the System.Configuration.Install.Installer class

public override void Install(IDictionary stateSaver). So if the custom action calls 'Install' will it work?

RobertDickau
06-19-2006, 01:27 PM
Can you use a component's .NET Installer Class setting with your DLL?

Christopher Painter
06-19-2006, 01:29 PM
Author the DLL as a component and make it the keyfile. Then set the component properties:

.Net Scan At Build: Properties Only
.Net Application File: The KeyFile
.Net Installer Class: Yes
.Net Installer Class Arguments: Anything you need to pass in via CustomActionData and make available as a Context Parameter.

BTW, I don't really reccomend that you do any of this. See some reasons why at:

http://geekswithblogs.net/vagmi.mudumbai/archive/2005/03/28/27473.aspx

Instead I reccomend writing your CA's in InstallScript. If you still want to have managed code CA's then I suggest writing your classes to be [Assembly: ComVisible(True) ] and invoking them through InstallScript's CoCreateObjectDotNet() function. See:

http://www.macrovision.com/beta/installshield/v12/

Frankly the Installer class pattern leaves alot to be desired. It was something that was dreamed up by the .Net team and never really implemented correctly with the WindowsInstaller team. ( This is pretty much true for all Installer technologies that came out of the VisualStudio team also. )

bruno_k
06-21-2006, 08:49 AM
Thanks for the replies, I'm going to continue to use the .Net Installer class because it was written by another company and it's working. A problem I'm having with it is that it that the installer's code is calling

Activator.CreateInstance(Type.GetTypeFromProgID("Word.Application"))

in order to add a schema to Word and I think there is a permissions issue

bruno_k
06-21-2006, 10:20 AM
BTW, in case anyone runs into this problem:

What was happening was that when the install was run for All users the createInstance in the dotNet installer class was creating 2 instances of Word (one as SYSTEM user and one as my NT userid).

The installation I pulled the installer class from was forcing 'current user' and only correctly creating one instance of Word.

So it looks like Installshield will run operations in 2 contexts, one for the current user and one for all users.

Christopher Painter
06-21-2006, 10:39 AM
Enjoy. Personally I wouldn't do it. MSI custom actions are unmanaged. InstallUtil is mixed mode and doesn't provide real access to the MSI handle.

Your basically invoking a Type1 DLL custom action that launches the CLR just to do COM interop back to office which is also unmanaged code. There are so many points of failure that it spins my head. This may seem desirable since your getting to write in a `modern` .Net language but really InstallScript is a better choice since it's a Domain Specific Language. Maybe one day .Net will be preinstalled with every deployed version of Windows and MSI will natively support a ManagedCode custom action type that supports the MSIHANDLE, but until then I'd stick with InstallScript.

If you ever decide to refactor, take a look at InstallScripts CreateObject() function.

bruno_k
06-21-2006, 02:12 PM
yup, I agree, but we're incorporating code from another vendor on a joint project, so I'll stick with what they've implemented for now.

Thanks for the tip on CreateObject()