laservision1.55249138997464E12 asked a question.
MsiExec.exe causes exception on CA with managed code
When I use a CA with managed code I get a nasty exception with the MsiExec.exe, see attachment. I have seen it working on a new installed system, but on a running systems I got into this problem on at least three different computers. The C code in the managed dll can not be the problem, it's too simple to break and both methods are with inside a try-catch block, I hope you agree on this:
public class Helper
{
public Helper() { }
public static string ToUpper(string value)
{
try
{
if (value != null) { return value.ToUpper(); }
}
catch { }
return String.Empty;
}
....
I tried a workaround where I tried to increase the assembly trust in the .NET Framework 1.1 Configuration. This is obviously not possible on the setup.exe but strangely the setup worked after that - BUT not always. I guess this has nothing to do with it.
Any ideas?
My system configuration:
- Windows XP SP2
- NET 1.1 with SP1 installed
- Managed code dll written in C with .NET 1.1
- Disabled code optimization in the project setting of the managed code dll
- Set the location of the custom action to be "Stored in the Binary table"
- Install UI Sequence "After LaunchConditions", Condition "Not installed"
When I start the setup and I have no exception (later, on the same machine, killed all MsiExec, done my "workaround") I see three MsiExecs in the Taskmanager! That makes me wonder how my dll is called by the setup. Is there some kind of resource synchronization problem depending which MsiExec is called first? Maybe the sequence point for the CA is to early in the process but I want to call this only once before the dialogs are shown.
I hope someone could help me...
Ciao
Toni
Image file error
I'd switch to .NET 2.0 and checkout DTF for your CA hosting/interop mechanism. It's far superior to InstallShield's managed custom action pattern.
Still the problem is why this message box pops up when the setup.exe is calling the dll.
I don't think that writing the dll in .NET in 2.0 is an option. I only can assure that 1.1 is installed...
[CODE]...
MSI (c) (30:94) [09:49:32:328]: Doing action: MakeMachineIdUpperCase
Action 09:49:32: MakeMachineIdUpperCase.
Action start 09:49:32: MakeMachineIdUpperCase.
MSI (c) (30:94) [09:49:32:359]: Creating MSIHANDLE (26) of type 790542 for thread 916
MSI (c) (30:EC) [09:49:32:359]: Invoking remote custom action. DLL: C:\DOKUME~1\LV1126\LOKALE~1\Temp\MSI51.tmp, Entrypoint: m1
MSI (c) (30:EC) [09:49:32:359]: Lost connection to custom action server process. Attempting to regenerate.
MSI (c) (30:68) [09:49:32:359]: Cloaking enabled.
MSI (c) (30:68) [09:49:32:359]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (30:68) [09:49:32:359]: Connected to service for CA interface.
MSI (c) (30!74) [09:49:32:421]: Creating MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:421]: Closing MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Creating MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Closing MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30:EC) [09:49:58:421]: Closing MSIHANDLE (26) of type 790542 for thread 916
Action ended 09:49:58: MakeMachineIdUpperCase. Return value 1.
...[/CODE]
Hope that this helps you to get an idea, Michael.
Checking the forum shows that this problem exists at least since 2005 , also 2007 and 2008 someone got into the same situation.
So, what I would like to know is - because I assume that this will not be fixed in the near future - is this a general problem calling any kind of dll? If I would replace the .NET dll with a custom dll would I get the same trouble?
Can I achieve following two things with IS build in mechanism?
1. I want to check if volume "D:" exists, to change a default path. The volume might exists but could be a CD, but I want to be sure that I can use it to write to it.
2. I want to write to the registry a string in upper case.
Thx in advance
Toni
[CODE]...
MSI (c) (30:94) [09:49:32:328]: Doing action: MakeMachineIdUpperCase
Action 09:49:32: MakeMachineIdUpperCase.
Action start 09:49:32: MakeMachineIdUpperCase.
MSI (c) (30:94) [09:49:32:359]: Creating MSIHANDLE (26) of type 790542 for thread 916
MSI (c) (30:EC) [09:49:32:359]: Invoking remote custom action. DLL: C:\DOKUME~1\LV1126\LOKALE~1\Temp\MSI51.tmp, Entrypoint: m1
MSI (c) (30:EC) [09:49:32:359]: Lost connection to custom action server process. Attempting to regenerate.
MSI (c) (30:68) [09:49:32:359]: Cloaking enabled.
MSI (c) (30:68) [09:49:32:359]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (30:68) [09:49:32:359]: Connected to service for CA interface.
MSI (c) (30!74) [09:49:32:421]: Creating MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:421]: Closing MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Creating MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Closing MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30:EC) [09:49:58:421]: Closing MSIHANDLE (26) of type 790542 for thread 916
Action ended 09:49:58: MakeMachineIdUpperCase. Return value 1.
...[/CODE]
Hope that this helps you to get an idea, Michael.
Checking the forum shows that this problem exists at least since 2005 , also 2007 and 2008 someone got into the same problem.
So, what I would like to know is - because I assume that this will not be fixed in the near future - is this a general problem calling any kind of dll? If I would replace the .NET dll with a custom dll wouild I get the same trouble?
Can I achieve following two things with IS build in mechanism?
1. I want to check if volume "D:" exists, to change a default path. The volume might exists but could be a CD, but I want to be sure that I can use it to write to it.
2. I want to write to the registry a string in upper case.
Thx in advance
Toni
I was able to get rid (currently) of the MSIExec exceptions but this was not straight forward: I have the strange feeling that this problem occurs when the UI is visible and the CA should be working in the background. Therefore I executed the first CA before the UI starts, but the second I had no clue where to put it - tried several possibilities...So, as a hack I created a InstallScript, great :mad: (I wanted to get rid of this ...)
This still leaves me all in doubt if the solution is fool proof in all cases...
Found two articles that are saying this kind of CA is a bad idea:
I wonder why this is sold as major feature for IS if in the end it useless.
Anyone experience with Wix? Couldn't test it because you have to have at least VS2005 installed - still not finished :mad: Will try it later at home, but anyone: Can I make my CAs with this one?
Bye
Toni
The solution to managed CA woes is WiX's DTF and it doesn't cause you to leave InstallShield. It allows MSI/InstallShield to treat managed code as C++ style custom actions.
The problem is you refuse to take a dependency on .NET 2.0 which is required by DTF.
I hate to tell you so, but I already told you what you need to do. So either go back to InstallScript, write it in C++ or adopt .NET 2.0 and use DTF.
I appreciate your comments pointing me out to WiX and DTF, probably the solution to my problem - haven't heart of WiX before and made not the connection that DTF has something to do with it, so thank you for that.
But as I wrote earlier we are still bound to .NET 1.1 take this as a fact which I can not change in the short run - I might add that our Software must still run on several NT4 systems (end of story of using 2.0). So I hope you agree that installing 2.0 only for install reasons is not an acceptable solution. I know 2.0, 3.5 and know that 1.1 has a lot of other deficiency, e.g. I waisted a lot of time finding memory leaks.
Toni
I would say that from my experience that using Custom Actions does not always work as expected. Errors usually occurs on systems that are to be updated and not on a clean install. This is because the first installer many times leaves one or more instances of msiexec running. I have no idea why. When I run an upgrade the installer (msiexec) sometimes terminates when the first CA is executed. If I kill all msiexec before trying to upgrade it usually works fine. No useful info in the verbose log. The type of error can vary from the standard dialog saying that msiexec just stopped working to DEP (Data Execution Prevention) errors that causes msiexec to terminate. I don't know if this is a MSI or InstallShield problem but I'm leaning toward MSI. Also, I am not using manages code but a standard Win32 MSI dll.