Managed Code Custom Action

[yamakamyar]

Hi:

All my calls to the new feature CA Managed Code works great when on my smoke-test machine XP or Vista SQL Server 2005 Express is installed. When SQL Express 2005 is not installed when my code hits the CA Managed Code it aborts...

The C# code runs .NET 3.5. It references InstallShield.Interop.Msi.dll located in the System folder of the 2009 InstallShield. I haven't looked at dependencies for the interop yet. Is there some kind of depenedency between referencing the interop and SQL Server?

Framework 2.0 SP2, 3.0 SP2, and 3.5 SP1 are installed. I thought it could have been something with MSXML version but those were not it...

Has anyone experienced this behavior when using the interop DLL?

Thanks,
Yama

[MichaelU]

Our interop dll should only depend on msi.dll and standard framework v2.0 DLLs. Does the assembly for the method you're calling into have any other dependencies? Is there anything relevant in a verbose MSI log?

[yamakamyar]

The binary is:
1. Class Library
2. .NET Framework 3.5

References:
1. InstallShield.Interop.Msi.dll
2. System
3. System.Core
4. System.Data
5. System.Data.DataSetExtension
6. System.EnterpriseServices
7. System.Xml
8. System.Xml.Linq


Using the following code will abort without SQL Server (need further testing today to confirm)

public void Testing(Int32 handle)
{
try
{
InstallShieldLogger("start: handle = " + handle.ToString());
InstallShieldLogger(Msi.CustomActionHandle(handle).GetProperty("INSTALLDIR"));
Msi.CustomActionHandle(handle).ResetProgressBar(100, true, true);
Msi.CustomActionHandle(handle).AddTicksToProgressBar(75);
Msi.CustomActionHandle(handle).IncrementProgressBar(50);
InstallShieldLogger("end: handle = " + handle.ToString());
}
catch (Exception e)
{
InstallShieldLogger(e.ToString());
}
}

private void InstallShieldLogger(string message)
{
using (TextWriter tw = new StreamWriter(@"C:\InstallShieldLogging.txt", true))
{
tw.WriteLine(message);
}
}

In IsClrWrap:
TestingInterop: Type 0
Class myAssemblyNamespace.ClassName
Return -
Assembly \myTest.dll
Dependency0 \system\InstallShield.Interop.Msi.dll
MEthod Testing
Param1 MsiHandle

Any clues?
Yama

[MichaelU]

I don't see any references that worry me there. You aren't testing on a machine that starts without the v3.5 framework, install it and continue your installation without a reboot, are you? Again, I'd suggest looking at the verbose MSI log around this action for any clues - exception tracebacks should be included there, if relevant.

As a style comment, I'd suggest a slight refactor to store Msi.CustomActionHandle in a local Msi.Install variable:

InstallShieldLogger("start: handle = " + handle.ToString());
Msi.Install install = Msi.CustomActionHandle(handle);
InstallShieldLogger(install.GetProperty("INSTALLDIR"));
install.ResetProgressBar(100, true, true);
install.AddTicksToProgressBar(75);
install.IncrementProgressBar(50);
InstallShieldLogger("end: handle = " + handle.ToString());

But I don't think the other way should cause any problems, and certainly not just when SQL Server isn't installed.

[yamakamyar]

Figured out why SQL Server caused this issue (error 1603) using msiexec /i "myism.ism" /L*v "mylog.log" I saw the problem was in the contructor which I had as follow without a try an a catch go figure 😄

It was throwing an ArgumentNullREference as expected! LOL So without no further due here is the arrrgggg!! code...


namespace myAssemblyNamespace
{
public ClassName : IClassname
{

public ClassName : base()
{
InstallShieldLogger("*** Constructor ***");
registrySQLPath = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Microsoft SQL
Server\80\Tools\ClientSetup\").GetValue("SQLPath").ToString();
}
private static string registrySQLPath;
//-- rest of code
}
}

My code basically takes a set of assembly names installed by our client and server installers and performs NGen, GAC, UnNGen, UnGAC, adds firewall rules for our other installer which includes the SQL Server Express 2005 (open ports or adds sql server to exception rules), deletes firewall rule. The process for performing these tasks can take between 3 to 5 minutes.

So accessing MsiHandle and allowing control from the managed environment was like a dream come true!

Truly thanks for the interop Msi.
Yama