Access Session.Property in Managed DLL

[Videstra]

When creating a custom action in VBScript I can get the value of any session property thusly:

MyVariable = Session.Property("InstallDir")

and it works brilliantly.

Now I need to do this in a Visual Basic managed DLL (Using Visual Studio 2008).

Of course Session.Property means nothing to the VB.NET IDE so I assume I have to include something - but I haven't a clue.

Any ideas?

[MichaelU]

This document with associated files talks from a C# perspective, but shows a couple approaches that will work similarly (with merely syntax changes) in VB.net. See http://community.installshield.com/attachment.php?attachmentid=7220&d=1217951981 and the files in \Samples\WindowsInstaller\Managed Custom Actions.

[Videstra]

Ok - thanks - got it working. But now it occurs to me that I need this to work in 64 bits too.

A. Is InstallShield.Interop.Msi.dll only available as a 32 bit DLL?
B. Is there another way I should be doing this?

By "this" I mean simply passing the value of INSTALLDIR to my managed DLL.

[Christopher_Pai]

Yes, I only use Microsoft.Deployment.WindowsInstaller ( WiX DTF ). It presents managed custom actions to the windows installer as standard type 1 msi style dll's and provides your code a Session class that is very similar to the Session object in VBScript CA's.

http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html

var foo = session["PROP"];
session["PROP"] = "value";
session.Log("Hello World");

using( var view = session.Database.OpenView( "SELECT * FROM `Property`")
{
foreach( var record in view )
{
string property = record[0].ToString();
string value = record["Value"].ToString();
// do something
}
}

return ActionResult.Success;


There simply is no better way to roll and it works with InstallShield perfectly. You can take that to the bank.

[Videstra]

Thanks Chris - I will look into this. Is it fully capable of 64 bit?
It seems that authoring a truly functional CA is extremely esoteric and something as simple as passing an argument into a CA function is an over-the-top complicated thing. I'm learning that authoring an installer is every bit as complex as writing the program you are installing, only worse - you often have to employ multiple languages to make it work! So far my installer has some Install Script, some VBS and a managed DLL written in VB.Net.
Anything to help make this a little simpler is welcomed in my environment!

[Christopher_Pai]

Per the MSI SDK documentation ( "64-Bit Custom Actions" )

On 64-bit operating systems, Windows Installer may call custom actions that have been compiled for 32-bit or 64-bit systems.

A 64-bit custom action based on Scripts must be explicitly marked as a 64-bit custom action by adding the msidbCustomActionType64BitScript bit to the custom actions numeric type in the Type column of the CustomAction table.

Constant Hexadecimal Decimal Meaning
msidbCustomActionType64BitScript 0x0001000 4096 This is a 64-bit custom action written in Scripts.


What does this mean for DTF? DTF wraps your managed class with an unmanaged 32bit wrapper. But that's ok because it calls RunDLL to go out of process and start up the CLR for you. Assuming you set your project to AnyCPU your class will then become either a 32bit or 64bit process and still be able to communicate with your MSI.

I've done session.Log( IntPtr.Size.ToString() ) and confirmed I see 4 on my x86 windows and 8 on my x64 windows.

[Christopher_Pai]

BTW, did I mention you can attach a debugger to DTF custom actions?