Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Script to set NoImpersonate bit for custom actions in Visual Studio 2005 setup projects

Script to set NoImpersonate bit for custom actions in Visual Studio 2005 setup projects

Rate This
  • Comments 14

I previously posted a set of steps that can be used to toggle the NoImpersonate bit for custom actions in MSI-based setups created with Visual Studio 2005 setup projects.  This type of script is necessary because custom actions created in the VS setup project designers do not have this attribute, and there is no way to set this attribute via the UI.

Unfortunately, my file server has been unreliable lately, which has made it difficult to download the Jscript file used in this in these instructions.  As a result, I decided to post the source code for that script here so you can copy and paste it into a file for use in your build process.

Here are the instructions that can be used to modify an MSI built in VS 2005 to set the NoImpersonate attribute for all deferred custom actions:

  1. Copy and paste the code listed below and save it to the directory that contains the Visual Studio project you are working on with the name CustomAction_NoImpersonate.js (or download the sample script and extract the contents to the project directory)
  2. Open the project in Visual Studio 2005
  3. Press F4 to display the Properties window
  4. Click on the name of your setup/deployment project in the Solution Explorer
  5. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
  6. Click on the "..." button to display the Post-build Event Command Line dialog
  7. Add the following command line in the Post-build event command line text box:
    cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOuputPath)"
  8. Build your project in Visual Studio 2005 - now all deferred custom actions will have the NoImpersonate bit set for them

Here is the source code for CustomAction_NoImpersonate.js.  You can cut and paste all of the text below into a file and save it to your computer to use with your setup projects:

// Usage: CustomAction_NoImpersonate.js <msi-file>
// Performs a post-build fixup of an MSI to change all
// deferred custom actions to include NoImpersonate

// Constant values from Windows Installer
var msiOpenDatabaseModeTransact = 1;

var msiViewModifyInsert = 1
var msiViewModifyUpdate = 2
var msiViewModifyAssign = 3
var msiViewModifyReplace = 4
var msiViewModifyDelete = 6

var msidbCustomActionTypeInScript = 0x00000400;
var msidbCustomActionTypeNoImpersonate = 0x00000800

if (WScript.Arguments.Length != 1)
{
  WScript.StdErr.WriteLine(WScript.ScriptName + " file");
  WScript.Quit(1);
}

var filespec = WScript.Arguments(0);
var installer = WScript.CreateObject("WindowsInstaller.Installer");
var database = installer.OpenDatabase(filespec, msiOpenDatabaseModeTransact);

var sql
var view
var record

