Aaron Stebner's WebLog

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

May, 2007

  • Aaron Stebner's WebLog

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

    • 14 Comments

    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);
    }

  • Aaron Stebner's WebLog

    How to prevent the Program Compatibility Assistant from appearing on Windows Vista

    • 10 Comments

    While researching the root cause of the issue that can cause a Windows XP SP2 block dialog to appear when trying to install the .NET Framework 3.5 beta 1 on Windows Vista (described in more detail in this blog post), I learned some useful information about the Program Compatibility Assistant (PCA) that I wanted to summarize here.

    What kinds of applications are affected by the Program Compatibility Assistant?

    The Program Compatibility Assistant monitors setup applications that it detects are not Windows Vista-aware.  The PCA uses a list of well-known names such as setup.exe, install.exe, etc to try to decide whether or not an application is a setup.  The PCA treats all setup applications that do not have an embedded manifest that specifies a requested execution level (asInvoker, highestAvailable or requireAdministrator).

    In the case of the .NET Framework 3.5 beta 1, the setup package did not include an embedded manifest specifying a requested execution level, and it was named dotnetfx35setup.exe, which triggers the Windows Vista legacy setup application detection logic.

    When does the Program Compatibility Assistant appear?

    Once the Program Compatibility Assistant identifies a non-Windows Vista-aware setup application, it will monitor the Programs and Features control panel (previously known as Add/Remove Programs).  If an entry is not created or removed from the Programs and Features control panel, then the PCA treats the process as a failed setup and displays a dialog after the setup process exits that asks if the user wants to attempt to re-install using recommended settings.  In this case, using recommended settings will cause Windows Vista to re-run the setup using Windows XP SP2 compatibility mode.

    In the case of the .NET Framework 3.5 beta 1, because the setup application is treated as a non-Windows Vista-aware setup, whenever it returns without creating or removing a Programs and Features control panel entry, the PCA dialog will appear (even if you simply launch setup and cancel on the End User License Agreement page).

    How can I opt out of the Program Compatibility Assistant for my setup?

    In order to prevent the Program Compatibility Assistant from appearing, you must include an embedded manifest that specifies a requested execution level for your setup executable.  If you wrap the setup executable in a self-extracting package, you must also include an embedded manifest in the self-extracting package too.  Once you do this, Windows Vista will treat your setup as Windows Vista-aware, and it will no longer show the PCA dialog when setup exits after a failure or cancellation.

    Where can I find more detailed documentation?

    For more detailed information about the Program Compatibility Assistant, I encourage you to check out the following resources:

  • Aaron Stebner's WebLog

    Mailbag: Why does my custom action that depends on the VC 8.0 CRT fail on Windows Vista?

    • 8 Comments

    Question:

    I have built an MSI-based setup for my application that includes the merge module for the Visual C++ 8.0 CRT (msvcrt80.dll).  In addition, the MSI contains a custom action that has a dependency on the Visual C++ 8.0 CRT.  I have been able to successfully install this MSI on Windows XP, Windows Server 2003 and Windows Vista in the past.

    Recently, I updated my development system to Visual Studio 2005 SP1.  After I did this and rebuilt my MSI, I am no longer able to install my MSI on Windows Vista.  The custom action that depends on the VC 8.0 CRT no longer runs correctly.

    Why did this error just start happening, and how can I resolve it so that I can install my MSI correctly on Windows Vista?

    Answer:

    As I previously described in this blog post, an MSI that installs any of the VC 8.0 runtime files and also includes custom actions that depend on the VC 8.0 runtime files can run into problems.

    To briefly summarize that blog post, on Windows Vista, the VC 8.0 runtime files are installed as global assemblies using the MsiAssembly and MsiAssemblyName tables.  When global assemblies are installed during an MSI-based setup, they are not fully published and available for use on the system until after the InstallFinalize standard action.  This means that if an MSI installs the VC 8.0 runtime files and also includes custom actions that depend on the VC 8.0 runtime files, then the custom actions must be scheduled after InstallFinalize in order to be guaranteed to not run into dependency issues on Windows Vista.

    The reason why the MSI happened to install correctly on Windows Vista prior to updating your development system to Visual Studio 2005 SP1 is that Windows Vista includes the .NET Framework 2.0, and the .NET Framework 2.0 installs the VC 8.0 CRT (msvcrt80.dll).  This means that the CRT was already present on the system and the custom action in your MSI was able to run correctly as a result.  However, once this MSI is rebuilt using Visual Studio 2005 SP1, the custom action now depends on the VS 2005 SP1 version of the VC 8.0 CRT, which does not ship with the .NET Framework 2.0 and is therefore not on Windows Vista by default.  In this case, your MSI will install the CRT as a global assembly, and the CRT will not be fully published and ready to use until after the InstallFinalize action.

    In order to resolve this issue, you will need to do one of the following:

    • Compile your custom action DLL with #define _USE_RTM_VERSION in order to cause it to always depend on the originally released version of the VC 8.0 CRT, regardless of whether or not you have Visual Studio 2005 SP1 installed
    • Schedule the custom action as a commit custom action so it will run after InstallFinalize and you can be sure that the VC 8.0 CRT will be fully published by your MSI
    • Statically link to the VC 8.0 CRT when building the custom action DLL
    • Remove Visual Studio 2005 SP1 from your development and build system so that the custom action DLL will not depend on the SP1 version of the CRT
    • Re-design your setup so that it uses Windows Installer standard actions where possible and ideally does not require a custom action in the first place (if possible)

    <update date="5/20/2007"> Added an option to compile the custom action with the _USE_RTM_VERSION variable defined </update>

     

  • Aaron Stebner's WebLog

    How to prevent custom actions from running during a Windows Installer major upgrade

    • 6 Comments

    I ran into an interesting scenario related to Windows Installer major upgrades recently and I wanted to summarize some things I learned from this experience and from the MSDN documentation in case they are useful for others.  In the scenario I ran into, I implemented a Windows Installer major upgrade to automatically remove older versions of my MSI behind the scenes as part of the installation process for newer versions of my MSI.

    I scheduled the uninstall of the previous version after InstallFinalize due to the assembly publishing issue described in this blog post.  This scheduling resulted in the newer version being installed before the older version was uninstalled.  However, I needed a way to prevent some of the custom actions in the older version from running during this major upgrade uninstall step because they would interfere with the already installed newer version.

    Fortunately, I was alerted to the existence of the UPGRADINGPRODUCTCODE property in Windows Installer.  When Windows Installer removes an older version of a product in the RemoveExistingProducts action as part of a major upgrade, it sets the UPGRADINGPRODUCTCODE property on the command line for the uninstall action.  This property can be used by the MSI being uninstalled to differentiate between a standard uninstall initiated by the user (via Add/Remove Programs for example) and an uninstall initiated by a newer version of the MSI via a major upgrade.

    What I ended up doing was adding a condition of (NOT UPGRADINGPRODUCTCODE) in the InstallExecuteSequence table for each of the custom actions that I wanted to prevent from running during the major upgrade.  This allowed my major upgrade to work as expected and prevented the uninstall of the older version from breaking the newer version.  It also allowed a standard uninstall of the MSI to correctly execute these custom actions.

    Thanks to Heath Stewart for letting me know about the UPGRADINGPRODUCTCODE property to help out in this scenario.

     

  • Aaron Stebner's WebLog

    Windows Vista Media Center SDK refresh now available for download

    • 5 Comments

    A refreshed version of the Windows Vista Media Center SDK has been released for download on the Microsoft Download Center today.  You can download it at the same location as the original release of the SDK - http://www.microsoft.com/downloads/details.aspx?FamilyID=A43EA0B7-B85F-4612-AA08-3BF128C5873E&displaylang=en.

    This refresh will automatically upgrade any previous version of the Windows Vista Media Center SDK that you have on your system.  This refresh is mostly aimed at enhancing some of the documentation and sample code.  It does not include new versions of the tools like the MCML Preview Tool (McmlPad), but it does now include the MCML Preview Tool Launcher power toy that was previously only available as a separate download.

    The SDK refresh installs to the same c:\Program Files\Microsoft SDKs\Windows Media Center\v5.0 folder by default, but the setup UI and the entry in Add/Remove Programs both specify that the product is named Microsoft Windows Media Center SDK 5.1 (instead of v5.0).  We decided to not change the folder path because a lot of the documentation refers to the v5.0 folder name.

    The following is a summary of the key changes in the Windows Vista Media Center SDK refresh (this list is also available in the Getting Started document that launches at the end of installation):

    • Added several previously standalone MSDN technical articles and blog posts to the help documentation CHM file
    • The MCML Preview Tool Launcher power toy is now included as part of the SDK installation process.  If you previously had the standalone MCML Preview Tool Launcher power toy installed on your system, the new version of the SDK will automatically upgrade it
    • Modified the Q and Z setup projects to use WiX v3.0 instead of WiX v2.0
    • Added an additional shortcut for the MCML Preview Tool (McmlPad) to the Windows Vista Start Menu.  The new shortcut launches McmlPad inside of Windows Media Center by using the ehshell.exe /entrypoint command line switch.  The other shortcut launches McmlPad as a standalone application like it did before
    • Added registry files (*.reg) to the \Tools folder to make it easier to enable and disable application debugging and the application error details button.  The registry value to enable the error details button is set by SDK setup, but the registry file can be useful when attempting to debug application failures on systems that do not have the SDK installed
    • Added C# source code (.cs) files for the samples in McmlSampler that use code-behind
    • Made a few minor fixes and tweaks to the Z sample application
  • Aaron Stebner's WebLog

    .NET Framework 3.5 beta 1 fails to install on pre-release builds of Windows Vista

    • 5 Comments

    I heard from a customer last week who could not get Visual Studio codename Orcas beta 1 to install on their Windows Vista system.  The installation failed during the .NET Framework 3.5 beta 1 prerequisite step.  The .NET Framework 3.5 setup log file (located at %temp%\dd_dotnetfx35install.txt) showed the following error message:

    [04/19/07,20:23:23] Microsoft .NET Framework v3.5: GenericComponent Action: CreateProcess launched with cmd line : C:\Users\Aaron\AppData\Local\Temp\20404.00\1033\wcu\dotnetframework\dotnetfx35setup.exe /q /norestart /lang:ENU
    [04/19/07,20:27:30] Microsoft .NET Framework v3.5: C:\Users\Aaron\AppData\Local\Temp\20404.00\1033\wcu\dotnetframework\dotnetfx35setup.exe exited with return value 1
    [04/19/07,20:27:30] InstallReturnValue: GFN_MID NET Framework v3.5, 0x1
    [04/19/07,20:27:30] Setup.exe: AddGlobalCustomProperty
    [04/19/07,20:27:30] Microsoft .NET Framework v3.5: ***ERRORLOG EVENT*** : Error code 1 for this component means "Incorrect function."

    When installing on Windows Vista, the .NET Framework 3.5 attempts to install service packs for the .NET Framework 2.0 and 3.0 (which are OS components on Windows Vista).  Error code 1 for these service packs mean that the package is not applicable on the system.

    In the scenario where I saw this error last week, the user was running Windows Vista RC2 and not the final release of Windows Vista.  The .NET Framework 2.0 and 3.0 service packs that are included in the .NET Framework 3.5 will only apply to the final release of Windows Vista, and return error code 1 indicating that they do not apply on pre-release builds of Windows Vista.

    This means that if you are still running a pre-release build of Windows Vista, you will not be able to install the .NET Framework 3.5 beta 1 or Visual Studio codename Orcas.

  • Aaron Stebner's WebLog

    Why does .NET Framework 3.5 beta 1 setup tell me to install Windows XP SP2 on Vista?

    • 4 Comments

    Recently, we have heard from a few customers who have been trying to install the .NET Framework 3.5 beta 1 or Visual Studio codename Orcas beta 1 on Windows Vista, but received an error message when they launched setup that stated that they need to install Windows XP SP2.  We have found a scenario where this can end up happening, and I wanted to post a description of the problem and a possible workaround in case you end up in this state on your Windows Vista system.

    Description of the problem

    The .NET Framework or Visual Studio both require Windows XP SP2 before they will allow installation on Windows XP operating systems.  However, if setup is run in Windows XP compatibility mode on Windows Vista, it will think that it needs to run Windows XP OS prerequisite checks and will not be able to find Windows XP SP2 installed.

    How the problem can occur - option 1

    There are a couple of different ways that .NET Framework or Visual Studio setup can be run in compatibility mode on Windows Vista.  The first way is if setup fails or if you cancel setup, and then you select the option to attempt to reinstall using recommended settings after setup exits.

    On Windows Vista, if a setup package exits without creating or removing an Add/Remove Programs entry, Windows Vista assumes that it failed and triggers a Program Compatibility Assistant dialog that states that the program might not have installed correctly.  This dialog has 2 buttons on it - one will cause Windows to try to reinstall using recommended settings, and the other states that the program installed correctly and will not cause Windows to try to take any corrective actions.  This dialog looks like the following:

    If you see a dialog like the following after exiting the .NET Framework or Visual Studio setup on Windows Vista, and you select the option to reinstall using recommended settings, that will cause Windows Vista to re-run the setup in Windows XP compatibility mode.  Doing this will then show a block dialog stating that you need to install Windows XP SP2.  To make matters worse, Windows Vista stores this choice in the registry so that if you try to run the same setup package from the same location in the future, it will continue to display the Windows XP SP2 block dialog.

    How the problem can occur - option 2

    The second way that .NET Framework or Visual Studio setup can be run in compatibility mode on Windows Vista is if you specify this setting directly in the properties for the setup file by doing the following:

    1. Right-click on the setup package and choose Properties
    2. Click on the Compatibility tab in the properties window
    3. In the Compatibility mode section, check the box that is labeled Run the program in compatibility mode for Windows XP (Service Pack 2)
    4. Click OK to save the changes
    5. Re-run the setup package

    The .NET Framework and Visual Studio setup packages do not support running in compatibility mode on Windows Vista, so if you have done the above, you should try to uncheck the box labeled Run the program in compatibility mode for Windows XP (Service Pack 2) and re-run setup to see if it resolves this issue.

    How to resolve the problem

    In order to prevent Windows Vista from running the setup in Windows XP compatibility mode each subsequent time, you can use the following steps to turn off compatibility mode for the setup package:

    1. Right-click on the setup package and choose Properties
    2. Click on the Compatibility tab in the properties window
    3. Click the button at the bottom that is labeled Show settings for all users and click Continue to allow the process to elevate
    4. In the Compatibility mode section, uncheck the box that is labeled Run the program in compatibility mode for Windows XP (Service Pack 2)
    5. Click OK to save the changes
    6. Re-run the setup package

    In case you are interested, Windows Vista stores information about the application compatibility mode to use for specific packages in the registry at the following locations:

    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
    <full path to setup file> = WINXPSP2

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
    <full path to setup file> = WINXPSP2

    If you have problems clearing the Windows XP compatibility mode setting using the steps listed above, you can also clear this setting by removing the appropriate entries directly from these registry locations.

    One last note - in many cases the Program Compatibility Assistant dialog is triggered because of a legitimate failure in either the .NET Framework 3.5 beta 1 or Visual Studio codename Orcas setup.  Once you resolve the compatibility issue where setup tells you to install Windows XP SP2, there will likely be an additional setup error that needs to be resolved.  You can check out my blog categories (for the .NET Framework 3.5 beta 1 and for Visual Studio codename Orcas beta 1) and the Visual Studio Orcas MSDN Forums for additional troubleshooting suggestions if needed.  You can also leave comments on my blog posts or contact me and I can try to help further.

    <update date="5/10/2007"> Added information about the HKEY_CURRENT_USER version of the app compat registry value </update>

    <update date="5/11/2007"> Clarified the exact logic that Windows Vista uses to trigger a PCA dialog.  It monitors additions/removals to the Add/Remove Programs (Programs and Features) control panel, and not the exit code of the process as I originally stated.  For reference, see http://www.microsoft.com/indonesia/msdn/appcomp.aspx </update>

     

  • Aaron Stebner's WebLog

    Links to Microsoft WiX developer blogs

    • 2 Comments

    I have been semi-regularly attending the weekly meetings (described by Rob Mensching in this blog post) to work on the WiX toolset.  This past week, as I was eating some excellent chocolate chip cookies provided by Peter Marcu's wife, I realized that most of the regular contributors to the WiX code base here at Microsoft have their own blogs and have been writing in them fairly regularly.  I wanted to provide a list of links to WiX developer blogs because many of them contain valuable information about setup development in general and WiX specifically.

    I encourage you to keep an eye on the above blogs if you are a setup developer and/or if you are working with WiX.

  • Aaron Stebner's WebLog

    .NET Framework 3.5 will fail to install if .NET Framework 3.0 beta is installed

    • 2 Comments

    A few customers have reported an issue when installing the .NET Framework 3.5 beta 1 or Visual Studio Orcas beta 1.  This particular failure occurs when trying to install one of the .NET Framework 3.0 service packs, which is chained as a part of .NET Framework 3.5 installation. 

    Information about the error

    The .NET Framework 3.5 setup log file (located at %temp%\dd_dotnetfx35install.txt) shows the following error message:

    [05/01/07,04:44:44] Microsoft .NET Framework 3.0SP1 WCF: ***ERRORLOG EVENT*** : Error code 1642 for this component means "The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch."

    Windows Installer error code 1642 means that the base product that the service pack applies to is not actually installed on the system.  In the cases we've seen of this error so far, the system had a beta version of the .NET Framework 3.0 installed.  The .NET Framework 3.0 service packs do not apply to beta versions of the .NET Framework 3.0.

    How to resolve the error

    If you run into this scenario on your system, you can resolve it by uninstalling the beta version of the .NET Framework 3.0 from the Add/Remove Programs control panel on your system and then re-running .NET Framework 3.5 beta 1 or Visual Studio Orcas beta 1 setup.

    A note about the root cause of this error

    The underlying problem here is that the .NET Framework 3.5 uses the following registry value to determine whether or not it needs to install the .NET Framework 3.0:

    [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]
    InstallSuccess=1

    Unfortunately, as I described in this blog post, that InstallSuccess registry value is set in both the beta versions of the .NET Framework 3.0 and the final release.  That means that the .NET Framework 3.5 setup does not currently distinguish between the 3.0 beta and the 3.0 final release when deciding whether or not to install the .NET Framework 3.0 during 3.5 setup.  This will likely be fixed in the future by adding a block to .NET Framework 3.5 setup so it will not install if a beta version of the .NET Framework 3.0 is still installed on the system, but in the meantime you will have to manually uninstall the .NET Framework 3.0 beta if you run into an error like this.

  • Aaron Stebner's WebLog

    Creating a Windows Vista Media Center application using MCML step-by-step

    • 2 Comments

    Charlie Owen has posted links to some really useful information in this post on the Media Center Sandbox blog that I wanted to bring to everyone's attention in case you haven't seen it yet.  He starts by introducing the Windows Vista Media Center SDK refresh.

    Then he continues on and provides links to some extremely useful step by step guides to help developers get started creating Windows Media Center applications using the Windows Media Center Presentation Layer (WMCPL) and Media Center Markup Language (MCML).

    When the Windows Vista Media Center SDK originally shipped, we included a technical reference and a set of samples in the McmlSampler application.  In addition, we included a couple of complete applications (the Q podcast client and the Z sample application).  However, there is a relatively large gap with respect to helping developers who are new to Media Center application development create, test, modify and deploy their own application.  These documents are a really big step towards filling that gap, and I strongly encourage you to take a look at them if you are interested in developing applications for Windows Vista Media Center.

    Creating a Windows Media Center application step by step

    Creating a WiX-based installer for a Windows Media Center application step by step

    Source code used in the above documents

    If you run into questions or have feedback while working through these step by step guides, please let the Media Center team know by posting your thoughts on the Media Center Sandbox forums at http://discuss.mediacentersandbox.com/forums/.

  • Aaron Stebner's WebLog

    .NET Framework 3.5 beta 1 fails to install on Windows Vista from a path with spaces in it

    • 2 Comments

    I have previously posted descriptions of a couple of issues that can cause the .NET Framework 3.5 beta 1 to fail to install -

    Today, I received log files from a customer who ran into a different issue while installing the .NET Framework 3.5 beta 1 on Windows Vista as a part of Visual Studio Orcas beta 1 setup. 

    Symptoms of the error

    The customer who contacted me received a pop-up error message during Visual Studio setup that has a title Windows Update Standalone Installer, text that lists command line switches and an OK button.  It looked like the following:

    How to find information about the error in the setup log files

    The .NET Framework 3.5 setup log file (located at %temp%\dd_dotnetfx35install.txt) showed the following error message:

    [05/07/07,13:28:33] Microsoft .NET Framework 2.0SP1 (CBS): CBSComponent Action: CreateProcess launched with cmd line : C:\Windows\system32\WUSA.exe "C:\Windows\system32\WUSA.exe" c:\Downloaded Files\microsoft\orcas_team\setup\..\wcu\dotnetframework\dotnetmsp\x86\Windows6.0-KB110806-x86.msu /quiet /norestart
    [05/07/07,13:29:08] Microsoft .NET Framework 2.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value 87
    [05/07/07,13:29:09] Microsoft .NET Framework 2.0SP1 (CBS): ***ERRORLOG EVENT*** : Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 87

    When installing on Windows Vista, the .NET Framework 3.5 attempts to install service packs for the .NET Framework 2.0 and 3.0 (which are OS components on Windows Vista).  Error code 87 for these service packs mean that the package could not be installed due to an error with the command line parameters.  In this case, the problem is that the path to the service pack setup file contains a space in it (c:\Downloaded Files), and there is a bug in .NET Framework 3.5 beta 1 setup where it does not correctly put quotes around paths with spaces in them.

    How to resolve the error

    If you run into this issue while attempting to install the .NET Framework 3.5 beta 1 and Visual Studio Orcas beta 1 setup, you will need to move the setup files to a folder that does not contain spaces in the name and then re-run setup.

  • Aaron Stebner's WebLog

    Link to an article describing how to create an MSI that does not prompt for elevation

    • 2 Comments

    As I previously described in this blog post, Windows Installer will prompt users for elevation by default when running MSI-based setups on Windows Vista, but it is possible to opt out of this behavior by making some changes to your MSI.  If you choose to opt out though, you need to make sure that none of the actions in your MSI will require elevation (such as installing files to the GAC, writing registry values under the HKEY_LOCAL_MACHINE hive, etc).

    This week, I ran across an interesting blog post that provides step-by-step instructions and example syntax that can be used to create an MSI in WiX v3.0 that does not prompt for elevation on Windows Vista.  This blog post can be found at this location:

    http://blogs.msdn.com/jamesfi/archive/2007/05/02/making-an-msi-that-doesn-t-need-a-uac-lua-prompt.aspx

    The author of this blog post also describes options for supporting both a per-user install (that does not prompt for elevation) and a per-machine install (that does prompt for elevation).  He demonstrates how to accomplish this within a single MSI, but points out some functional limitations that you will run into if you pursue this option.  The recommended alternative is to create separate MSIs - one for per-user installations and the other for per-machine installations.  Then you can use a bootstrapper setup.exe to determine at install time which MSI to install.

    There is some really helpful information in this blog post, and I encourage setup developers who are interested in how to manage elevation prompts on Windows Vista to take a look at the example WiX code and documentation contained in this post.

  • Aaron Stebner's WebLog

    Mailbag: How to debug 1935 errors with HRESULT 0x80131047 in an MSI-based setup

    • 1 Comments

    Question:

    I am attempting to create an MSI-based setup for my application.  This application needs to install some assemblies to the global assembly cache (GAC), and when I build an MSI and try to install it, setup fails with a 1935 error with HRESULT value 0x80131047 (-2146234297).

    I found your article describing 1935 errors, and according to that article, this HRESULT value corresponds to a FUSION_E_INVALID_NAME error that means "The given assembly name or code-base is invalid."

    This error description does not make much sense to me.  How can I narrow down the root cause of this error and fix my MSI so that it will install correctly? 

    Answer:

    In most of the cases I have seen a 1935 error with HRESULT value 0x80131047 (-2146234297), the root cause has been a mismatch between the assembly identity information listed in the MsiAssemblyName table of the MSI and the assembly identity information in the assembly itself.

    In order to narrow this error down further, I recommend first trying to manually install the assembly to the GAC and then uninstall it from the GAC using the tool gacutil.exe that is included in the .NET Framework SDK and Visual Studio.  Doing this will determine whether or not the problem is in the assembly or in the MSI, and it will also show you the full assembly identity for the assembly as well.  You can use the following steps to do this:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run a command like the following:  "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i <full path to the assembly>
    3. You should see output like the following:
    4. >"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i MyAssembly.dll
      Microsoft (R) .NET Global Assembly Cache Utility. Version 2.0.50727.42
      Copyright (c) Microsoft Corporation. All rights reserved.
      Assembly successfully added to the cache

    5. Run a command like the following:  "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u <name of assembly>
    6. You should see output like the following:
    7. >"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u MyAssembly

      Microsoft (R) .NET Global Assembly Cache Utility. Version 2.0.50727.42
      Copyright (c) Microsoft Corporation. All rights reserved.

      Assembly: MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
      Uninstalled: MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
      Number of assemblies uninstalled = 1
      Number of failures = 0

    If the assembly can be successfully installed to and uninstalled from the GAC using gacutil.exe, then there is likely something incorrectly authored in the MsiAssemblyName table of the MSI.  The next step is to do the following to try to narrow down the MSI authoring issue:

    1. Open the MSI in a tool such as Orca.exe
    2. Locate the entries in the MsiAssemblyName table for the assembly that fails with a 1935 error during setup
    3. Compare the attributes listed for this assembly in the MsiAssemblyName table with the attributes listed when running gacutil.exe for the assembly.
    4. Validate that all of the attributes listed when running gacutil.exe (for example, the highlighted items that appear in step 5 listed above) also appear in the MsiAssemblyName table for this assembly.  All values must match exactly

    It will not cause problems if there are extra values in the MsiAssemblyName table that do not appear when running gacutil.exe.  However, none of the values listed when running gacutil.exe can be missing from the MsiAssemblyName table, and none of the values can contain different data (such as misspellings, non-matching version numbers, different public key tokens, etc)

    For reference, assemblies built with the .NET Framework 1.0 and 1.1 contain the following attributes that combine to form the assembly identity: Name, Version, Culture, PublicKeyToken.  An MSI that installs .NET Framework 1.0/1.1 assemblies to the GAC must contain all 4 of these attributes for each assembly in the MsiAssemblyName table.

    Assemblies built with the .NET Framework 2.0 contain the following attributes that combine to form the assembly identity: Name, Version, Culture, PublicKeyToken, ProcessorArchitecture.  It is important to note that the ProcessorArchitecture attribute is new and will only exist in assemblies created with the .NET Framework 2.0 or later.  An MSI that installs .NET Framework 2.0 assemblies to the GAC must contain all 5 of these attributes for each assembly in the MsiAssemblyName table.

    It is possible to install both .NET Framework 1.0/1.1 and .NET Framework 2.0 assemblies to the GAC in the same MSI.  You will need to make sure that the attributes are correct for each assembly based on what version of the .NET Framework they were built against.  A common problem I have seen in this scenario is to leave off the ProcessorArchitecture attribute for .NET Framework 2.0 assemblies or to include it for .NET Framework 1.0/1.1 assemblies.

  • Aaron Stebner's WebLog

    Strong name signing for Media Center application assemblies

    • 1 Comments

    I have run into an issue a few times recently while helping folks create installers for their Windows Vista Media Center applications that are based on the project templates that ship in the Windows Vista Media Center SDK.  As a result, even though this is covered in the SDK documentation and on the Media Center Sandbox blog, I wanted to specifically describe this scenario, the underlying design of Media Center that introduces this issue and how to fix it in your application.

    Description of the problem

    When creating a new Windows Media Center Presentation Layer application using the project template included in the Windows Vista Media Center SDK, an XML file is generated that can be used with RegisterMceApp.exe to register the application with Media Center.  However, this XML file does not contain a public key token value (because it is not possible to know ahead of time what the public key token will be for each developer/company/etc).  If you do not add a strong name key file to your Media Center application assembly and also add the PublicKeyToken value to the XML file, you will be able to register the application and it will appear in the Media Center UI after registering it, but it will fail to launch correctly.

    Why does this happen?

    Media Center currently only supports loading application assemblies from the global assembly cache (GAC) or from the %windir%\ehome directory.  As a best practice, application developers should install their assemblies to the GAC on users' systems and not fill up the %windir%\ehome directory with files that are not a part of Media Center itself.

    If you are creating a Media Center application that consists of a code-based assembly, and that assembly is installed to the GAC (which it should be if you follow the best practice I listed above), you must register the application using the RegisterApplication API or the RegisterMceApp.exe utility.  When the assembly is located in the GAC, you must specify the full strong name identity for the assembly or else Media Center will not be able to locate the assembly to load it correctly.  The strong name identity for .NET Framework 2.0 assemblies that can be loaded by Windows Vista Media Center consists of the assembly name, the assembly version, the culture, and the public key token (and the processor architecture if you need to create and ship non-MSIL assemblies for some reason).

    How to fix this issue

    In order to fix this issue, you need to do all of the following:

    1. Add a strong name key file to your Visual Studio project
    2. Rebuild your Media Center application assembly
    3. Add the correct PublicKeyToken value to the XML file used to register your application with Media Center

    Charlie wrote up excellent instructions for developing Windows Vista Media Center applications that include steps to do all three of the above things, and they can be found in the Media Center application step-by-step instructions on the Media Center Sandbox blog.  I will also summarize the steps here to hopefully make them easier to discover in web searches.

    To add a strong name key file to the project assembly:

    1. Right-click on the project in the Solution Explorer and choose Properties.
    2. Select the Signing tab.
    3. Check the box labeled Sign the assembly.
    4. Click on the drop-down labeled Choose a strong name key file and select <New...>.
    5. Enter a key file name, and optionally provide a password for the key file.
    6. Click OK to add the key file to the project.
    7. Click on the File menu and choose Save All.
    8. Click on the Build menu and select Build Solution to build the project assembly with the strong name key file included.

    To add a strong name key to App.xml that is included when you create a new Windows Media Center Presentation Layer application using the Visual Studio 2005 project template:

    1. In Visual Studio 2005, click on the Tools menu and select External Tools.
    2. Click the Add button to create a new external tool item.
    3. Enter Get Public Key in the Title text box.
    4. If you are running on an x86 version of Windows, enter C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe in the Command text box. If you are running on an x86 version of Windows, enter C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe in the Command text box.
    5. Enter -Tp "$(TargetPath)" in the Arguments text box.
    6. Uncheck all options except Use Output window.
    7. Click the OK button.
    8. Click on the Tools menu and select Get Public Key.
    9. Copy the public key token value.
    10. Open the file App.xml and locate the addin value in the entrypoint element.
    11. After the text Version=6.0.6000.0, add a comma and the text PublicKeyToken= and then add the public key token that was reported by the Get Public Key tool.
    12. Save and close App.xml.

    After using the above steps, you can proceed to create an MSI-based installer for your application using the WiX installer instructions in the step-by-step guide.  When installing the MSI, your application assembly should install correctly to the GAC and Media Center will know how to load it because the registration XML file contains the full strong name identity information for your assembly.

  • Aaron Stebner's WebLog

    You can now boot an Xbox 360 directly into Media Center

    • 1 Comments

    I just noticed blog posts from Michael Creasy and Ian Dixon that I want to make sure everyone notices.  If you have an Xbox 360 that you are using as a Media Center extender, once you install the Xbox Spring 2007 Dashboard Update, you will be able to configure your Xbox 360 to boot directly to your Media Center.

    To access this new setting, go to the Xbox Dashboard, then the System tab.  Under Console Settings, select Startup, and you will now see 3 options:  Disc, Xbox Dashboard and Media Center.

    If you use your Xbox 360 primarily as a Media Center extender, this might be a really useful option for you to try out.

  • Aaron Stebner's WebLog

    Installing the Media Center SDK on a system with an un-activated VS Express Edition

    • 0 Comments

    I recently installed the refreshed version of the Windows Vista Media Center SDK on one of my Windows Vista system and ran into an installation issue that I wanted to describe here in case anyone else sees similar issues when installing the SDK on their systems. 

    The root cause of the issue is that if you install any of the Visual Studio 2005 Express Editions from the web download links, they require you to perform a free registration within 30 days of installing them.

    On the system where I saw this issue, I had the Visual C# 2005 Express Edition installed, but had not yet registered it.  Then, when Media Center SDK setup ran, it invoked the Visual C# Express Edition as a custom action in order to register the Media Center project templates and item templates within the Visual C# IDE.  Since my copy of Visual C# had been installed more than 30 days ago and had not yet been registered, when it was invoked during SDK setup, it popped up a dialog asking me to enter a registration code.  At the time I was installing the Media Center SDK, I was not connected to the internet, so I was not able to obtain a registration code.  Instead I just dismissed the dialog and made a mental note to register Visual C# Express the next time I was online.

    Later on, I was connected to the internet, so I launched Visual C# Express and registered it.  Then, I attempted to create a new Media Center project.  However, when I opened the New Project dialog, I did not see any available project templates for Media Center projects.

    After looking into this scenario in more detail, I realized that the custom action to register the Media Center project templates had not executed correctly because I dismissed the registration dialog that popped up during SDK setup.  I was able to fix my system by going to the Add/Remove Programs control panel (also known as Programs and Features on Windows Vista) and repairing the Media Center SDK.

    If you run into a similar issue where you do not see Media Center project templates in the Visual Studio New Project dialog in Visual C# Express or Visual Basic Express after installing the SDK, I suggest making sure that your Visual Studio Express Edition has been registered, and then repair the Media Center SDK.

    Note also that this same issue could affect any setup that installs project templates, item templates or add-ins for use in Visual Studio, so repairing your Visual Studio add-in might be helpful.

  • Aaron Stebner's WebLog

    Private beta for Big Screen Photos version 2 for Windows Vista Media Center

    • 0 Comments

    A little while ago, Niall Ginsbourg posted an introduction and some screenshots for a new version of Big Screen Photos that he is developing using Media Center Markup Language (MCML).  Yesterday, he published a much more in-depth post describing the features of Big Screen Photos version 2, and he also invited anyone interested to email him to get an invitation to the private beta.

    You can view his blog post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!425.entry.

    I got a beta invitation yesterday and have been trying out the application over the past day or so.  I'm really impressed with what Niall has been able to do with MCML and the tools/documentation in the Media Center SDK.  If you have a chance, I encourage you to check out this blog post and contact Niall if you would like to try out a beta version of the application on your Windows Vista Media Center system as well.

  • Aaron Stebner's WebLog

    Mailbag: How to resolve errors in the WEBCA_SetTARGETSITE custom action on Windows Vista

    • 0 Comments

    Question:

    I am using the Visual Studio 2005 web setup project wizard to create an MSI-based installer for my web application.  The application installs fine on Windows XP and Windows Server 2003, but I am running into some issues on Windows Vista.  When I run my MSI from an elevated command prompt, it installs correctly.  However, when I just double-click on the MSI to run it, setup fails.

    I looked in the verbose MSI log file and found that the custom action named WEBCA_SetTARGETSITE is failing with an error stating that it did not have sufficient permissions to complete correctly.  As a result, I tried to use the script named customaction_noimpersonate.js that you described in this blog post to add the NoImpersonate flag to the custom action attributes.

    However, that did not help and I am still not able to install my MSI on Windows Vista without elevating it.  How can I fix my MSI so that it will work in this scenario?

    Answer:

    The custom actions added to the MSI by the Visual Studio 2005 web setup project wizard require administrative privileges in order to complete successfully.  In addition, the WEBCA_SetTARGETSITE is a standard (immediate) custom action, and it is only possible to add the NoImpersonate flag to deferred custom actions.  Also, if you look at the source code for the customaction_noimpersonate.js script, you will see that it only updates deferred custom actions when setting the NoImpersonate flag.

    This means that you must do one of the following in order for this type of MSI to install correctly on Windows Vista:

    • Use a setup bootstrapper that prompts for elevation prior to launching the MSI.  The Visual Studio 2005 setup projects include a setup.exe bootstrapper that will prompt for elevation, or you can write your own setup bootstrapper.
    • Launch the MSI from an elevated command prompt

    Both of these options will ensure that the MSI will have the necessary permissions by the time it tries to execute the WEBCA_SetTARGETSITE immediate custom action.

    One other note - when installing on Windows Vista, the WEBCA_SetTARGETSITE custom action also requires that the IIS6 Management Compatibility item be installed as part of IIS7 on Windows Vista.  You can see this blog post for more information about IIS6 Management Compatibility and how to enable it on Windows Vista.

    <update date="5/18/2007"> Added a note that the Visual Studio 2005 setup bootstrapper can be used to prompt for elevation </update>

     

  • Aaron Stebner's WebLog

    MIX 07 hands-on lab - Understanding Media Center Markup Language (MCML)

    • 0 Comments

    Content for some of the sessions presented at this week's MIX07 conference have been posted on the web.  Included in the online content is a hands-on lab titled Understanding Windows Media Center Markup Language (MCML).  You can download the hands-on lab from https://downloads.eventpoint.com/mix07/hols/LWMC01%20-%20Understanding%20Media%20Center%20Markup%20Language%20(MCML).xps.

    The Understanding MCML hands-on lab includes exercises that cover the following topics:

    Exercise 1: Working with Media Center User Interfaces

    • Creating the Project
    • Working with Layouts
    • Referencing Objects within an MCML File

    Exercise 2: Binding to Objects

    • Adding a Custom Class for Binding
    • Binding MCML Elements to the Custom Class

    Exercise 3: Creating Basic Animations

    • Rotating Graphics
    • Handling Mouse Interaction

    While this lab is helpful in seeing some of the concepts of MCML in action, I would not suggest starting with this lab if you are new to MCML or Media Center development.  If you are getting started, I strongly recommend checking out the Windows Media Center Application Step by Step documentation and source code that is available in the links in this Media Center Sandbox blog post.

Page 1 of 1 (19 items)