This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Access Session.Property in Managed DLL
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
10:26 AM
Access Session.Property in Managed DLL
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?
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?
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
11:11 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
04:13 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
04:31 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
06:32 PM
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!
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
07:39 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2010
07:42 PM
BTW, did I mention you can attach a debugger to DTF custom actions?