Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

    Link to information about MSI script-based custom action error codes 2738 and 2739

    • 25 Comments

    Heath Stewart posted an item on his blog this past week that I wanted to raise awareness about.  In the post, located at http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx, Heath described some potential issues and workarounds for script-based custom action failures in MSI-based setups.

    These error codes appear in an MSI log file when a script-based custom action fails to run correctly, and the error messages look like the following:

    • 2738, Could not access VBScript run time for custom action [2].
    • 2739, Could not access JScript run time for custom action [2].

    A common resolution for this type of error is to re-register the file %windir%\system32\vbscript.dll and/or %windir%\system32\jscript.dll.  However, on Windows Vista this can present problems because if you attempt to re-register these DLLs from a normal user cmd prompt, the registration will be written to HKEY_CURRENT_USER instead of HKEY_CURRENT_MACHINE.

    A key point Heath makes in his blog post that I was not aware of before reading it is that Windows Installer will not load and use scripting engines if they are registered in HKEY_CURRENT_USER (for security reasons that he described in more detail in his post).  Therefore, if you have registered the DLLs on Windows Vista from a normal user cmd prompt, that will not help fix this type of error.

    If you have these scripting engines registered under HKEY_CURRENT_USER, you need to make sure that you remove that registration and re-register them under HKEY_LOCAL_MACHINE.  You can use the following steps to unregister them from HKEY_CURRENT_USER:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. To unregister the VBScript engine, run this command:  reg delete "HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
    3. To unregister the VBScript engine on a 64-bit OS, run this command:  reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
    4. To unregister the JScript engine, run this command: reg delete "HKCU\SOFTWARE\Classes\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f
    5. To unregister the JScript engine on a 64-bit OS, run this command: reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f

    One last note - if you are a setup developer reading this post, I encourage you to read this post by Rob Mensching where he explains reasons why using script-based custom actions in an MSI can lead to bad results and should be avoided if at all possible.

    <update date="7/29/2009"> Added steps to unregister the VBScript and JScript engines on 64-bit OS's. </update>

     

  • Aaron Stebner's WebLog

    How to fix .NET Framework install errors that ask for tmpXXXX.tmp

    • 23 Comments

    I have heard from several customers who have had problems trying to repair the .NET Framework or install a .NET Framework service pack and saw an error dialog asking for the source location for tmpXXXX.tmp.  I wanted to try to explain why this can happen and also describe a way that I normally recommend to fix this issue.

    Why does this happen?

    The .NET Framework hotfix setup wrapper creates patch files on the fly in the %temp% directory that are named tmpXXXX.tmp (where XXXX is a randomly generated ending), and then deletes the file after applying the patch.  When attempting to install any .NET Framework hotfix or repair the .NET Framework, Windows Installer will perform a component health check.  If any of the components installed as part of the patch have been damaged/deleted, Windows Installer will trigger a repair and search for the files in the original install location.  In this case, the original install location does not exist because it was deleted from %temp%.

    How can I workaround this?

    I posted a complete set of steps that you can use to clean up your system and reinstall the .NET Framework at http://blogs.msdn.com/b/astebner/archive/2008/03/07/8108332.aspx. 

    <update date="5/6/2011"> Removing the old instructions in this post and pointing to updated steps. </update>

     

  • Aaron Stebner's WebLog

    How to fix error code 25015 with access denied message during .NET Framework 2.0 setup

    • 11 Comments

    Recently, I saw a post on the MSDN .NET Framework Setup Forum indicating that a customer was having trouble getting the .NET Framework 3.0 to install on his system.

    How to diagnose this error

    The error log for the .NET Framework 3.0 setup (%temp%\dd_dotnetfx3error.txt) showed the following information:

    [11/10/06,11:30:12] Microsoft .NET Framework 2.0: [2] Error: Installation failed for component Microsoft .NET Framework 2.0. MSI returned error code 1603
    [11/10/06,11:30:36] WapUI: [2] DepCheck indicates Microsoft .NET Framework 2.0 is not installed.
    [11/10/06,11:30:37] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.0 was not attempted to be installed.

    Based on this information, I determined that the .NET Framework 2.0 setup was failing.  Then, I used the list of .NET Framework 3.0 setup log files to request additional information from the customer - specifically, the log file named %temp%\dd_netfx_retMSI*.txt.

    When the customer sent me this log file, I found the following error that was causing the .NET Framework 2.0 setup to fail:

    Error 25015.Failed to install assembly 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.VisualBasic.Vsa.dll' because of system error: The process cannot access the file because it is being used by another process.

    In addition, the customer sent me a log file created by Filemon that indicated that setup failed when attempting to open this file with an access denied error.

    How to workaround this error

    Based on the above information, I made an educated guess that there was something wrong with the folder and file permissions on the customer's system.  Fortunately, he was able to use the following steps to resolve this issue and successfully install the .NET Framework 3.0:

    1. Use the SubInAcl tool described at http://blogs.msdn.com/astebner/archive/2006/09/04/739820.aspx to make sure that the Administrators group and the SYSTEM account both have permissions to folders under %windir% and registry hives under HKLM
    2. Run the cleanup tool described at http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx to make sure any remnants of the .NET Framework 2.0 have been removed from the system
    3. Try again to install the .NET Framework 2.0 (or in this case, try again to install the .NET Framework 3.0, which will try to install the .NET Framework 2.0 behind the scenes)

    Important caveats about error code 25015

    Please note - error code 25015 during .NET Framework 2.0 setup is a catch-all for many types of errors.  Therefore, the solution described in this post will likely only work if you see error code 25015 and the system error message states that the file is being used by another process and/or access is denied.  Not all instances of the 25015 error code will be resolvable with these steps.

    In coding terms, error code 25015 is the else block at the end of a big if statement.  As a result, it ends up being the error code displayed after .NET Framework 2.0 setup verifies that the error is not caused by any other known fusion return code (which are defined in the file corerror.h that ships in the .NET Framework 2.0 SDK).

    The customer who encountered this problem also posted this item on his blog describing this troubleshooting experience in case you are interested in reading that as well.  Hopefully this will be useful if you run into this type of error while installing the .NET Framework 2.0 on your system.

  • Aaron Stebner's WebLog

    Repairing the .NET Framework 2.0 SP2 or 3.0 SP2 MSI from Add/Remove Programs does not work

    • 28 Comments

    Last week, I posted a set of command line parameters that can be used to repair or uninstall the .NET Framework 2.0 SP2 and 3.0 SP2.  When I was working on that blog post, I noticed a behavior change that is new in 2.0 SP2 setup and 3.0 SP2 setup that affects the repair scenarios for these products on Windows XP and Windows Server 2003, so I wanted to describe the issue and how to work around it.

    Description of the issue

    There was a change made in the MSI-based installers for the .NET Framework 2.0 SP2 and 3.0 SP2 that causes the default repair that happens when you use the Add/Remove Programs entry for these products to not actually repair anything.  For example, if you end up with an out-of-date version of c:\windows\system32\mscoree.dll or if any of the files or registry values in the .NET Framework 2.0 SP2 or 3.0 SP2 are missing entirely, the repair from Add/Remove Programs will not restore the files or registry keys.

    Because this issue only affects the MSI-based installers for 2.0 SP2 and 3.0 SP2, you will only encounter this issue on Windows XP and Windows Server 2003.  On Windows Vista and Windows Server 2008, the .NET Framework 2.0 SP2 and 3.0 SP2 are installed as OS update packages instead of as MSIs.

    How to work around the issue

    If you need to repair the MSI-based version of the .NET Framework 2.0 SP2 or 3.0 SP2 on Windows XP or Windows Server 2003, you must run the following command lines instead of using the repair option from Add/Remove Programs:

    .NET Framework 2.0 SP2 - silent repair

    msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qb

    .NET Framework 3.0 SP2 - silent repair

    msiexec /fpecmsu {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REINSTALL=ALL /l*v %temp%\netfx30sp2_repair_log.txt /qb

    Behind-the-scenes details if you are interested

    There is a difference in the command line switches being passed in to trigger the repair of 2.0 SP2 and 3.0 SP2 compared to 2.0 SP1 and 3.0 SP1.  Here are a couple of specific examples:

    .NET Framework 2.0 SP2 - silent repair

    msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qn

    .NET Framework 2.0 SP1 - silent repair

    msiexec /i {B508B3F1-A24A-32C0-B310-85786919EF28} /l*v %temp%\netfx20sp1_repair_log.txt /qn

    The reason that these command lines need to be different (aside from the product codes changing between SP1 and SP2) is that the REINSTALL=ALL property no longer gets set by default in the MSI-based .NET Framework 2.0 SP2 or 3.0 SP2 repair processes.  There is a custom action in .NET Framework 2.0 SP1, 2.0 SP2, 3.0 SP1 and 3.0 SP2 setup that sets the REINSTALL=ALL property during repair scenarios.  However, the condition for that custom action was changed in 2.0 SP2 and 3.0 SP2 setup such that it will never evaluate to true, and the REINSTALL=ALL property no longer gets automatically set.  As a result, you have to manually pass in the REINSTALL=ALL property in order to perform a full repair of the .NET Framework 2.0 SP2 and 3.0 SP2.

  • Aaron Stebner's WebLog

    How to perform a silent repair and uninstall of the .NET Framework 3.5 and 3.5 SP1

    • 5 Comments

    Question:

    I have seen your blog posts that describe how to silently repair and uninstall the following versions of the .NET Framework:

    How can I perform a silent repair and uninstall for the .NET Framework 3.5 SP1?

    Answer:

    The following list provides example command lines that can be used to repair and uninstall the MSI-based .NET Framework 3.5 SP1 package after it has been installed on the system.  The silent option will perform the repair/uninstall with no UI displayed to the user.  The unattended option will perform the repair/uninstall with only a progress dialog, but with no user interaction required.

    .NET Framework 3.5 SP1 - silent repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /norestart

    .NET Framework 3.5 SP1 - unattended repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /norestart

    .NET Framework 3.5 SP1 - silent uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /uninstall /norestart

    .NET Framework 3.5 SP1 - unattended uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /uninstall /norestart

    Important notes about repair scenarios:

    • The .NET Framework 3.5.1 (an updated version of the .NET Framework 3.5 SP1) is installed as an OS component on Windows 7.  As a result, the MSI-based versions of 3.5 or 3.5 SP1 cannot be installed on these OS's, and the above command lines will not work on these OS's.  If you need to repair the .NET Framework 3.5.1 on Windows 7, you will need to use instructions like the ones in this blog post.
    • On Windows XP and Windows Server 2003, the .NET Framework 3.5 SP1 repair process will chain the repair processes for the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2, so there is no need to use separate steps to repair those products if you are going to repair the .NET Framework 3.5 SP1 on these OS's.
    • On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 are OS components, and the repair of the .NET Framework 3.5 or 3.5 SP1 will not repair these OS components.  If you need to repair the .NET Framework 2.0 and/or 3.0 on Windows Vista or Windows Server 2008, you will need to use instructions like the ones in this blog post.

    Important note about uninstall scenarios:

    • The .NET Framework 3.5 SP1 uninstall process will only uninstall the .NET Framework 3.5 SP1 MSI.  It will not uninstall the .NET Framework 2.0 SP2 or the .NET Framework 3.0 SP2 products because there may be other applications on the system that rely on those versions of the .NET Framework.  If you want to uninstall the .NET Framework 2.0 SP2 and 3.0 SP2, you must uninstall in the following order:  .NET Framework 3.5 SP1, then .NET Framework 3.0 SP2 then .NET Framework 2.0 SP2.

    Other important notes:

    • Log files will be created for the .NET Framework 3.5 SP1 repair and uninstall just like for the initial install.  You can find a list of .NET Framework 3.5 and 3.5 SP1 log files in this blog post.
    • When calling .NET Framework 3.5 SP1 setup in silent or unattended mode, you should check the return code from the setup.exe process in order to determine success or failure.  Return code 0 means that the setup was successful, return code 3010 means that the setup was successful but a reboot is required to complete the setup and any other return code means that there was an error.  If you receive a 3010 return code, the reboot is required before all .NET Framework functionality will be expected to function correctly on the user's system, so it cannot be deferred forever.
    • The above examples only demonstrate the command lines used for repair and uninstall.  For install scenarios, I recommend reviewing the content in the .NET Framework 3.5 deployment guides as well as the steps for creating administrative install points.
  • Aaron Stebner's WebLog

    Error loading mscorwks.dll that may appear while trying to install a .NET Framework hotfix

    • 23 Comments

    I was working with a couple of different customers today who saw a .NET Framework initialization error dialog that says that setup failed to load mscorwks.dll appear when trying to install ASP.NET hotfix KB886903.  The exact error dialog looks like this.

    It turns out this is being caused by a race condition that can happen when trying to install one .NET Framework or ASP.NET hotfix immediately after installing another .NET Framework or ASP.NET hotfix.  There is special logic in the .NET Framework hotfix and service pack setup wrapper that is used to rerun ngen.exe to regenerate native images for some of the .NET Framework binaries.  This process is done when installing the .NET Framework, but the native images are invalidated by any changes made to them (such as when they are patched by a service pack).  The process that reruns ngen.exe is separate from the original hotfix installation and in some cases it is scheduled to occur after the next reboot (to account for files in use and things like that).

    In both of the scenarios I saw, the customers had installed .NET Framework 1.1 SP1 via Windows Update and then were required to reboot.  After the reboot, the background process was launched by an entry in the RunOnce registry hive and at approximately the same time the setup for the ASP.NET hotfix was launched by Windows Update or Automatic Update.  In some cases, these two processes try to access some of the same resources at the same time and it ends up resulting in an error message.

    The end result of this error message is that one or more of the native images fails to be recreated.  This does not cause the .NET Framework to fail in any way, but since ngen.exe is designed to improve performance for the binaries in question, it can lead to performance degradation for the .NET Framework.

    If you hit this error and want to make sure that the files will have correct native images generated for them by ngen.exe you can reapply the service pack to cause these commands to be rerun.

     

  • Aaron Stebner's WebLog

    Mailbag: How to set the NoImpersonate flag for a custom action in Visual Studio 2005

    • 69 Comments

    Question:

    I have built an installer using the Visual Studio 2005 setup project wizard.  It installs correctly on Windows XP but fails on Windows Vista.  I investigated and found that the failure on Windows Vista is caused by a custom action that fails with an access denied error.  However, I am running the setup with elevated privileges in Windows Vista.  How can I fix my setup so it will work correctly on Windows Vista?

    Answer:

    As Robert Flaming described in this blog post, it is necessary to set the NoImpersonate flag for custom actions that modify the system in Windows Vista.  This was an uninforced architectural intent that is now enforced in Windows Vista.

    Unfortunately, there is not a way to directly set this flag for a custom action in the UI for the setup project in the Visual Studio IDE.  In Visual Studio 2005, you can use a post-build step that modifies the MSI to set this bit using a strategy previously described in this blog post.

    You can use the following steps to set the NoImpersonate bit in a Visual Studio 2005 setup project:

    1. Download the sample script and extract the contents to the directory that contains the Visual Studio project you are working on
    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

    <update date="1/22/2007"> Updated command line in step 7.  The variable I had specified previously was incorrect.  It actually needs to be spelled wrong using "ouput" instead of "output" in the $(BuiltOuputPath) variable </update>

    <update date="3/18/2009"> Fixed broken link to the sample script. </update>

     

  • Aaron Stebner's WebLog

    MSI tools

    • 19 Comments

    There are quite a few good tools and resources for MSI setup creation and debugging in the Platform SDK.  I figured I'd list the ones I use most often, and I would really like to know what everyone else uses and if there are any holes in that you've found where new tools are needed.....

    Descriptions for all of the tools in the PSDK can all be found at http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_development_tools.asp by the way....

    Stuff I used every day when I worked on the VS and .NET Framework setup team:

    • MSI.chm - the help file for Windows Installer, this is indispensible for looking up error codes, command line parameter permutations, descriptions of fields in the various tables, bitmask descriptions for things like file and component attributes, etc.  There is one thing that drives me crazy though - trying to figure out the meaning of the different custom action attributes to determine exactly what you should expect for any given CA
    • Orca - graphical viewer for the contents of an MSI, I have this installed on all of my machines, even on my new team.  It can be scary to open up and look at random setups though - I've seen all sorts of horror stories over the past few years - both within MS and elsewhere.

    Stuff I found very useful though I didn't need to use them daily:

    • MSIZap - removes the remnants of a failed install/uninstall from your machine.  I strongly recommend using this only as a last resort - most of the times I use this it is because someone installed a daily build or an early beta of one of our products that had some kind of uninstall bug.
    • MSIVal2 - performs internal consistency validation for MSI tables, this can be useful for catching MSI authoring errors that may not always manifest themselves in the form of a failure and roll-back of your setup. 
    • MSITran - lets you easily take the delta between 2 MSI packages and create a transform containing the differences.  What I've used this for in the past is to modify some of the UI and add/remove launch conditions as a one-off for customers who weren't familiar with the internal workings of an MSI in Orca.

    There is a log analyzer tool on the site (wilogutl) that can help narrow down failures in your setup - it can be especially useful for verbose logs for large products such as Visual Studio (those logs are 40+ megs....)  I usually take shortcuts before I use that tool though, most of the errors can be found by searching for “return value 3“ in your MSI verbose log file.  This doesn't work for non-English products because that string is translated, and it also relies on the setup author to log useful information for things like custom actions that may end up failing.

    The other tools on the PSDK site sound like they'd be very useful as well but I don't have first-hand experience with them.

    What other stuff is out there that folks are using?  What stuff is missing that needs to be written in this space?  Thoughts?

     

  • Aaron Stebner's WebLog

    How to configure the Visual Studio 2005 IDE to use custom XSD files for IntelliSense

    • 18 Comments

    I've finally gotten some time to experiment with some of the features of the Visual Studio 2005 IDE (as you can see from my post last week about how to populate the Add References dialog).  I wanted to share a couple of tricks I discovered about using Visual Studio 2005 to create and edit XML that I found pretty useful, but for which the documentation was either vague or lacking (in my opinion).

    I have been trying to install or register an XSD file so that Visual Studio 2005 can find it and automatically use it when I am editing specific types of XML documents in the IDE.  Initially, I expected that there would be a simple registry-based solution to associate new XSDs like there is for populating folders with assemblies into the Add References dialog.  After some research, I couldn't find a way to do this so I began looking for what kind of other options are available.

    I found an MSDN document that describes what is new in code editing in VS 2005.  This document describes some of the features of the new XML editor in the IDE.  I was specifically interested in "Flexible schema association" and "XSD-based IntelliSense" so I tried to find more information about these topics.  I ended up finding this topic about the schema cache.  Based on this document, I was able to get the following mechanisms to work to cause Visual Studio 2005 to recognize my XSD:

    Option 1 - copy the XSD into the Visual Studio 2005 schemas directory

    • Place a copy of the XSD file into the folder %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas

    I also decided to associate a file extension for my file type with Visual Studio 2005.  If you are using a well-known file extension you may not need to use these additional steps.

    • Go to the Tools menu and choose Options
    • If you are using a Visual Studio 2005 Express Edition, check the box in the lower left corner named Show all settings
    • Expand the Text Editor tree item and choose File Extension
    • Type the name of your extension, choose XML Editor in the dropdown and click OK

    This option worked fine for me, but required that I copy my XSD into the Visual Studio 2005 schemas directory.

    Option 2 - modify the Visual Studio 2005 schemas catalog.xml file

    • Edit %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas\catalog.xml and add a new section that looks like the following:
      <Schema href="(path to your XSD file)" targetNamespace="(your schema namespace)" />

    Because I also wanted to associate a file extension for my file type with Visual Studio 2005, I added this line to catalog.xml as well.  If you are using a well-known file extension you may not need to add this additional entry.

    <Association extension="(your extension)" schema="(path to your XSD file)"/>

    This option allowed me to store my XSD file in whatever location I wanted to, but had the drawback of requiring me to edit one of the configuration files that ships with Visual Studio 2005.

    Option 3 - add a new XML file to the Visual Studio 2005 schemas directory

    I could not find this option documented on MSDN, but I discovered it by asking some questions of the team that developed the XML Editor features in Visual Studio 2005.  I wanted to be able to register my schema without requiring my XSD file to be in the central Visual Studio 2005 schemas directory and without requiring any modifications to the catalog.xml file that shipped with Visual Studio 2005.  I found out that Visual Studio 2005 will parse files named *.xml in %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas and look for additional schema registration, even if the file is not named catalog.xml.

    So in this option, I did the following:

    • Create a new file named myschema.xml
    • Add the following lines to the XML file:
      <Schema href="(path to your XSD file)" targetNamespace="(your schema namespace)" />
      <Association extension="(your extension)" schema="(path to your XSD file)"/>
    • Copy the file to %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas

    This option allowed me to store my XSD file in whatever location I wanted to, and it did not require me to to edit one of the configuration files that ships with Visual Studio 2005.  This is the option I ended up choosing for my scenario.

    Additional notes

    A few other notes about this process that I found while trying to figure this out:

    • The MSDN documentation claims that Visual Studio monitors the %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas directory when the IDE is running and will dynamically update if any changes are made.  I may have been doing something wrong, but I could not get that feature to work and I had to close and reopen the IDE in order to see the changes I made to the contents of the Schemas directory get picked up and used by Visual Studio
    • The MSDN documentation also claims you can add a new <catalog> entry in %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas\catalog.xml in order to add new directories that Visual Studio will look in to try to find XSD files.  I could not get that functionality to work either, but I feel that option 3 listed above is cleaner anyways because you don't have to edit a pre-existing XML file (which makes it easier to write a setup that will register a schema with Visual Studio because Windows Installer does not have native support for editing XML files and you would have to write a custom action to do this)

    Also, the coolest thing I discovered while looking into this is that any annotations in your XSD will be picked up and used by Visual Studio 2005 as IntelliSense comments.  That means when you type an open angle bracket to start a tag, and you get the dropdown with a list of applicable tags, when you give focus to each tag VS will display tooltips for the tag based on the annotations in the XSD file.  This is mentioned very briefly in this MSDN article, but I found this to be extremely useful - once I found out that I could easily enable this feature, I didn't need to Alt+Tab back and forth to the help documentation for my schema nearly as often.  Very cool!!

     

  • Aaron Stebner's WebLog

    Error installing .NET Framework on Windows XP SP2 caused by Data Execution Prevention (DEP)

    • 39 Comments

    Note - the issue described in this blog post was originally presented as an issue on Windows XP SP2.  However, it can also affect .NET Framework 1.0 and 1.1 installation on any OS released after the .NET Framework 1.0 and 1.1 shipped - specifically, I have seen reports of this issue on Windows Vista.  The steps listed here are applicable to this type of install failure on other newer OS's like Windows Vista and not just Windows XP SP2. 

    As I was researching the bug in .NET Framework 1.0 and 1.1 that is related to regional language settings on Windows XP SP2 (see this blog post for full details), I discovered an additional issue introduced in Windows XP SP2 that can cause .NET Framework 1.0 or 1.1 setup to fail.  Just like the other bugs, this one causes .NET Framework setup to report an error while registering System.EnterpriseServices.dll.  In the case of .NET Framework service pack setup, it will cause an error to occur while extracting the service pack to a temporary location before even starting setup.

    Windows XP SP2 introduced a new security feature known as Data Execution Prevention (or DEP for short).  There is a good article introducing DEP here.  If a computer running XP SP2 has hardware that supports DEP and DEP is enabled in boot.ini, installation of the .NET Framework will fail while trying to register System.EnterpriseServices.dll (which happens to be the first time that managed code gets run during setup and therefore is the first time the bug is hit).  Also, installation of .NET Framework service packs will fail while trying to extract the service pack setup to a temporary location because the .NET Framework service pack wrapper is written in managed code.

    The DEP feature was introduced after the .NET Framework 1.0 and 1.1 shipped and unfortunately the .NET Framework is not compatible with DEP without applying a service pack.  Like the language settings bug, this DEP compatibility bug has been fixed in the .NET Framework 1.0 SP3 and 1.1 SP1.  However, this bug causes the initial installation of the .NET Framework to fail and rollback, and you cannot install the service pack without first getting the product installed (unless you use a method like I describe here, which will work but is not "officially" supported).

    If you are running into this bug on your Windows Vista, Windows Server 2008 or Windows 7 computer, you can use steps like the ones in this blog post to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed. 

    If you are running into this bug on your Windows XP SP2 computer, you can use the following steps to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed:

    1. From the Start menu, type sysdm.cpl in the Run box or go to Control Panel and choose the System item
    2. Click the Advanced tab
    3. Click the Settings button in the Startup and Recovery section of this tab
    4. In the Default operating system dropdown, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=Optin to /NoExecute=AlwaysOff.  This will update the settings in boot.ini on the computer
    5. Click OK
    6. Restart
    7. Install the .NET Framework 1.0 or 1.1
    8. Install .NET Framework 1.0 SP3 or 1.1 SP1
    9. Return to the System control panel, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=AlwaysOff back to /NoExecute=Optin

    For reference, here is what the Startup and Recovery item in the Advanced tab of the System control panel looks like (this is the screen you will see in step 4 of the instructions above):

    System control panel Advanced tab

    <update date="4/17/2008"> Added a note indicating that the issue in this post can affect the .NET Framework 1.0 and 1.1 setup on Windows Vista and not just Windows XP SP2 </update>

    <update date="6/23/2009"> Fixed broken image link, and added a link to a separate blog post that provides steps for turning DEP on and off on Windows Vista and higher. </update>

     

  • Aaron Stebner's WebLog

    Draft version of a new .NET Framework setup verification tool available for download

    • 27 Comments

    A while ago, I published a .NET Framework setup verification tool that can be run to provide a sanity check of the install state of the .NET Framework 1.0, 1.1 and 2.0 on a system.  However, there are some limitations in that tool:

    • It does not support validating the .NET Framework 2.0 on Windows Vista
    • It does not support the .NET Framework 2.0 SP1, the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the .NET Framework 3.5
    • It only checks file version information and does not check registry values created by setup
    • It depends on the setup technology used to install the product in the first place (Windows Installer or OS install technologies) and requires you to select an OS-specific version of the product in the UI in order to get accurate verification results
    • It reports misleading warnings if hotfixes for the .NET Framework are installed on the system

    As a result, I decided to create a new verification tool, and I have an initial version that I think is ready for more people to use.  I wanted to post some information about the tool so that folks can try it out to verify the installation state of the various versions of the .NET Framework on their systems.

    Where to download the new verification tool

    I have a draft version of a new verification tool that can be used to verify all versions of the .NET Framework (1.0, 1.1, 2.0, 2.0 SP1, 3.0, 3.0 SP1 and 3.5) on any supported OS and processor architecture.  You can find information about the tool and download it from this location:

    http://blogs.msdn.com/astebner/pages/8999004.aspx

    The UI for the tool is straightforward - it contains a drop-down list box that lets you choose the version of the .NET Framework that you would like to verify and a Verify Now button to initiate the verification process for the chosen product.  After verification completes, it will display results for the chosen product and allow you to select additional products to verify.

    I have been testing this new version on several systems that I have access to, but there are likely to still be issues where the tool falsely reports errors or misses some error cases.  Please let me know if you see any issues while using this tool by posting comments on this blog post or by contacting me directly.  If possible, please include information about your scenario and copies of the log files that I describe below so I can continue to make this tool better in the future.

    How to run the tool in silent mode

    This verification tool supports running in silent mode if you would like to automate the verification process.  To run in silent mode, you need to download the verification tool .zip file, extract the file netfx_setupverifier.exe from the .zip file, and then run it using syntax like the following:

    netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p <name of product to verify>"

    The value that you pass with the /p switch to replace <name of product to verify> in this example must exactly match one of the products listed in the file setupverifier.ini that is included in the self-extracting package for the verification tool.

    Currently, the verification tool includes the following product names that can be passed in using the /p switch:

    • .NET Framework 1.0
    • .NET Framework 1.1
    • .NET Framework 2.0
    • .NET Framework 2.0 SP1
    • .NET Framework 2.0 SP2
    • .NET Framework 3.0
    • .NET Framework 3.0 SP1
    • .NET Framework 3.0 SP2
    • .NET Framework 3.5
    • .NET Framework 3.5 SP1

    For example, if you would like to run the tool in silent mode and verify the install state of the .NET Framework 2.0, you would use a command line like the following:

    netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 2.0"

    The verification tool returns the following exit codes:

    • 0 - cleanup completed successfully for the specified product
    • 1 - the required file setupverifier.ini was not found in the same path as setupverifier.exe
    • 2 - a product name was passed in that cannot be verified because it does not support installing on the OS that the tool is running on
    • 3 - a product name was passed in that does not exist in setupverifier.ini
    • 100 - verification failed for the specified product
    • 1602 - verification was canceled

    Logging

    This verification tool creates 2 log files by default that can be used to determine what actions the tool is taking and what errors it encounters while verifying a product.  The 2 log files are listed below, and they are created in the %temp% directory by default.  Note that you can find the %temp% directory by clicking on the Windows start menu, choosing Run, typing %temp% and clicking OK to open the directory in Windows Explorer.

    • %temp%\setupverifier_main_*.txt - this log contains information about all actions taken during a verification tool session; it will include information about each resource that the tool attempts to verify for a chosen product and whether or not that resource was found on the system; this log tends to be fairly long, so errors will be logged with the prefix ****ERROR**** to make it easy to search and find them
    • %temp%\setupverifier_errors_*.txt - this log only contains information about any errors found during verification of a chosen product

    A new pair of log files will be created each time the verification tool is launched.  The date and time the tool is launched will be appended to the end of the log file names by default in place of the * in the names listed above.  If you want to control the exact names used for the log files, you can use the following command line parameters:

    • /l <filename> - specifies a name to replace the default value of setupverifier_main_*.txt for the main activity log for the verification tool
    • /e <filename> - specifies a name to replace the default value of setupverifier_errors_*.txt for the error log for the verification tool

    For example, the following command line will allow you to specify non-default names for both log files:

    netfx_setupverifier.exe /q:a /c:"setupverifier.exe /l %temp%\my_main_log.txt /e %temp%\my_error_log.txt"

    <update date="9/2/2009"> Fixed broken link to the verification tool. </update>

     

  • Aaron Stebner's WebLog

    How to fix Media Center remote control if it breaks when installing IR update rollup

    • 15 Comments

    We recently released Update Rollup 1 for eHome Infrared Receivers for Windows XP Media Center Edition 2005.  There are some fixes in this package that may cause your Media Center remote control to stop working.  Specifically, we previously allowed channels 1-8 to broadcast IR signals on, and with this package installed the remote is limited to channels 1-4.  If your remote is broadcasting on channels 5-8, here is what you can do to change to a channel in the 1-4 range to allow it to start working again:

    • Hold down the “DVD Menu” button and the “1” key at the same time for 5 seconds (or the "2", "3" or "4" key if you want to have the remote broadcast on one of the other supported channels instead
    • After 5 seconds, the LED on the IR receiver should blink twice, and your remote should work correctly again.

     

  • Aaron Stebner's WebLog

    Final versions of Windows 8, .NET Framework 4.5 and Visual Studio 2012 now available for download

    • 13 Comments

    As announced on the Windows 8 app developer blog, Somasegar’s blog and Jason Zander’s blog, the final versions of Windows 8, the .NET Framework 4.5 and Visual Studio 2012 are now available for developers to download. Here is some information to help you get started installing and using these releases.

    Download links

    Here are links to help you get started downloading Windows 8:

    Here are links to help you get started downloading the .NET Framework 4.5 and Visual Studio 2012:

    Documentation links

    Here are links to help you get started using Windows 8:

    Here are links to help you get started using the .NET Framework 4.5 and Visual Studio 2012:

    Important note about installing Visual Studio 2012 on Windows 8

    The .NET Framework 4.5 is included as a part of Windows 8, and Visual Studio 2012 requires the .NET Framework 4.5 as a prerequisite.  You can only install the final version of Visual Studio 2012 on the final version of Windows 8 because the final version of Windows 8 is the only one that includes the final version of the .NET Framework 4.5.  This means you cannot install pre-release versions of Visual Studio 2012 on the final version of Windows 8, and you also cannot install the final version of Visual Studio 2012 on pre-release versions of Windows 8.

    Notes about XNA Game Studio and Windows Phone development

    If you plan to develop games and applications using XNA Game Studio and/or the Windows Phone SDK, there are a couple of important notes to keep in mind:

    1. XNA Game Studio and the Windows Phone SDK 7.1 both work with Visual Studio 2010, not Visual Studio 2012. You will not see any XNA Game Studio or Windows Phone project templates or other functionality for these products in Visual Studio 2012 if you install both products on the same computer. You can safely install Visual Studio 2010 and Visual Studio 2012 side-by-side on the same computer though.
    2. If you try to install XNA Game Studio or the Windows Phone SDK 7.1 on Windows 8, setup may fail. If it does, you can use the workaround at http://blogs.msdn.com/b/astebner/archive/2012/02/29/10274694.aspx to solve the setup failure.
  • Aaron Stebner's WebLog

    How to create an administrative install point for the .NET Framework 4

    • 20 Comments

    I previously wrote a blog post listing the silent install, repair and uninstall command line parameters for the .NET Framework 4.  Since then, I’ve gotten questions from a few folks who are trying to deploy the .NET Framework 4 in ways that require them to run the MSIs directly instead of using the setup executable (for example, via Group Policy or WMI).  Here are some steps you can use to extract the .NET Framework 4 setup package and create administrative install points for the MSIs that are a part of the .NET Framework 4:

    1. Download the .NET Framework 4 standalone installer and save it to your hard drive
    2. Run the following command to extract the contents of the .NET Framework 4 installer:  dotNetFx40_Full_x86_x64.exe /x:c:\dotnetfx4
    3. Run the following command to create an administrative install point for the .NET Framework 4 core x86:  msiexec /a c:\dotnetfx4\netfx_Core_x86.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_core_x86
    4. Run the following command to create an administrative install point for the .NET Framework 4 core x64:  msiexec /a c:\dotnetfx4\netfx_Core_x64.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_core_x64
    5. Run the following command to create an administrative install point for the .NET Framework 4 extended x86:  msiexec /a c:\dotnetfx4\netfx_Extended_x86.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_extended_x86
    6. Run the following command to create an administrative install point for the .NET Framework 4 extended x64:  msiexec /a c:\dotnetfx4\netfx_Extended_x64.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_extended_x64

    Once you’ve created the administrative install points described above, you should be able to install the MSIs in the administrative install point folders directly or use steps like the ones previously published for the .NET Framework 2.0 to create Group Policy objects to deploy the .NET Framework 4.  When doing this, you will need to apply an additional transform to each of the MSI files to prevent the installation from blocking you and telling you to run setup.exe instead.  I have created an example transform that you can download from here for this scenario.  The transform changes the condition for CA_BlockDirectInstall to False so it will not be run during the installation process.

    Important note: when creating administrative install points and installing the .NET Framework 4 MSIs directly, it is your responsibility to install all of the prerequisites for these MSIs onto the target computer prior to attempting to install the MSIs.  This includes the OS prerequisites listed here plus the OS update (.msu) files that are packaged with the .NET Framework 4 if you are running setup on Windows Vista or higher.  If you do not install these prerequisites, then installing the MSIs will fail.

    <update date="6/17/2010"> Added a link to a transform that can be used to bypass the custom actions in the .NET Framework 4 MSIs that prevent installing the MSI drectly and tell you to run setup.exe instead. </update>

     

  • Aaron Stebner's WebLog

    Final version of Windows Phone SDK 7.1 now available for download

    • 8 Comments

    As announced on the Windows Phone Developer Blog and on the App Hub web site, the final version of the Windows Phone SDK 7.1 (formerly named the Windows Phone Developer Tools, and which includes the XNA Game Studio 4.0 Refresh as well) was released for download today.

    Getting Started links

    Here are links to help you get started installing and using the English version of the Windows Phone SDK 7.1:

    Here are download links for non-English versions of the Windows Phone SDK 7.1:

    Documentation links

    Here are some links to documentation to help you get started using the Windows Phone SDK 7.1:

    Support links

    Here are some links if you run into questions or issues with the Windows Phone SDK 7.1:

    How to install

    Here are steps you can use to install the Windows Phone SDK 7.1:

    1. If you have any Visual Studio 2010 editions (such as Professional, Ultimate, C# Express, etc) installed on your computer, you will need to install Visual Studio 2010 SP1 first.
    2. If you have the WPDT 7.1 Beta, the Windows Phone SDK 7.1 Beta 2 or the Windows Phone SDK 7.1 RC installed, you must uninstall it before installing the Windows Phone SDK 7.1. To uninstall it, you can go to the Programs and Features control panel and uninstall the item named Windows Phone SDK 7.1 (RC) - ENU and that will automatically uninstall all of the beta components that you need to remove before proceeding to install the Windows Phone SDK 7.1.

      Note: If you have the original Windows Phone 7 version of WPDT and/or XNA Game Studio 4.0 installed, you do not need to uninstall them. The Windows Phone SDK 7.1 and the XNA Game Studio 4.0 Refresh will automatically uninstall the previous version for you behind the scenes. You only need to uninstall previous 7.1 beta builds.

    3. After updating any existing editions of VS 2010 to SP1 and uninstalling any previous beta versions of the Windows Phone SDK that you previously installed, you can proceed with installing the Windows Phone SDK 7.1.

    If you encounter Windows Phone SDK 7.1 setup failures

    If you run into an installation or uninstallation failure for the Windows Phone SDK 7.1, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.

    Once you have gathered your setup log files, you can upload them to a file server of your choice (such as http://skydrive.live.com), and post a link to the log files in the forums to get additional support.

    If you run into uninstallation issues with any release of the Windows Phone SDK or XNA Game Studio, you can use the cleanup tool described at http://blogs.msdn.com/astebner/pages/9544320.aspx to remove the Windows Phone SDK or XNA Game Studio.

  • Aaron Stebner's WebLog

    How to install the Windows Phone Developer Tools on Windows Server 2008

    • 65 Comments

    The Windows Phone Developer Tools are not officially supported on operating systems other than Windows Vista or Windows 7.  In between the CTP and the CTP Refresh, a block was added to setup to prevent installing on Windows Server 2008 to help enforce this support limitation.  I’ve heard from some folks who were using the original CTP on Windows Server 2008 who cannot move forward to the CTP Refresh or the final release because of this block.

    There is a way you can work around the Windows Server 2008 setup block if needed.  Please note that this is not officially supported, so if you try these steps, you are doing so at your own risk.

    1. Download the Windows Phone Developer Tools web bootstrapper and save it to your hard drive
    2. Extract the contents of the setup package by running vm_web.exe /x and choosing a path to extract to
    3. Go to the folder you extracted to in step 2 and open the file baseline.dat in notepad
    4. Look for the section named [gencomp7788]

      Note - you have to change this exact section - this is the one that controls the OS version blocking behavior in Windows Phone Developer Tools setup.
       
    5. Change the value InstallOnLHS from 1 to 0
    6. Change the value InstallOnWin7Server from 1 to 0
    7. Save and close baseline.dat
    8. Run setup.exe /web from the folder you extracted to in step 2

      Note - please make sure that you include the /web command line parameter in step 8.  If you don't, setup will not attempt to download the packages it needs to install, and it will fail to install correctly as a result.

    <update date="9/17/2010"> Added an emphasis on steps 4 and 8 - setup will fail if you don't pass in the /web switch when using these steps.  Also updated the steps for the final RTW build of Windows Phone Developer Tools. </update>

     

  • Aaron Stebner's WebLog

    Why does Windows Installer start installing some other product when I try to install or use a different MSI-based product?

    • 17 Comments
    I received a question in response to my blog entry about reverse engineering setup - basically the .NET Framework setup is being triggered while trying to install an unrelated product (in this case Drive Image 7).  The details of this particular interation may not be interesting to everyone, but I think the underlying issue of why Windows Installer would start installing some other product when you try to install or use an unrelated product would make an interesting topic for discussion.  I'm going to try to explain the underlying issue and also touch on some specific points related to the .NET Framework setup and how to fix it in particular.
     
    Background
     
    This is a feature of Windows Installer called resiliency.  Basically, what happens is that in various type of install or product usage scenarios, Windows Installer will query some or all of the products installed on the machine to determine if the features are correctly installed.  If these queries return any kind of error code, Windows Installer will try to trigger a repair for the feature and product in question.  This will appear as a small installation dialog with the name of the product in the title bar, and normally the text of the dialog will say something like "Configuring <product name>.  Please wait...." and it will contain a progress bar and a cancel button.
     
    In some resiliency repair scenarios, you will never be prompted for a source location.  Windows Installer caches the original location that a product is installed from, and if it can be accessed during a repair it will seamlessly connect to that location and use the files from there.  However, when this type of repair is triggered for the .NET Framework, another dialog will appear stating that Windows Installer could not find the original installation location and asks you to browse to the location of netfx.msi.  This is because it is an IExpress setup package (explained further here), the original source location is no longer valid because IExpress creates a temporary folder in the %temp% folder on a machine, installs from there, and then deletes that folder.  When any repair is triggered by Windows Installer, you will be prompted for the source location of the .NET Framework installation package (netfx.msi).
     
    Locating Netfx.MSI
     
    If you are prompted for the location of netfx.msi, you can extract it from dotnetfx.exe and then browse to that location.  To do this, download dotnetfx.exe or locate it on your local hard drive or a CD.  Then, from a cmd prompt run the following:  dotnetfx.exe /t:c:\temp /c.  You can substitute any folder you want for the "c:\temp" parameter.  Once the extraction is complete, browse to the folder you provided for the /t argument and .NET Framework repair should complete with no further issues.
     
    Identifying the Root Cause
     
    Locating netfx.msi can help get you past the browse dialog that appears, but it does not really help answer the more important question - why is the repair being triggered in the first place?  I have seen many cases where an incorrectly authored MSI setup package has inadvertantly triggered a repair for a product already installed on the machine.  In order to diagnose the root cause of the repair request, I usually do the following:
    1. Go to the Start menu and run eventvwr.exe
    2. Locate the Application event log and click on it to list the events
    3. For each repair that was triggered, there will be an entry in this log with a source named MsiInstaller
    4. Using the GUID of the component or feature that is being repaired, it is usually possible to look at the MSI for the product in question using Orca and determine why Windows Installer thinks it needs to perform a repair
    In most cases, you will need to have a pretty solid level of Windows Installer expertise to track down a root cause based on the application event log entries.  It is also possible to export the application event log and send it to someone else (such as a Product Support specialist) for help diagnosing the problem.  To do this, simply right-click on the application event log and choose Save Log File As... in the menu that appears.  Then you can save the file as *.evt, and someone else can import it and view it using eventvwr.exe
     
    Hope this helps explain things a little bit.  Let me know if I got any of the above wrong or if you have any specific questions/comments....
  • Aaron Stebner's WebLog

    Available command line switches for .NET Framework 2.0 setup

    • 39 Comments

    With the release of VS 2005 and the .NET Framework 2.0, we began to use a new Windows Installer external UI handler to manage installation of several of the setups that are part of the VS 2005 family, including the .NET Framework 2.0 redistributable and SDK, J# redistributable, VS Tools for Office redistributable, language packs .NET, J# and VS Tools for Office, etc.

    This new external UI handler is named install.exe, and you will find an INI file named install.ini included with each product that uses install.exe.  Install.ini expresses many configuration options for the setup in question.  I have described many of the settings used for the .NET Framework 2.0 redistributable in this blog post.

    In addition to the INI file, install.exe can be configured using several command line switches.  The following list provides information about all of the command line switches that are supported by the install.exe external UI handler in the VS 2005 and .NET Framework 2.0 family of products:

    • /a - Launches setup in administrative mode.  This mode is used to create a Windows Installer administrative install point that can then be used to install or deploy the product from.  Administrative mode presents UI that allows you to choose the location to stage the files to
    • /l <log file> - Causes setup to create a verbose log in a non-default path.  Setting this value will override the value of the VerboseLog entry in the install.ini file.  If the /l switch is passed, the log file name is required.  If it is provided, it will override the LogFilePrefix entry in install.ini.  If you choose to pass a log file name and there is a space in the path, you will need to enclose the name in quotes.  Leaving this parameter off will allow setup to create a verbose log file in the %temp% directory that has a name beginning with the LogFilePrefix entry in install.ini and ending with a randomly generated character sequence.
    • /lang #### - Specifies the 4-digit language code for the language in which to display the setup UI.  This setting overrides the OS language check and the language specified in the install.ini file.  Setup looks for a file named install.res.####.dll in the same path as install.exe and attempts to load strings from that DLL.  If the DLL with the numerical value passed in via this command line parameter does not exist, install.exe falls back to English strings (located in install.res.1033.dll).  If install.res.1033.dll also does not exist, setup will display an error dialog and exit
    • /msipassthru MSI_PROP_BEGIN"<properties with quotes here>"MSI_PROP_END - Specifies additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe). This switch also requires that a token be used to prefix/postfix the actual command line arguments.  For example: /msipassthru MSI_PROP_BEGIN"PROPERTY1=Value1 PROPERTY2=Value2"MSI_PROP_END
    • /msipassthru MSI_ARGS_FILENAME_BEGIN<path to file with properties>MSI_ARGS_FILENAME_END - Specifies the full path to a file that contains additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe)
    • /q - Specifies quiet install mode. Suppresses the display of all setup UI during installation
    • /qb - Specifies basic UI mode for installation.  This will cause install.exe to only show a small Windows Installer progress dialog with no other user interaction required.  This is the equivalent of the msiexec.exe /qb command line switch
    • /qb! - Extends the /qb switch by hiding the cancel button on the progress dialog during installation.  This is the equivalent of the msiexec.exe /qb! command line switch
    • /qu - Specifies quiet uninstall mode.  Suppresses the display of all setup UI during uninstallation
    • /skip_all_checks - Causes install.exe to skip all prerequisites checks that are specified in install.ini.  This may result in setup failing elsewhere because some of the checks are also specified in the MSI itself.  However, this can be useful as a troubleshooting tool if you know the state of the machine(s) that you are installing on very well
    • /watsonsilent - Causes all Watson reports generated by setup in the case of failure to be silently sent to Microsoft instead of displaying a dialog.  This command line switch is only applicable if one of the /q flags is also used
    • /watsonui - Causes all Watson reports generated by setup in the case of failure to display UI informing the user of the issue
    • /? - Displays a help dialog with information about supported command line parameters.  As I was writing this article I noticed that many of the switches that are supported by install.exe are not actually listed in this dialog.  I'll be reporting a bug to the setup team so that hopefully this will be cleaned up in a future release to present more useful information to the user

    <update date="12/7/2005"> Added a note to the /l log file switch indicating that you need to put quotes around the file name if there are spaces in the name </update>

     

  • Aaron Stebner's WebLog

    Possible solutions for a 2203 error while installing the .NET Framework

    • 12 Comments

    I received a mail from a customer today that described a scenario where the .NET Framework 2.0 setup failed with error code 2203.  In this scenario, the application event log contained an entry like the following:

    Microsoft .NET Framework 2.0 -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2203. The arguments are: C:\WINNT\Installer\2579981.ipi, -2147287035

    According to the Windows Installer documentation, error code 2203 means Database: [2]. Cannot open database file. System error [3].  In this case, the system error code (-2147287035) means "access denied."

    There are a couple of cases where I have seen this error in the past for the .NET Framework and other types of MSI-based setup packages:

    1. Permission problems for the %windir%\installer folder - If the Windows Installer service does not have sufficient permissions to read and write to this folder, the installation will fail.  Typically the subinacl tool described here will fix the permissions and then you can re-run setup and it will work correctly.
    2. Anti-virus software - If you have a real-time virus scanner enabled, and it happens to be scanning the file in %windir%\installer at the same time as setup is trying to open the file and install from it, you will get this type of error.  This is generally a timing issue, and in this case re-running setup will fix it.  Alternatively, you can disable real-time virus scanning during installation, but if you do this please be aware of the security implications of doing so and either install while not connected to the network, or if that is not possible, make sure to immediately re-enable the virus scanner after setup completes.

     

  • Aaron Stebner's WebLog

    Final official version of .NET Framework 2.0 is available for download!

    • 13 Comments

    Hey, I'm happy to say that the .NET Framework 2.0 is finally finished, and the official RTM build (2.0.50727.42) is available for download on the Microsoft Download Center.  Check out this location for a full list of .NET Framework 2.0 products that are available.  Here are some of the most commonly requested downloads:

    A couple of important notes here:

    1. The .NET Framework 2.0 SDK requires that you install the .NET Framework 2.0 redistributable first, so if you want the SDK make sure to download both
    2. The .NET Framework 2.0 redistributable is a language-neutral package.  Setup UI will appear in the language of the OS you are running setup on (more setup packaging details are here if you are interested).  The resources inside of the package are English only.  There will be language packs available soon that contain non-English product resources.
    3. The .NET Framework 2.0 SDK is English only.  Non-English languages will be available soon.

     

  • Aaron Stebner's WebLog

    Windows Installer custom action tutorial

    • 1 Comments

    Steven Bone posted the first of a series of articles about how Windows Installer custom actions work and how to create and debug them.  You can click on the link to read Part 1 - Custom Action Types and Sequences.

    This article describes how to configure the columns of the custom action table in an MSI, when to use immediate and deferred custom action types, how to handle rollback, and when to use the various custom action flags, options and conditions.

    When using Windows Installer to create a setup, you can author most necessary actions using the standard MSI tables.  However, there are some types of actions that are not supported using native MSI tables (such as the list I posted a while back).  Because of this, using custom actions in your MSI will sometimes be necessary.  Building a setup package is an integral part of the software development process, and the same level of care should be put into planning and designing the setup and deployment for your software.

    Therefore, I strongly encourage you to read through this article (and the follow-up articles he will be posting in the future about writing custom action code) if you do any kind of setup development or testing work.

    I also wanted to point out that there is a set of commonly needed custom actions that are published with the WiX toolset, and they can be easily incorporated into a setup package without needing to write any additional code.  If you are writing an MSI-based setup I encourage you to take a look at WiX as well.

     

  • Aaron Stebner's WebLog

    How to fix 5.1 analog surround sound in Media Center 2005 Update Rollup 2

    • 29 Comments

    There is a known issue in Update Rollup 2 for Media Center 2005 that causes 5.1 analog surround sound to revert to 2 channel mode.  The underlying issue is that a registry setting is being overwritten by Media Center.  You can use the following steps to add the registry value needed to fix this issue:

    1. Close Media Center
    2. Click on the Start menu, choose Run and type cmd
    3. Run the command reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video" /v AudioOutputFormat /d {696E1D31-548F-4036-825F-7026C60011BD} /f

    Note that if you re-run the Speaker Setup portion of Media Center Setup, this registry value will be reset again and you will need to re-run the above command to fix the underlying issue once more.

    This issue was previously described on this NVidia support page, but I wanted to list it here as well in case anyone reading my blog runs into it as well.

     

  • Aaron Stebner's WebLog

    Hibernate once, resume many (HORM) in a nutshell

    • 32 Comments

    I wanted to take a minute to spotlight one of the big new embedded enabling features that is new to Windows XP Embedded SP2.  It is called hibernate once, resume many.  We have taken to abbreviating this to HORM internally, so if you see this new acronym floating around in documents or newsgroups about XP Embedded that is likely what it means.

    HORM provides the ability to resume an EWF-protected system from a hibernation file (hiberfil.sys) each time a machine is restarted instead of performing a full OS boot.  This greatly improves the cold-boot startup time of machines.  Here are a few key points about HORM:

    • You must protect all partitions on your volume with EWF in order for HORM to work correctly
    • You must use EWF RAM or RAM Reg overlay types in conjunction with HORM
    • Ordinarily, NTLDR will check the header/signature of hiberfil.sys when the system begins the boot process in order to protect against a stale orphaned hiberfil.sys being booted.  If a stale hiberfil.sys is detected, NTLDR will show a menu asking if you want to continue to resume or discard the hiberfil.sys and perform a full boot.  You can create a file named resmany.dat (any size, any format) on the root of the boot partition (typically c:) to suppress this check and allow your device to resume without any user interaction.
    • You must make sure to use the EWF NTLDR with HORM.  EWF NTLDR is the only boot loader that has the logic to search for resmany.dat and skip the hiberfil.sys header check.
    • There are useful help docs describing how to implement HORM on your device, you can check them out here.
    • One thing not covered in the documentation is how to enable HORM directly from Target Designer.  You can create an additional file resource that will copy resmany.dat to the root of your image partition or simply add it to the image after you do a build inside of Target Designer.  Then, assuming you have enabled hibernation in your power management component and configured EWF to run on startup, you will be able to immediately create your hiberfil.sys after your image finishes running through first-boot agent (FBA).
    • If you are using Winlogon and include the settings in the UI Core component you will be able to hibernate via the start menu.  If not, you can include the XPE Power Management tool (xpepm.exe) and run xpepm -hibernate from a cmd prompt to create your hiberfil.sys after you launch the apps that you want to run each time you resume.

    I encourage you all to take a look at HORM as you start exploring XPE SP2.  Please let us know if you run into any problems or have any questions.

     

  • Aaron Stebner's WebLog

    How to manually reset Digital Rights Management (DRM) in Windows Vista

    • 5 Comments

    Question:

    I have a system with Windows Vista and have been using Media Center to watch DRM-protected content for a while.  Recently, I upgraded some hardware on my system, and now I can no longer view any DRM-protected content in Media Center.  After some web searches, I found one of your old blog posts that describes a similar type of error message in Update Rollup 2 for Windows XP Media Center Edition 2005.  However, that post and the knowledge base article it refers to appear to be specific to older versions of Windows.

    I have read that some types of hardware upgrades can cause DRM to stop working in Windows, and I suspect that is what is happening to me.  How can I reset DRM on my system so that I can view protected content inside of Windows Vista Media Center again?

    Answer:

    The knowledge base article linked in that old blog post (located at http://support.microsoft.com/?kbid=891664) contains information that is applicable to Windows Vista as well as older versions of Windows, but it does not specifically state that it applies to Windows Vista.

    According to this knowledge base article, you can reset DRM by deleting the files in the DRM folder on your system (but make sure to not delete the DRM folder itself because that can cause other problems on your system).

    The default location of the DRM folder in Windows Vista is c:\ProgramData\Microsoft\Windows\DRM, but it might not be in the same location on every system.  To reliably determine the location of the DRM folder on your system, you can look up the data in one of the following registry values:

    For 32-bit versions of Windows Vista:

    [HKEY_LOCAL_MACHINE\Software\Microsoft\DRM]
    DataPath

    For 64-bit versions of Windows Vista:

    [HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\DRM]
    DataPath

    Note - the DataPath value is in binary format, so you will have to double-click on the DataPath value in regedit.exe and look at the right-hand column of the Edit Binary Value dialog box that appears to see the plain text version of the path.

  • Aaron Stebner's WebLog

    Instructions for chaining installation of Visual Studio 2005 and MSDN

    • 44 Comments

    I got a question from a customer who found this blog post describing how to chain silent installation of VS .NET 2003 prerequisites, VS .NET 2003 and MSDN.  They wanted to know what the equivalent set of steps would be for chaining silent installation of VS 2005.  There have been some modifications to how setup works behind the scenes in VS 2005, most notably the elimination of the separate step that used to be required to install prerequisite components for VS, so happily I can say these steps are much simpler than in the past.  Here are the steps for VS 2005 (using the same format as my previous post).

    To start with you should stage Visual Studio bits to a network share so that you can use this as your installation source later on.  You can accomplish that with the following steps (also described in the VS readme located in the file adminreadme.htm in the Setup subdirectory on VS Disk 1):

    1. Create a folder on your server, such as \\server\vs2005
    2. Create subfolders named \\server\vs2005\vs and \\server\vs2005\msdn
    3. Copy the contents of all CDs labeled Visual Studio 2005 to \\server\vs2005\vs.  If prompted, choose yes to overwrite existing files.
    4. Copy the contents from all the CDs labeled MSDN Library for Visual Studio 2005 to \\server\vs2005\msdn.  If prompted, choose yes to overwrite existing files.
      NOTE: You can substitute a different MSDN Quarterly Library for the version of MSDN that shipped with Visual Studio 2005 if you choose

    Now that you have a network image, you can create the unattended INI file to install VS 2005 and MSDN using the following steps:

    1. Locate a test computer that has the same operating system that you want to deploy Visual Studio to in your network, and make sure that it does not already have Visual Studio 2005 installed
    2. Install .NET Framework 2.0 on your test computer (because this is required for creating an unattend file for Visual Studio in the next step)
    3. Run \\server\vs2005\vs\setup\setup.exe /createunattend \\server\vs2005\datafiles\vs.ini /vsupdate=\\server\vs2005\MSDN\setup.exe /vsupdateargs="qn"
    4. Open \\server\vs2005\datafiles\vs.ini, go to the [PostSetupLaunchList] section and change """qn""" to /qn
    5. Go to a clean computer without Visual Studio 2005 installed and run \\server\vs2005\vs\setup\setup.exe /unattendfile \\server\vs2005\datafiles\vs.ini to test the unattended installation process

    There are a couple of gotchas that I have seen that you should keep an eye out for when following these instructions:

    • Make sure to note the extra \setup\ directory for the Visual Studio setup.exe in the steps above.  Unattended installation will not work correctly if you run the setup.exe in the root of the \\server\vs2005\vs folder; you must use \\server\vs2005\vs\setup\setup.exe.
    • Make sure that you have write permission for the location that you create your data file at in step 3 (in this example I used \\server\vs2005\datafiles).  You will get an error if you try to create the data files on a share that you do not have write permissions for.
    • Make sure that you create the INI file on a computer that does NOT already have Visual Studio 2005 installed.  If you have VS installed, you will end up creating an INI file for a maintenance mode update instead of an initial install of VS.
    • The INI file for VS is unique to each version of VS (such as Pro, Standard, Team System), and also unique to the OS that you want to install on (Windows 2000, Windows XP, etc).  Make sure that you create INI files on computers that match what you will eventually be deploying to.

    There is an advanced trick that you can use when creating this unattend script as well:

    • If you want to perform a full install of MSDN to the local hard drive instead of a default installation, you can read the steps at this blog post to learn how to update your vs.ini file to call MSDN setup with the correct parameters to accomplish this.

    In the VS 2003 instructions there was an additional advanced trick regarding waiting for the setup process to exit and checking the return code.  The workaround I listed in my previous post is not necessary in VS 2005 because setup now has specific logic to not copy itself to the %tmep% folder and start a new process if it detects it is being run in administrative installation mode.

     

Page 4 of 48 (1,186 items) «23456»