Aaron Stebner's WebLog

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

  • 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

    How to deploy the .NET Framework 2.0 by using the MSI directly

    • 38 Comments

    If you try to extract the contents of the .NET Framework 2.0 setup package and install it using the MSI directly, you will see a blocking dialog that looks like the following:

    .NET Framework 2.0 block dialog

    This type of blocking dialog does not appear when trying to install the .NET Framework 1.0 or 1.1 using the MSI directly.

    If you look at the .NET Framework 2.0 netfx.msi in Orca, you can see that there is a custom action that starts with the name CA_BlockDirectInstall_GUIH_SKU_URT.  Then, if you look at the InstallExecuteSequence table of the MSI, you will see that this custom action has the following condition: ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ).  As you can see from these conditions, this custom action will fire and show this block dialog unless one of those properties is passed on the command line or the product is already installed.

    As I previously described in this blog post, we created a new external UI handler for the .NET Framework 2.0.  Along with this external UI handler, we added this custom action to block the user from installing via the MSI directly as a means of more strongly encouraging people to install using the external UI handler (side note  - this is the technique described in this post on the Windows Installer team blog for using external UI handlers).

    The external UI handler for the .NET Framework 2.0 includes a command line parameter (described in this previous post) to invoke administrator mode - you can enter this mode by running install.exe /a.  This administrator mode is essentially a UI wrapper around the standard msiexec.exe /a command line parameter for creating an administrative install point (AIP) for an MSI.  It requires you to accept a EULA, then allows you to specify a location to stage the files for the administrative install point.  The interesting thing is that if you run install.exe /a and then look at the verbose MSI log file (named %temp%\dd_netfx20_a_msi*.txt), you will see that the property ADDEPLOY=1 is set while creating the AIP.  However, this property is not used at all during creation of the AIP, and it is not saved as a part of the staged MSI.  Therefore, even if you try to install the .NET Framework 2.0 using the AIP created using install.exe /a, you will still run into the block dialog shown above.

    To make a long story short, you can use the following command lines to create an administrative install point and install the .NET Framework 2.0 using the MSI directly:

    1. To extract the contents of the setup package - dotnetfx.exe /t:c:\temp /c (or you can substitute any path of your choosing for c:\temp)
    2. To create an administrative install point - c:\temp\install.exe /a
    3. To install using the MSI directly - msiexec.exe /i netfx.msi ADDEPLOY=1

    If you are interested, you can combine the steps above if you do not care about being able to extract the contents of dotnetfx.exe or create an administrative install point:

    • To combine steps 1 and 2 above to create an administrative install point without extracting dotnetfx.exe first - dotnetfx.exe /c:"install.exe /a"
    • To combine steps 1, 2 and 3 above to directly install the MSI - dotnetfx.exe /q /c:"msiexec.exe /i netfx.msi ADDEPLOY=1 /qn"

    One other item I should point out here - you will also notice when you install the MSI directly with basic UI (using the /qb switch instead of the /qn switch above), the progress dialog has a title bar and a cancel button but is otherwise blank like the following:

    .NET Framework 2.0 blank progress dialog

    The .NET Framework 2.0 MSI has been configured to be language-neutral (described in more detail here if you're interested), and there is a bug in Windows Installer that when a language-neutral MSI with no action text or error text is installed in basic UI mode, it will not display any of the standard messages in the progress dialog.  Unfortunately, this bug is present in all current versions of Windows Installer up to and including version 3.1.  I tried an installation scenario using basic UI mode on a recent Windows Vista build and verified that this bug has been fixed in Windows Installer 4.0 (which is included in Vista).

    One final thing - all of the details in this blog post apply to all .NET Framework 2.0 and VS 2005 products that use the new external UI handler we have created.  This includes the .NET Framework 2.0 SDK, the J# redistributable package, the VS Tools for Office Runtime, Document Explorer, etc.  Essentially, any setup package included as part of Visual Studio that is packaged as a self-extracting executable and contains install.exe, install.ini and install.res.####.dll will behave the same way.

    I realize this topic is a bit involved and confusing and represents a change from previous versions of the .NET Framework, so please let me know if you have any questions or run into any problems getting things to work for you.

     

  • Aaron Stebner's WebLog

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

    • 29 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

    Media Center crashes when launched after installing KB908250 and KB910393 from Windows Update

    • 36 Comments

    I mentioned yesterday that there is a new Windows Media Player hotfix (KB910393) available that will help reduce instances of digital rights management problems in Update Rollup 2 for Media Center 2005.

    We have found a problem with the way the setup package for this hotfix interacts with Update Rollup KB908250 for Update Rollup 2 that can cause Media Center to crash when you try to launch it after installing KB908250 and KB910393 from Windows Update.

    Problem description

    In this scenario (described in this newsgroup posting), after installing Update Rollup 2 for Media Center 2005 you can visit Windows Update to search for additional updates.  There will be some new critical updates available that are only offered after you install Update Rollup 2.  Included in this list of critical updates are both KB908250 and KB910393.  If you accept the default settings, Windows Update will silently install each of these hotfixes and then reboot at the end.  However, after the reboot, you will get an unhandled exception and Media Center will crash if you try to launch it.

    How to workaround the problem

    In order to repair your system and fix this crash, you can one of the following sets of steps:

    1. Download KB908250 and re-run it
    2. Reboot

    -or-

    1. Click on the Start menu, choose Run and type cmd
    2. Run the command %windir%\system32\spupdsvc.exe /install "Enables Service Pack Installer to complete its scheduled post-reboot tasks"
    3. Reboot the system

    Root cause

    The reason Media Center crashes in this scenario is that the computer is left in a state where critical Media Center services (ehRecvr and ehSched) are not registered on the system.  The setup package for KB908250 runs commands to unregister these services, and then schedules a process to re-register them after the system is rebooted.  However, there is a command in the setup package for KB910393 that un-schedules the process that KB908250 schedules.  Therefore, the command to re-register Media Center services after the reboot never happens.

    You can verify that you are running into this exact problem by checking the following:

    • Run sc query ehrecvr and verify that it reports that ehrecvr is not an installed service on your system
    • Run sc query ehsched and verify that it reports that ehsched is not an installed service on your system
    • Look for a file named %windir%\system32\spupdsvc.inf and verify that it contains a [ProcessesToRunAfterReboot] section with commands to run C:\WINDOWS\ehome\medctrro.exe /p /f C:\WINDOWS\INF\KB908250rg.inf RunOnce, C:\WINDOWS\ehome\EhMCXIns.exe /i and C:\WINDOWS\system32\spupdsvc.exe /delete

    This problem will only occur if you install KB908250, suppress the reboot at the end, and then install KB910393 afterwards.  Unfortunately, this is exactly the way that Windows Update currently installs these 2 hotfixes after Update Rollup 2 is installed.

    We are still working with the Windows Update and Windows Media Player team to identify the best way to fix this issue.  I will post an update when we decide the right course of action.  I apologize for the inconvenience that this issue is causing.

     

  • Aaron Stebner's WebLog

    How to silently install Visual Studio 2005 Express Editions

    • 38 Comments

    A few folks (both inside and outside of Microsoft) have contacted me asking for instructions for how to install the Visual Studio 2005 Express Editions in silent and/or unattended mode.

    Some of you have found the instructions I previously posted for Visual Studio 2005 unattended installations and tried them with the Express Editions.  However, you will find that running any of the Express Edition setup.exe files with the /createunattend or /unattendfile switches will show an error dialog stating that those switches are not supported with this setup package.

    There is not a built-in automated silent or unattended installation mode for the Express Editions, so the method for performing silent installation is a bit more involved than it is for the higher-level versions of Visual Studio 2005.  You have to download each of the setup packages that is chained as part of the Express Edition setup and then run each of them using their individual silent mode command line switches.

    To accomplish the setup package download, you need to follow the instructions to create a network install point for a VS 2005 Express Edition.

    Once you have downloaded the pieces of the Express Edition setup package, you will need to figure out which pieces are needed for the OS type (Windows XP, Windows Server 2003, etc), OS language (English, etc), processor architecture (x86, x64) and Express Edition type (VB, VWD, etc).

    The following is a list of the Express setup packages, what conditions they are needed for and their silent command line switches:

    Windows Installer 3.1

    Needed on Windows 2000 and Windows XP if not already installed

    WindowsInstaller-KB893803-v2-x86.exe /quiet /norestart

    .NET Framework 2.0 (x86)

    Needed on all x86 operating systems if not already installed

    dotnetfx.exe /q:a /c:"install.exe /q"

    .NET Framework 2.0 (x64)

    Needed on all x64 operating systems if not already installed

    NetFx64.exe /q:a /c:"install.exe /q"

    .NET Framework 2.0 language pack

    Needed for all non-English Express Editions if not already installed

    langpack.exe /q:a /c:"install.exe /q"

    J# Redistributable 2.0

    Needed only for the J# Express Edition on all operating systems if not already installed

    vjredist.exe /q:a /c:"install.exe /q"

    J# Redistributable 2.0 language pack

    Needed for non-English J# Express Edition if not already installed

    vjredist-LP.exe /q:a /c:"install.exe /q"

    Lite Debugger Package (x64)

    Needed on all x64 operating systems if not already installed

    expdbgsetup.exe /q:a /c:"install.exe /q"

    Main Express Edition package

    Needed on all operating systems.  The exact command line depends on which Express Edition you want to install.

    MSDN Express

    Optional on all operating systems if not already installed

    msdnixp.exe /q:a /c:"Install.exe /q"

    SQL Express (x86)

    Optional on all x86 operating systems if not already installed

    SQLEXPR32.EXE -q /norebootchk /qn reboot=ReallySuppress addlocal=all instancename=SQLEXPRESS SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=2 SQLAUTOSTART=1

    SQL Express (x64)

    Optional on all x64 operating systems if not already installed

    SQLEXPR.EXE -q /norebootchk /qn reboot=ReallySuppress addlocal=all instancename=SQLEXPRESS SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=2 SQLAUTOSTART=1

    Additional notes about silent install of the Express Editions:

    • The packages should be chained in the order listed above because this is the order that Express setup will run them if you launch setup in full UI mode
    • All of the command lines listed above can be figured out by downloading the Express web download bootstrapper (for example, this package for Visual WebDev Express 2005), extracting the contents of the package, and reading through the file baseline.dat.  The combination of the Executable value data and the CommandLine value data for each component forms the command line that you want to use for silent installation.
    • If you look at baseline.dat for the Express Editions to form the command lines, you will notice that I removed the /watsongenman switches in the command lines that I listed above.  The /watsongenman switch is used to generate a log file that is sent as part of a Watson report for the Express Edition setup package when it is installed via full UI mode.  That switch is not needed when individually installing the components as I describe above.
    • To change from a silent installation to an unattended installation, change all instances of install.exe /q to install.exe /qb and change /qn to /qb for the main Express Edition and SQL Express command lines

    <update date="4/11/2006"> Updated command lines for Main Express Edition packages - I missed the REBOOT=ReallySuppress and /qn switches from a few of the editions </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

    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

    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

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

    • 22 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. This 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>

    <update date="9/18/2014"> Fixed broken link to the transform. </update>

     

  • 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

    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

    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 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

    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

    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

    Example of how to use Visual Studio IDE language switching

    • 16 Comments

    Recently, I wrote a couple of blog post (here and here) about how to enable multi-lingual development scenarios by taking advantage of the Visual Studio IDE UI language switching feature.  I would like to add to those previous posts by showing an example of using this feature, including some screenshots.

    For this example, I will use the English and French versions of the Visual C# 2005 Express Edition.  However, it works equally well for any version and UI language of Visual Studio.

    I configured my system as follows:

    1. I installed the English version of the Visual C# 2005 Express Edition
    2. I launched the VC# IDE to verify that everything worked as expected
    3. I installed the French version of the Visual C# 2005 Express Edition
    4. I launched the VC# IDE again to verify that everything still worked.  The UI remained in English even though I had installed the French version because this setting was set to use English UI when I launched the IDE in step 2 above

    Now that I have both the French and English versions of VC# Express installed, I can easily switch IDE UI languages.  When I launch the IDE with English UI, it appears as follows:

    Visual C# 2005 Express Edition IDE with English UI

    Once I launch the IDE with English UI, I can do the following to change the UI language to French:

    1. Click on the Tools menu and choose Options...
    2. Check the Show all settings check box at the bottom left of the screen (which is unchecked by default in the VS 2005 Express Editions)
    3. Click the International Settings option under the Environment item in the tree control on the left side of the Options dialog
    4. Select francais in the Language drop down
    5. Click OK to confirm the language change and then press OK on the notification dialog that appears to indicate that the IDE must be restarted for the change to take effect
    6. Close and reopen the IDE

    The English Options dialog looks like the following:

    Visual C# 2005 Express Edition English international settings dialog

    After following the above steps and then reopening the IDE, VC# will appear as follows:

    Visual C# 2005 Express Edition IDE with French UI

    I am able to change the language back to English by using the same set of steps as listed above, except I need to refer to the French translation for each of the IDE UI elements.  The French Options dialog looks like the following: 

    Visual C# 2005 Express Edition French international settings dialog

    In addition to using the steps listed above, I can change the IDE UI language by using the following command lines:

    • To launch the IDE with English UI: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\vcsexpress.exe /LCID 1033
    • To launch the IDE with French UI: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\vcsexpress.exe /LCID 1036

    It is important to note that when using the /LCID command line switch, the default UI language will be updated in the registry when Visual Studio launches.  That means that if you had previously configured VS to launch in English and you then pass in /LCID 1036, you will set the default language to French.  That means that when you close the IDE and reopen it using the Start menu shortcut it will continue to appear with French UI until you change it in the International Settings section of the Options dialog or launch the IDE with /LCID 1033.

    One other interesting note that I want to emphasize here - IDE language switching will be available even if you don't install the exact same edition of Visual Studio for each language.  For example, you can install the English Visual Studio Team Suite and the French Visual Studio Professional.  However, the only UI that will correctly switch languages will be components that are common to the two editions that you install on your system.  So you might see a mix of two different UI languages depending on what editions you have installed on your system and what features you use within the IDE.  In addition, there are limitations in the UI language fallback mechanism for some IDE features, so you may see some features missing from the IDE even though the feature is installed for one of the two UI languages.

    <update date="2/10/2011"> Fixed broken links to images used in this post. </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

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

    • 16 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

    Steps that might help fix Windows Update errors and a blank Windows Features dialog in Windows Vista

    • 8 Comments

    Over the holidays, I was asked by a friend to look at a problem they were running into on their Windows Vista system.  They were unable to connect to Windows Update and check for updates and received a cryptic error message.  After a few minutes of poking around on the system, I recognized a common set of symptoms that I had also seen on a couple of co-workers' systems a few weeks prior to that.  I also recognized some symptoms that I've heard about from customers via my blog who had trouble getting the .NET Framework 3.5 to install on Windows Vista due to issues with the .NET Framework 2.0 SP1 and/or .NET Framework 3.0 SP1 OS update packages that it tries to install behind the scenes.

    Since I had a system available to debug on, I ran through some troubleshooting steps that I've learned over the past couple of years related to Windows Vista OS update installation issues and identified several specific symptoms, and then eventually came up with a set of steps to fix this system.  Then I came back to work after the holidays and tried out the steps on my co-workers' systems and found that the same basic set of symptoms and resolution steps worked there as well.  As a result, I'm going to try to summarize these symptoms and the steps I used to resolve them in the hope that they might be helpful to others suffering from the same issues on their systems.

    Symptoms of this problem

    In the systems I've been able to find so far with this type of problem, I've observed a common set of symptoms.

    Symptom 1: Blank Windows Features dialog

    Going to the Programs and Features control panel and then clicking the link on the left labeled Turn Windows features on or off brings up the Windows Features dialog.  This can also be launched directly by running OptionalFeatures.exe.  In the error cases I've seen, the Windows Features dialog appears completely empty instead of listing all of the Windows components that can be enabled or disabled on the system.

    Symptom 2: Blank list of installed updates

    Going to the Programs and Features control panel and then clicking the link on the left labeled View installed updates brings up a list of installed service packs, updates and hotfixes for the OS and any applications installed on the OS.  In the error cases I've seen, the list of installed updates was completely empty, even when I knew for sure that some OS updates had been installed on the system.

    Symptom 3: Error when attempting to check for updates using Windows Update

    Going to the Windows Update control panel and choosing the Check for updates link either reports an error message and an HRESULT code (for example, 0x80070005 or 0x80073712) or states that there were no updates available for the system.

    Symptom 4: Hang or error when attempting to manually download and install OS updates

    Bypassing the Windows Update control panel by going to the Microsoft support site and directly downloading and attempting to install a Windows OS update package results in the update hanging and failing to complete installation or the update reporting that it is not applicable on the current OS and exiting without installing.

    I saw the latter behavior for the .NET Framework 3.5 on systems in this state.  On Windows Vista, the .NET Framework 3.5 attempts to install the .NET Framework 2.0 SP1 OS update package (because the .NET Framework 2.0 is an OS component on Vista).  When the systems I observed were in this broken state, the .NET Framework 2.0 SP1 failed to install, and I observed the following error in the .NET Framework 3.5 or 3.5 SP1 log file named %temp%\dd_dotnetfx35install.txt:

    [08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): ***ERRORLOG EVENT*** : Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1.

    Error code 1 from the .NET Framework 2.0 or 3.0 CBS package means that the package is not applicable on the current OS.

    Steps that might help resolve this problem

    On the systems that I have been able to find in this state so far, I have used the following set of steps to get the system back into a working state so that it could display information in the Windows Features dialog, check for updates using Windows Update and successfully install OS updates.  I have only been able to work with a few systems in this broken state though, so I'm not sure the same set of steps will always work.  I wanted to post them here in case there are helpful in some cases though, but please keep in mind that your mileage may vary.

    1. Download the System Update Readiness Tool and save the .msu file to your desktop.  You need to make sure to download the correct version of this tool because there is a different version for each OS type and processor architecture.  You can find the download links for this tool in this knowledge base article.

    2. Run the System Update Readiness Tool.  Once you download the appropriate .msu file for your OS type and processor architecture, you can double-click on it to install it.  This tool is not an OS update, but it uses the .msu packaging logic that OS updates use.  Therefore, it will tell you that it is installing the package, but it is actually running the tool in the background.  When the tool is running, you will see processes named checksur.exe, checksurlauncher.exe and checksurpackage.exe listed in Task Manager.

      Note: The tool attempts to fix any problems that it finds on the system.  However, it was not able to fix the problems it found on the systems that I have seen that experienced this type of problem.  It is still useful to run the tool in order to create a log file that lists the issues it finds.

    3. Look at the output in the CheckSUR.log file and make fixes based on what the tool reports.  The checksur.exe tool created a log file at the following location: %windir%\Logs\CBS\CheckSUR.log.  On the systems that I have seen this type of problem on, the CheckSUR.log reported problems with some of the registry values located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages on the system.  I used the information in CheckSUR.log to locate and manually delete keys with errors reported for them.  On one of the systems, some of the sub-keys only had permissions assigned to them for the local system account, so I had to add the Administrators group and then delete them.  On one of the other systems, some of the sub-keys were reported as orphaned from some previous OS update that had been installed on the system, so I manually deleted them.

      One very important note here - I strongly recommend making a backup of your registry before trying to manually change any of the sub-keys under this HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages key.  This sub-key contains information that is usually only modified by installing and uninstalling OS update packages, so it is possible to cause problems with the OS if you delete keys that are still needed.  If you do not feel comfortable manually backing up and modifying your registry, then I instead recommend that you try to repair your OS by re-running OS setup using your original OS installation disc.

    Note - I found another blog post with a more detailed step-by-step description about how to fix the Component Based Servicing registry keys.  You can find that post at http://www.raymond.cc/blog/archives/2009/03/06/fix-blank-or-empty-list-in-vista-turn-windows-features-on-or-off-optionalfeaturesexe/.

    Hopefully this set of steps will be helpful to some folks who run into this type of symptoms on their Windows Vista systems.  Again, I want to emphasize that I've only been able to directly look at a few systems that exhibited this type of symptoms, so these steps may or may not help 100% of the time if you have a system in a similar state.

    <update date="2/11/2009"> Updated list of steps to run the CheckSUR tool because the packaging for the tool has changed since the time I originally wrote this blog post. </update>

    <update date="4/3/2010"> Added a link to a blog post with additional steps about how to fix the Component Based Servicing registry keys. </update>

     

  • 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

    Scenarios where .NET Framework 3.5 setup tries to connect to the Internet and how to avoid them

    • 30 Comments

    The setup program for the .NET Framework 3.5 and the Visual Studio 2008 Express Editions contains logic that will cause it to attempt to connect to the Internet to download files in some scenarios.  I've heard from several folks who have asked me why this happens and how to prevent it in case they need to install in a fully offline scenario where the system has no Internet connectivity.  This post will describe the cases I know of where .NET Framework 3.5 and VS 2008 Express Edition setup will attempt to download files from the Internet and how they can be avoided if necessary.

    Case 1 - Missing setup packages

    .NET Framework 3.5 and Visual Studio 2008 Express Edition setup both have logic to search in relative paths next to setup.exe for packages that need to be installed during the setup process.  If any of the packages are not found in those relative paths, setup will use URL values constructed from information in the setup data file named baseline.dat to attempt to download the packages from the Internet instead.  If setup cannot connect to the Internet or the download fails for any reason, then setup will fail and report an error.

    In order to avoid requiring Internet access in this scenario, you need to make sure to construct an install point for the .NET Framework 3.5 or the Visual Studio 2008 Express Editions that include all packages that could need to be installed in your environments.  You can find more information about how to do this in the following blog posts:

    If you are interested, you can find more information about how this automatic download functionality works in .NET Framework 3.5 setup here and here.  The VS 2008 Express Edition setup packages use the same setup.exe code as the .NET Framework 3.5 setup, so the behind-the-scenes logic is similar for those packages.

    Case 2 - Installing the .NET Framework 3.5 on a non-English OS

    The .NET Framework 3.5 setup contains logic to check the language of the OS that it is being installed on and attempt to install a language pack that matches the OS language if one is available.  However, the "full install" setup package for the .NET Framework 3.5 does not include any language packs, so setup will attempt to connect to the Internet when this package is run on many non-English language OS's.

    In order to avoid requiring Internet access in this scenario, you can use one of the following techniques:

    • Download the .NET Framework 3.5 language packs that could be needed in your environments and copy them into your installable .NET Framework 3.5 layout.  You can find download locations for the .NET Framework 3.5 language packs in this blog post and instructions regarding where to copy them in your .NET Framework 3.5 installable layout in item 2 in this blog post.
    • Run .NET Framework 3.5 setup with the /lang switch and pass in the value ENU to prevent it from attempting to install any language packs.  This is described in item 1 in this blog post.

    Note - .NET Framework 3.5 setup is configured to report warnings as opposed to failures if it is unable to download or install language packs.  That means that the above steps are not required in order to allow setup to succeed in offline scenarios, but these steps are required if you want to avoid any attempts to connect to the Internet during .NET Framework 3.5 setup on non-English operating systems.

    Case 3 - Checking for a new version of setup

    The setup programs for the .NET Framework 3.5 and the Visual Studio 2008 Express Editions contain logic to cause them to connect to the Internet to search for an updated version of the setup program.  This will only happen if setup is run with the /web command line switch.  The .NET Framework 3.5 setup program (dotnetfx35setup.exe) and the web download bootstrapper packages for the Visual Studio 2008 Express Editions (vbsetup.exe, vcsetup.exe, vcssetup.exe and vnssetup.exe) are self-extracting packages that are configured to unpack and then run the setup.exe contained within the package with the /web switch.

    In order to avoid having .NET Framework 3.5 setup connect to the Internet to search for an updated version of itself, you must do the following:

    1. Create an installable layout using the steps in this blog post
    2. Go to the folder that you extracted the .NET Framework 3.5 setup files to, find the file named dotnetfx35setup.exe and run dotnetfx35setup.exe /x to unpack it
    3. When prompted, choose to unpack it to the same folder it is currently located in
    4. Instead of using the file dotnetfx35setup.exe to start installing the .NET Framework 3.5, use the file setup.exe in the unpacked location.  This will cause setup to run without the /web switch and skip the step of connecting to the Internet to search for a new copy of setup.  The setup.exe file takes the same command line parameters as dotnetfx35setup.exe (such as the /q and /norestart switches for silent installation).

    For the Visual Studio 2008 Express Editions, only the web download bootstrapper packages available from this download page are configured to use the /web switch.  If you use the instructions for creating an installable layout in this blog post, you will end up unpacking the package that has the /web switch built into it, and running from the layout you create will not end up searching for a new instance of itself during setup.

    Note - .NET Framework 3.5 and VS 2008 Express Edition setups are configured to not fail if they are unable to connect to the Internet to check for a new instance of setup.  That means that the above steps are not required in order to allow setup to succeed in offline scenarios, but these steps are required if you want to avoid any attempts to connect to the Internet during .NET Framework 3.5 setup.

  • 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

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

    • 7 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.

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