none
Trying to change Custom Action type to get around error: "There is a problem with this Windows Installer package", but can't set msidbCustomActionTypeInScript flag. RRS feed

  • Question

  • I have an msi file that is created by a Setup and Deploy project (.NET 2.0 SP1). I do several modifications to it post-build using an msi editing program. One of the things that is added after the fact is a few CustomActions which call a binary (executable) that is stored in the msi file itself.

    I have not personally had any problems with this msi installer, but a few people (all of which who are on Vista) have gotten the following error when trying to run the msi:

    "There is a problem with this Windows Installer package. A program required for this install to complete could not be run."

    I assumed that this was referring to the Custom Action binary program that tries to run during the install. This was later confirmed.

    After some searching, I found that the problem is essentially caused because the Custom Actions try to run as the current user, when they should be running as an admin or local system or something like that. I further found that you can get around this error by disabling UAC. This fix works, but it is obviously not ideal, because then I have to walk the user through disabling UAC, installing the app, and then re-enabling UAC (this requires two reboots). I'm assuming that I'd have to do the same thing if they ever try to uninstall it (since the uninstall sequence calls the same binary using a Custom Action).

    So, I went looking for some settings to put in the msi that will keep it from trying to impersonate the user. I found some Custom Action "Type" flags which can be set here:

    http://msdn.microsoft.com/en-us/library/aa368069%28VS.85%29.aspx

    ...as well as someone who had issues with setting the needed flags:

    http://n2.nabble.com/How-to-set-msidbCustomActionTypeNoImpersonate-in-Wix-td700008.html

    The problem is... it looks like I need to set two flags. msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate. These have decimal values of 1024 and 2048 respectively. Together, they add up to 3072.

    My Custom Action runs an executable, so it already has a Type of 2.

    I would think that I could put 3074 in the Type field and it would incorporate all three of the flags (2 + 1024 +2048). But when I do this, the msi fails to run even on my machine, with this error:

    "The installer has encountered an unexpected error installing the package. This may indicate a problem with this package. The error code is 2762"

    So... when I set all three flags in the Custom Action "Type" field, I can't launch the msi on any machines (even the ones who don't have the original error).

    But... if I get rid of the msidbCustomActionTypeInScript flag and just use a Type of 2050 (2 + 2048), the installer works again. Unfortunately, it doesn't solve the original problem. Apparently, the msidbCustomActionTypeInScript is the problem, because if I just try 1026 (2 + 1024), it also fails with the same error. Any combination involving the msidbCustomActionTypeInScript flag fails on my machine.

    So... I'm trying to figure out...

    1) If these Custom Action "Type" flags are the solution I should be using for the original error that I received. If not, then what is?

    2) If this IS the type of solution I should be pursuing, then how do I set a Custom Action to have both the flags (msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate)?


    WATYF
    Thursday, March 4, 2010 7:10 PM

Answers

  • Well, I found the solution to this myself. It appears that the issue had to do with where in the Install Sequence the Custom Actions we running. When they had a Type of 2, they apparently could run anywhere, but once I changed the Type to 3074, they had to run between InstallInitialize and InstallFinalize. One of the Actions was running during the UISequence, and that caused the secondary error, so I just got rid of that Action (since I ended up finding out that it was redundant). The other Actons were moved between InstallInitialize and InstallFinalize in the Install Sequence, and the original error, and the secondary error, both went away.

    For anyone who's interested, I was able to find out exactly where the errors in the install were by running the msi with verbose logging enabled using this:

    msiexec.exe /i myinstaller.msi /L*v c:\mylogfile.txt

    WATYF
    Friday, March 5, 2010 5:16 PM
  • Hello WATYF,

    It is so great to hear you have found the solution.

    If you have any issues related to setup, etc. You can post it on the ClickOnce and Setup & Deployment Projects Forum or corresponding language general forum which will make answer searching in the forum easier and be beneficial to other community members.

    Thanks.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Monday, March 8, 2010 8:08 AM
    Moderator

All replies

  • Well, I found the solution to this myself. It appears that the issue had to do with where in the Install Sequence the Custom Actions we running. When they had a Type of 2, they apparently could run anywhere, but once I changed the Type to 3074, they had to run between InstallInitialize and InstallFinalize. One of the Actions was running during the UISequence, and that caused the secondary error, so I just got rid of that Action (since I ended up finding out that it was redundant). The other Actons were moved between InstallInitialize and InstallFinalize in the Install Sequence, and the original error, and the secondary error, both went away.

    For anyone who's interested, I was able to find out exactly where the errors in the install were by running the msi with verbose logging enabled using this:

    msiexec.exe /i myinstaller.msi /L*v c:\mylogfile.txt

    WATYF
    Friday, March 5, 2010 5:16 PM
  • Hello WATYF,

    It is so great to hear you have found the solution.

    If you have any issues related to setup, etc. You can post it on the ClickOnce and Setup & Deployment Projects Forum or corresponding language general forum which will make answer searching in the forum easier and be beneficial to other community members.

    Thanks.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Monday, March 8, 2010 8:08 AM
    Moderator
  • Sorry... I thought this was the forum for msi/Setup Project questions.

    WATYF
    Monday, March 8, 2010 7:00 PM
  • Thank you.
    Thursday, March 11, 2010 9:40 AM
  • Well, I found the solution to this myself. It appears that the issue had to do with where in the Install Sequence the Custom Actions we running. When they had a Type of 2, they apparently could run anywhere, but once I changed the Type to 3074, they had to run between InstallInitialize and InstallFinalize. One of the Actions was running during the UISequence, and that caused the secondary error, so I just got rid of that Action (since I ended up finding out that it was redundant). The other Actons were moved between InstallInitialize and InstallFinalize in the Install Sequence, and the original error, and the secondary error, both went away.

    For anyone who's interested, I was able to find out exactly where the errors in the install were by running the msi with verbose logging enabled using this:

    msiexec.exe /i myinstaller.msi /L*v c:\mylogfile.txt

    WATYF

    I encountered the same problem, The reason is quite out of my expectation.
    Sunday, August 8, 2010 8:58 AM