try
{
  sql = "SELECT `Action`, `Type`, `Source`, `Target` FROM `CustomAction`"
  view = database.OpenView(sql);
  view.Execute();
  record = view.Fetch();
  while (record)
  {

    if (record.IntegerData(2) & msidbCustomActionTypeInScript)
    {
      record.IntegerData(2) = record.IntegerData(2) | msidbCustomActionTypeNoImpersonate;
      view.Modify(msiViewModifyReplace, record);
    }
    record = view.Fetch();
  }

  view.Close();
  database.Commit();
}
catch(e)
{
  WScript.StdErr.WriteLine(e);
  WScript.Quit(1);
}

  • In case you haven't noticed, there are a couple of gaps within setup projects regarding how the generated

  • PingBack from http://msdnrss.thecoderblogs.com/2007/06/01/moving-into-del-boca-vista-with-the-costanzas/

  • The gaps are huge... 100+ comments along the lines of `VDPROJ sucks` should convince anyone by now.  Anyone who works outside of Microsoft and spends any amount of effort to learn MSI quickly learns their limitations.

  • This script is immensely helpful.  Thank you.  I sincerely hope this makes it into Orca as a custom action property.

    Vince

  • Hi,

    The custom action works with this script. But i encountered one more problem after this. I am not able to install my product in the full silent mode using msiexec. I am able to install the product in the silent mode using msiexec without this post build event. Why does this happen?

  • Hi Vharron - The setup projects in Visual Studio Orcas will correctly set the NoImpersonate bit for deferred custom actions, so this script will no longer be needed in the new version of VS.

    Hi Mithun - This script only adds the NoImpersonate bit to deferred custom actions, which will not affect whether or not the MSI will run correctly in silent mode.  What kind of UI do you see when you try to run it in silent mode, and what is the exact command line you are using to try to install it?

  • Is there a comprehensive list of other things fixed for VDPROJ in VS2008?  

    The top three that I'd be interested in would be:

    Proper MSBuild support

    Fix the Merge Module Directory table bug introduced in VS2005 that was never fixed

    Opt-Out of the annoying dependency scanning `feature`

  • Hi Christopher - Unfortunately, I don't have a comprehensive list of fixes for the VDProj system in VS 2008.  Regarding your top 3:

    1.  MSBuild support is definitely on our radar, but will not be available in VS 2008.  This is something we are definitely looking at for future versions.

    2.  I haven't been able to find any information so far about the MSM directory table bug that you're referring to.  Do you have more specific details so I can investigate further?

    3.  There are no current plans to update the dependency scanning functionality.  For now, you will have to manually exclude dependencies found by the scanner that you do not want to end up in your resultant MSI.

  • For #1, this is a killer for anyone doing build automation.  I use TFS and I hate having to do custom tasks to go out of process to DevEnv ( which I shouldn't need installed ).

    For #2, wow, how can you miss it? Just author a MSM in VDPROJ and define a module retarget folder.  It's missing the .: and can't be associated to a parent installer correctly without writing a postbuild script to tweak the table.  It was caught in the VS2005 beta but never fixed in the RTM or the service pack.

    http://groups.google.com/group/microsoft.public.dotnet.framework.setup/browse_thread/thread/241188147a4702c9/84d3ac7a324d8e5c?lnk=st&q=visual+studio+directory+table&rnum=2#84d3ac7a324d8e5c

    http://support.installshield.com/kb/view.asp?articleid=Q112116

    http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=105512

    For #3, this was a *HUGE* problem for the build team at my last job.  The problem with excluding is you have to find the dependency first.  The developers would do this, but then on a build box a different dependency would be detected.  We finally write a program that opened up the project in the IDE to get the dependencies to be caught and then programatically disabled them.  Really, really ugly stuff....

  • Hi Christopher - I totally agree about #1 being a big pain.  Unfortunately the cost of doing full MSBuild integration didn't fit into the timeframe of VS 2008.  This is definitely on the team's radar for future editions of VS.  In the meantime, there are other solutions like WiX that do support full MSBuild and TFS Team Build integration.

    For #2, it looks like there was some misunderstanding about the exact repro case on our side back in the VS 2005 timeframe.  I've opened a new bug and hopefully there will be time to get this in for VS 2008.

    I'm not sure the scenario you mention for #3 has been thought of in much detail here.  I'd suggest reporting this as a bug on the Connect site at http://connect.microsoft.com/visualstudio/ and describe your scenario in more detail and also provide ideas about how you would envision it working to better suit this type of build environment.

  • Votive has great MSBuild/TFS/VS integration support...... now if it actually just had some designers.

    For dependency scanning, you don't have to look any further then ISHNMET to know how it should be handled.  Components get an extended attribute called `.NET Scanning` with three options:  Deps & Props, Props, None.  There is also a tool setting for selecting the default state of freshly created components.   I almost always set it to Props.

  • You can use the same script for setting the bit NoImpersonate for custom actions in Visual Studio 2010 setup projects?

  • Hi Jose Sandoval - I haven't tried it, but I think it should also work in VS 2010.  If you're able to give it a try, I'd appreciate it if you could post a comment here about your experience so that others will know in the future.

Page 1 of 1 (14 items)
Leave a Comment
  • Please add 7 and 1 and type the answer here:
  • Post