Aaron Stebner's WebLog

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

December, 2005

  • Aaron Stebner's WebLog

    More detailed steps to fix .NET Framework install errors that ask for tmpXXXX.tmp


    I previously described a set of steps in this blog post that can be used to manually remove the .NET Framework and reinstall it if you receive an error message stating that setup is unable to find the file tmpXXXX.tmp when attempting to install a .NET Framework service pack or hotfix.   However, I've heard from a couple of customers over the past few weeks who still received errors related to tmpXXXX.tmp after performing the cleanup steps in that blog post.  As a result, I posted a more complete set of steps that you can use to clean up your system and reinstall the .NET Framework.  You can find them at http://blogs.msdn.com/b/astebner/archive/2008/03/07/8108332.aspx.

    <update date="3/20/2009"> Fixed broken link to the .NET Framework cleanup tool. </update>

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


  • Aaron Stebner's WebLog

    How to clean up a SQL 2005 instance name left behind by a previous uninstall


    I have heard from a few customers who have tried to uninstall and re-install SQL 2005 and have run into errors with both the uninstall and the re-install.  I have already described the most common uninstall error and a suggested workaround in this previous blog post (an error reading property "Installids" from the cache and/or an error writing property "flagCommit" to the cache).

    I wanted to address one of the most common SQL Express install errors I have seen - a duplicate instance name error that causes SQL setup to fail and rollback.  It is pretty easy to tell if you are running into this error if you launch SQL setup directly and step through the SQL setup UI.  However, if you are installing SQL Express as a part of Visual Studio 2005, setup runs in silent mode and you will only see a generic error bubbled up from Visual Studio setup indicating that SQL Express failed to install.

    VS 2005 configures SQL Express with an instance name of SQLEXPRESS when it runs SQL setup in silent mode.  If you previously had SQL Express installed and try to uninstall it but something goes wrong with uninstall, you may end up with an orphaned instance name on your system, and then re-installing SQL Express can fail.  In this case, the verbose setup log file for SQL Express will show an error that looks like the following:

    MSI (s) (AC!38) [00:01:41:056]: Product: Microsoft SQL Server 2005 Express Edition -- Error 28086. An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

    Error 28086. An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

    If you are running into an error installing SQL Express as a part of Visual Studio 2005 setup, you can check in the SQL Express log files (located at %ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG).  If you are receiving an error about the instance name not being unique, you can manually clean off the orphaned instance name by doing the following:

    1. Click on the Start menu, choose Run and type regedit
    2. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server
    3. Remove SQLEXPRESS from the REG_MULTI_SZ value named InstalledInstances
    4. Delete the subhive named MSSQL.1
    5. Delete the subhive named SQLEXPRESS
    6. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL
    7. Delete the value named SQLEXPRESS
    8. Delete the folder %ProgramFiles%\Microsoft SQL Server\MSSQL.1

    Note - the above steps apply to the instance name that is created when SQL Express is installed as a part of Visual Studio 2005.  The actual instance name on your system may vary if you have had any other beta version of SQL 2005 (such as the developer edition).  Please make sure to adjust the steps accordingly based on what instance name information is in your registry and file system.

    <update date="7/24/2009"> Updated this post to not be beta-specific.  The same type of error can occur if you uninstall and re-install the final release of SQL Express or SQL Express service packs. </update>


  • Aaron Stebner's WebLog

    Definitive list of workarounds for Package Load Failure errors in Visual Studio 2005


    Important note - the steps in this blog post have typically only proven useful in cases where a previous beta of Visual Studio 2005 was installed on the system prior to installing the final release of VS 2005.  If you have never had a beta of VS 2005 on your system and are encountering package load failure errors, these steps will most likely not help.  In that type of scenario, I recommend running devenv.exe with the /log switch (described in this MSDN topic) to create a log file of the packages it tries to load and then search in that log file for errors and warnings to help narrow this issue down further. 

    Ever since the final version of Visual Studio 2005 was released, I have been hearing from customers who are running into Package Load Failure errors while trying to get beta versions uninstalled and the final version installed.  I have previously posted a set of steps that I have found will resolve nearly all cases of these Package Load Failure errors.  However, there have been some cases where these steps are not enough and more in-depth manual removal steps have proven necessary.  Up until now, I have been resisting posting the additional steps that are necessary in some cases because I really want folks to try out the other steps I have posted first.  However, I am going to go ahead and post a complete set of steps and just duplicate my previous steps in an effort to communicate the workarounds I have found as widely as possible while also making my best effort to make things as easy as possible for the majority of customers.

    So, without further ado, here is a complete, hopefully definitive set of steps that will help resolve all Package Load Failure errors seen while trying to use the final release of VS 2005 on a system that previously had a beta version installed.  Please try these steps in the order listed and check to see if the Package Load Failure errors are resolved after completing each step so that you can try to avoid needing to perform more removal steps than are strictly necessary on your system.

    Please note - if you have Dotfuscator 3.0 installed on your system, you should first try the workaround described here to see if you are running into a known issue that has been fixed by Preemptive (the company that produces Dotfuscator).

    1.  Try to repair the .NET Framework 2.0

    Sometimes, package load failures have a very simple cause - the .NET Framework 2.0 is somehow in a broken state.  Before trying any of the more complicated steps listed below, it is worth trying to repair the .NET Framework 2.0.  To do this, go to the Add/Remove Programs control panel, locate the item named Microsoft .NET Framework 2.0 and choose to repair it.

    2.  Try to run the VS 2005 beta uninstall troubleshooting tool

    Before trying any of the manual steps listed below in this blog post, please download and run the VS 2005 beta uninstall troubleshooting toolThis tool is built on the same code base as the auto-uninstall tool, but it has knowledge of some specific problems that existed in previous beta versions of VS 2005 and knows how to go in and surgically clean them up.

    3.  Try to run the following command line to clear out parts of the native image cache

    • Close Visual Studio and/or reboot the system to make sure that there will not be any files in use
    • Click on the Start menu, choose Run and type cmd
    • Type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu# and press enter to remove a subset of the native images that have proven problematic in the past from the cache.

    4.  Try to run the following command line to clear out all of the native image cache

    • Close Visual Studio and/or reboot the system to make sure that there will not be any files in use
    • Click on the Start menu, choose Run and type cmd
    • Type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32 and press enter to remove all VS 2005 native images from the cache.

    5.  Remove the version of VS 2005 you have installed, manually clean the system and try installing again

    • Uninstall all of VS 2005 using the uninstall instructions and automated uninstall tool
    • Click on the Start menu, choose Run and type cmd
    • Type cd /d %windir%\assembly
    • Type rd /s /q GAC_32 and then rd /s /q GAC_MSIL
    • Type dir and locate any directories named NativeImages_v2.0* and type rd /s /q <directory> to delete all VS 2005 native image directories as well
    • Using regedit.exe, remove all of the following registry sub-hives, including all registry keys and values underneath them:

    • Run this set of steps to locate and delete any files with versions 2.0.xxxxx.xx and 8.0.xxxxx.xx that are still left on your system.  Please note that all of the Package Load Failure errors that I have seen so far have been caused by files left behind in %windir%\assembly (the GAC) on the machine, so pay special attention to any leftover files in this location and make sure that all orphaned files with versions 2.0.xxxxx.xx and 8.0.xxxxx.xx are removed before attempting to reinstall VS 2005
    • Run this set of steps to clean up the WinSxS folder
    • Reboot the machine
    • Try to install VS 2005 again

    If none of the above steps work for you, please leave a comment on this blog post or contact me and I will try my best to help you further.

    <update date="12/19/2005"> Added a new step to remove some registry data related to VS 2005 as part of step 4 above </update>

    <update date="1/10/2006"> Added link to information about a package load failure scenario caused by Dotfuscator 3.0 </update>

    <update date="1/15/2006"> I have seen a couple of issues caused by orphaned keys under the Express Edition hives and the MSDN hives, so I added those to the list in step 4 above </update>

    <update date="11/18/2006"> Added a new first step to try repairing the .NET Framework 2.0 </update>

    <update date="4/2/2008"> Added caveat that the steps in this post are typically only useful when a beta of VS 2005 was previously installed on the system. </update>

    <update date="4/24/2009"> Fixed broken link to the VS 2005 beta uninstall troubleshooting tool. </update>


  • Aaron Stebner's WebLog

    Resolving Tuner Not Found errors in Update Rollup 2 for Media Center 2005


    I have heard from some folks who have been encountering Tuner Not Found error messages when trying to view live TV in Media Center 2005 after installing Update Rollup 2.  Many of these errors have been caused by the .NET Framework versioning issue that I previously described in this blog post.  However, recently I have seen this error on systems that had no error messages listed in their setup log files.  Fortunately, I got a chance to look at one of these systems because we found a repro machine that belonged to a Microsoft employee and they brought the system in for us to take a look at in our lab.

    On the system I looked at, the Media Center receiver and scheduler services (named ehRecvr and ehSched) were installed and registered, but were in a stopped state.  I could verify by running sc query ehrecvr and sc query ehsched that this was the case.  However, when I tried to manually start these services by running sc start ehrecvr or sc start ehsched, they each failed with an error message and an error code stating that a class was not registered.

    I used the following steps to fix these services, and once I did this, live TV started working again in Media Center 2005 with Update Rollup 2.  Note that before running these steps, I verified by looking at the setup log files that setup ran correctly and that the setup error described here was not present:

    1. Click on the Start menu, choose Run and type cmd
    2. Run the command regsvr32.exe atl.dll
    3. Run the command %windir%\ehome\ehrecvr.exe /unregServer
    4. Run the command %windir%\ehome\ehsched.exe /unregServer
    5. Run the command %windir%\ehome\ehrecvr.exe /service
    6. Run the command %windir%\ehome\ehsched.exe /service

    Note that the command line parameters to unregister and re-register are case sensitive, so you must spell it /unregServer with a capital S and /service all in lower case.

    If the above steps do not help, I have also seen the following steps work in some cases to fix Tuner Not Found error messages in Media Center 2005:

    • Update your video card and tuner drivers from the websites for your hardware manufacturers
    • Launch Media Center, go to Settings | TV and try to re-run the TV setup wizard
    • Use the MceRepair tool created by Peter Rosser to forcibly re-register all Media Center binaries (note that this tool does things that standard setup does not do, so please use it with caution)


  • Aaron Stebner's WebLog

    What to do if Media Center Extender for Xbox 360 setup crashes


    I have heard from a couple of customers who have tried to download and install the software to enable using Xbox 360 as an Extender for Media Center 2005 with Update Rollup 2, but have encountered a crash dialog from the DvcSetup.exe process at the beginning of setup.  I finally located a computer in our test lab that reproduced this issue and found a possible root cause and workaround in case anyone else runs into this.

    Problem description

    The Xbox 360 PC setup package crashes almost immediately after it is launched.  The error dialog indicates that DvcSetup.exe crashed, and it may ask if you want to debug the problem.


    I was able to use the following steps to clean up the machine in our test lab that exhibited this problem:

    1. Go to Add/Remove Programs and remove the .NET Framework 1.1 (and any .NET Framework 1.1 language packs if you have any installed)
    2. Download the .NET Framework cleanup tool, run it and choose to clean up the .NET Framework 1.1
    3. Reinstall the .NET Framework 1.1 
    4. Reinstall the .NET Framework 1.1 SP1

    Details about the root cause if you are interested

    On the machine I investigated, the .NET Framework 1.1 had been installed, but none of the files were correctly installed in the global assembly cache (GAC).  I found that there were folders created for each assembly (for example - %windir%\assembly\GAC\Accessibility\1.0.5000.0__b03f5f7f11d50a3a), but the folders did not actually contain the assembly.  I also saw the following entries in the verbose MSI log file for the .NET Framework 1.1 on this machine:

    MSI (s) (C8:D8): skipping installation of assembly component: {45B8FB98-2A6C-11D6-A551-0090278A1BB8} since the assembly already exists

    There is a bug in the version of Fusion that shipped with the .NET Framework 1.0 and 1.1 where it would skip installing an assembly to the GAC if the folder already existed, even if the file was not in the folder.  Windows Installer uses Fusion to try to install assemblies into the GAC, and as the log file shows, each of the .NET Framework 1.1 assemblies was skipped because Fusion thought they already existed.

    So far, I have only seen one scenario where empty folders exist in the GAC and cause this type of behavior for .NET Framework 1.1 setup.  If you have an operating system installed and have the .NET Framework 1.1 installed, and then you peform a clean install of your operating system to the same partition and choose not to format the partition, OS setup will create a new Windows directory for you.  When it does so, OS setup copies your Windows directory to a backup location and creates the same set of folders that previously existed in your Windows directory.  However, OS setup will not mirror any of the files because it assumes that you will want the copies of the files that are a part of the OS setup that you are currently installing.

    This type of OS install leaves your computer in a state where the .NET Framework 1.1 assembly folders exist in the GAC, but they are all empty, and then due to the bug in Fusion that I previously installed, reinstalling the .NET Framework 1.1 does not fix the problem.  The workaround I described above will work correctly because the .NET Framework cleanup tool will remove these empty directories, which will allow a reinstall of the .NET Framework 1.1 to correctly install the assemblies to the GAC.


  • Aaron Stebner's WebLog

    How to short a Media Center remote control if it stops working correctly


    A couple of months ago, I posted a list of workarounds that have proven useful to resolve problems using the Media Center remote control and IR receiver after installing Update Rollup 2 for Media Center 2005.

    Since I posted that, I have received several comments from customers who were able to solve this issue with a different workaround not previously listed on that post.  I have found that internet searches do not do a great job of indexing blog comments, but they do well for the main body text of blog posts, so I wanted to post this suggestion as a separate blog post in the hope that others will be able to find it more easily.  I can't take any credit for finding this workaround.  It was posted as a comment on my previous blog post by a kind customer who discovered it and found it useful, and I have heard from several additional customers who indicated that it has helped them as well.

    I encourage you to try this workaround if you have already exhausted the list of suggestions located in my previous blog post and still have problems getting your Media Center remote control and/or IR receiver to work correctly.


    • Media Center only receives the first button press (for example - pressing up, up, up only goes up once, but pressing down, up, down, up will work correctly)
    • The IR receiver light does not blink when pressing a button
    • Pressing buttons on the remote do not have any effect


    Remove the batteries from the remote control and short the battery terminals using a small metal object such as a paper clip.

    There is enough capacitance remote control circuit board to keep it alive for hours even after you remove the batteries. However, you can workaround this and drain the capacitors by shorting two of the adjacent battery terminals on the remote.   Different remotes have different configurations, so it is difficult to know \which two adjacent terminals are the ones wired to the circuit board (the other two are simply a short to connect one battery to the other).  Therefore, you should short both pair of adjacent terminals, which can be achieved by using a paper clip.  After that, re-insert the batteries and try to use the remote control again.


  • Aaron Stebner's WebLog

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


    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

    Visual Studio 2005 setup hangs while loading installation components


    I heard from a customer last week who was trying to install the final release of Visual Studio 2005 but could not even launch the setup program.  They ran setup.exe at the root of the installation DVD, and a small dialog appeared stating that setup was copying files to the %temp% directory, and then it started loading installation components.  At this point, setup hung and the progress bar never reached 100%.  In this scenario, the log file %temp%\dd_vsinstall80.txt had the following information as the last entry in the log before setup hung:

    [12/17/05, 11:11:11] setup.exe: [2] ISetupModule::SetManager() failed in ISetupManager::LoadSetupObjectGuid() : vs_setup.dll

    In this scenario, as well as in a few other cases listed in this forum post, the underlying problem was traced to the Kaspersky anti-virus program being installed on the system.  If you see VS 2005 setup UI hang when trying to launch setup, please try to uninstall Kaspersky and hopefully it will resolve the hang for you as well.  Please note that we have seen that simply disabling Kaspersky has not seemed to help, and that you will have to perform a full uninstall of this program to workaround this issue.

    If this workaround does not work for you, please try to use the steps in this blog post to enable verbose MSI logging and then reproduce the hang and send me a zipped copy of the most recent file named %temp%\msi*.log so that I can try to take a look and see if I can figure out a root cause and workaround for you.  I have seen a few other random cases of setup UI hanging like this, and most of them can be diagnosed with this verbose log file.


  • Aaron Stebner's WebLog

    List of possible return codes from .NET Framework 2.0 setup


    A few weeks ago I posted a list of supported command line switches for the new setup wrapper that is used to install the .NET Framework 2.0 and other products in the Visual Studio 2005 family.  If you are deploying the .NET Framework 2.0 as part of another setup package, the command line parameters are only one piece of the puzzle.  It is also useful to listen to the return codes passed back by the setup package in order to determine if .NET Framework 2.0 setup succeeded or failed.

    In general, the return code 0 indicates success, the code 3010 indicates success with a reboot required, and anything else indicates failure.

    Here is a list of other return codes that could be generated by the .NET Framework 2.0 setup wrapper along with descriptions of what they mean:

    • 0x001000 (4096) - Invalid command line parameter(s)
    • 0x001001 (4097) - Administrator provileges are required to run setup
    • 0x001002 (4098) - Installation of Windows Installer failed (this is a legacy return code that is not used since we stopped bootstrapping Windows Installer as a part of the .NET Framework setup during the 2.0 product cycle)
    • 0x001003 (4099) - Windows Installer is not configured properly on the machine
    • 0x001004 (4100) - CreateMutex failed
    • 0x001005 (4101) - Another instance of setup is already running
    • 0x001006 (4102) - Cannot open the MSI database
    • 0x001007 (4103) - Cannot read from the MSI database
    • 0x00100F (4111) - Cannot retrieve the %temp% directory
    • 0x001011 (4113) - Beta components have been detected on the machine that must be uninstalled before installation can proceed
    • 0x001013 (4115) - The length of the %temp% path is too long
    • 0x001014 (4116) - The length of the source path too long
    • 0x001016 (4118) - Failed to create or write to the log file
    • 0x001017 (4119) - The Windows Installer service is not responding to Service Control requests and the system requires a reboot in order to continue
    • 0x001018 (4120) - An internal error occured while trying to initialize the Windows Installer service
    • 0x001019 (4121) - One or more prerequisites for this product is missing
    • 0x00101A (4122) - The product does not support installing on the current operating system type
    • 0x00101B (4123) - The product is already installed as an operating system component (the .NET Framework 2.0 is an OS component on Windows Vista and installing the MSI-based setup is blocked and will return this error in silent mode)
    • 0x00101C (4124) - Error processing the install.ini file (there is either a syntax error or a missing mandatory entry)
    • 0x001FFF (8191) - Setup failure - unknown reason (all errors not covered above are grouped into this bucket)
    • 0x002000 (8192) - Reboot is required

    Here are some other error codes that could be returned by the .NET Framework 2.0 setup wrapper, but that are actually generated by Windows Installer and not by the code for the setup wrapper itself:

    • 0x00000641 (1601) - The Windows Installer service could not be accessed
    • 0x00000642 (1602) - The user cancelled setup. Installation cannot proceed
    • 0x00000643 (1603) - Fatal error during installation (this error is returned if any custom action fails within an MSI-based setup for example)
    • 0x00000656 (1622) - Error opening Windows Installer log file. Verify that the log file location exists and is writable.
    • 0x00000661 (1633) - This installation package is not supported on this platform

    Please note that I do not list any generic Win32 error codes here.  You can use a tool such as errlook.exe (which ships in %ProgramFiles%\Microsoft Visual Studio 8\Common7\Tools if you have VS 2005 installed) or err.exe to translate Win32 error codes.

    <update date="12/12/2005"> Added some common Windows Installer error codes to the list </update>


  • Aaron Stebner's WebLog

    Possible workaround for Media Center guide download error code 20


    Our development team has found a possible root cause and workaround for error code 20 that may appear when trying to download television guide data in Media Center 2005.  The guide download error code article I previously published describes error code 20 as a file validation error, possibly caused by a mismatched guide package.  Previously, the only recommended workaround was to try downloading guide data again later.

    We got a hold of a machine that was displaying error code 20, and the developer debugged and found the failure resulted from a call to a cryptographic API that is used to decode guide data (which is downloaded in an encrypted format).  For some reason we don't fully understand yet, this API returns a set of permissions that don't permit the guide data file to be opened correctly.

    This workaround that we used to resolve this issue is the following:

    1. Log onto the computer as a user with Administrator privileges
    2. Close Media Center
    3. Navigate to the %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys folder
    4. Delete the file that starts with 1c93d682e65b0f3af0cd51385becba5e_
    5. Restart Media Center and try to download television guide data again

    Error code 20 is being caused by one of the machine keys in that folder, but it appears to be a different key on each computer that hits this problem.

    <update date="6/22/2006"> Updated this workaround so that it only includes deleting Media Center-specific RSA keys.  The previous workaround ended up deleting the entire RSA key store, which can impact other products on the system. </update>


  • Aaron Stebner's WebLog

    How to resolve TV glitching in Media Center 2005 on dual core AMD computers


    Some customers have been reporting TV glitching issues in Media Center 2005, and Dave Fleischman has narrowed down one of the root causes to be an issue with dual core AMD systems.  He got a hold of one of these machines and was able to easily reproduce the issue, and further research showed that the problem affected other applications (specifically, games) and not just Media Center.  Fortunately AMD has released a processor update pack on their hotfix website to address this issue.  If you are running into this issue, you will want to download and apply this update for the dual core processor from that site.


  • Aaron Stebner's WebLog

    Digital Audio Service errors on machines with Emuzed Maui TV tuner cards


    We have identified a root cause and a fix for one of the sources of Digital Audio Service overlay errors that happen after installing Update Rollup 2 for Media Center 2005.  There are some Dell Media Center systems that shipped with Emuzed Maui TV tuner cards and contained drivers that were still going through the Windows Hardware Quality Lab (WHQL) certification process.  The manufacturer of these tuner cards, formerly known as Emuzed and now known as Lumanate, has released updated drivers for these tuner cards that have been certified by WHQL.  The Media Center team here at Microsoft was contacted by a fellow employee with a system like this at home, and he reported to us that installing these updated drivers caused the Digital Audio Service overlay to stop appearing on his system.

    If you are running Update Rollup 2 for Media Center 2005 and seeing Digital Audio Service overlays, you will first need to determine whether or not you have an Emuzed Maui TV tuner card in your computer by consulting your system specifications or by using the Media Center Diagnostics Kit.  This class of tuner appears with the name "Angel" in the Windows Device Manager and the Media Center Diagnostics tool.

    If you have one of these tuner cards, you will then need to determine the correct make and model and download the relevant updated driver package from the Lumanate Angel driver site and install them.

    Please note - this is only one possible root cause.  There are other cases that we are still investigating for folks who do not have this brand of TV tuner.

    I hope this helps resolve some of these issues for folks seeing the Digital Audio Service overlay problem.  I apologize for the hassles that this has caused and for the time that it took us to locate this fix.

    <update date="12/3/2005"> Added clarification that the tuners that can cause this issue are named "Angel" in Device Manager </update>


  • Aaron Stebner's WebLog

    How to escape quotes in the command line for .NET Framework setup


    I heard from a setup developer here at Microsoft last week who was working on updating his team's setup chainer to install the .NET Framework 2.0 instead of .NET Framework 1.1, but he was running into some issues while working on the implementation.

    Their team's setup is doing something creative that I hadn't heard of anyone trying before.  They want to be able to display reasonably accurate progress during the installation of the .NET Framework.  Since the .NET Framework setup does not offer any kind of hook to let a calling setup package register to receive messages, they added logic to their setup chainer to parse the .NET Framework verbose MSI log file and display granular progress UI based on that.  For reference, you can compare this algorithm to the "fake" progress algorithm used by Visual Studio setup when it installs the .NET Framework if you're interested.

    Their setup wrapper installs the .NET Framework 1.1 with the command line dotnetfx.exe /q:a /c:"install.exe /l /q"  In the .NET Framework 1.1 setup wrapper, passing the /l switch with no arguments following it causes setup to create a verbose MSI log file named netfx.log in the %temp% directory during setup.

    A similar command line will allow you to install the .NET Framework 2.0, but the behavior of setup is slightly different.  Verbose logging is enabled by default, so you do not need to pass the /l switch.  By default, the verbose MSI log file will be named %temp%\dd_netfx20msi*.txt (where * is a randomly generated ending) instead of %temp%\netfx.log.

    In order to minimize the churn to their setup code, the team that contacted me wanted to be able to force the log file to be named netfx.log so they would not have to dynamically determine the log file name each time their setup package launched .NET Framework 2.0 setup.  I tried the following command line from a cmd prompt and it worked great for me - dotnetfx.exe /q:a /c:"install.exe /l %temp%\netfx.log /q".

    However, the setup wrapper that this team wrote calls CreateProcess to launch .NET Framework 2.0 setup, and passing the %temp% string to CreateProcess throws an error because the environment variable is not automatically expanded via CreateProcess like it is via a cmd prompt, and the .NET Framework is not able to create a log file with the literal name %temp%\netfx.log.  So they added code to their setup wrapper to programatically expand the %temp% variable (using an API call such as GetTempPath) and then call .NET Framework 2.0 setup with the expanded path passed in via the /l command line parameter.

    This introduced one additional problem because the %temp% environment variable expands in a cmd prompt into 8x3 format (meaning there are no spaces in the path), but the GetTempPath API call expands into standard format (which typically has spaces in it).  The .NET Framework 2.0 setup wrapper (install.exe) parses command line parameters using spaces as a delimiter unless the parameter is enclosed with quotes.

    That means that if you want to install the .NET Framework 2.0 and create a log file in a path with spaces you need to use a command line like the following:  dotnetfx.exe /q:a /c:"install.exe /l ""c:\Documents and Settings\myusername\Local Settings\Temp\netfx.log"" /q"

    The key thing to note in this command line is that you have to double-quote any quotation marks that appear inside the quotes for the /c command line parameter.  Double-quoting is the way that you have to escape quotation marks when passing command line parameters to an IExpress self-extracting executable package.

    <update date="7/12/2006"> Updated instructions for .NET Framework 2.0 command line switches because the exact same command line from .NET 1.1 will not work in .NET 2.0 </update>


  • Aaron Stebner's WebLog

    How to repair a Visual Studio 2005 Express Edition without redownloading the source files


    While trying to configure Visual C# 2005 Express on my laptop as I prepared for my trip home for the holidays, I discovered some interesting behavior in the setup package that I wanted to post about.  This story began after I installed the product and then attempted to repair it by going to the entry for Microsoft Visual C# Express Edition 2005 - ENU in the Add/Remove Programs control panel.  I was expecting the installation program to cache a local copy of the C# Express setup files similar to how the .NET Framework 2.0 does (which is described in more detail in this blog post), but the design for repair for the Express Editions ended up changing in between the time I left the Visual Studio setup team and the time that VS 2005 shipped and that was not the case.

    Instead, when setup loaded, I was first presented with a set of options - add optional products (such as SQL Express or MSDN), repair, or uninstall.  When I chose the repair option, I reached a screen that asked if I wanted to browse to the source location or if I wanted to go to the internet and re-download the source files.  I decided to try to use the copy of the files that I found installed on my system in the folder named C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU (which I thought was the cached source files for repair based on the names and sizes of the files in that folder).  This screen looked like the following:

    Visual C# Express Edition setup source location dialog

    After browsing to the path and clicking Install, I got the following error message telling me that setup was unable to locate the product to repair it:

    Visual C# Express Edition setup unable to locate the product dialog

    Since I had seen similar error messages in the past, I decided to try to figure out exactly what setup was doing behind the scenes.  As an experiment, I created a blank folder named WCU inside of the folder named C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU (this folder structure mimics what the original installation folder structure looks like).  This time when I clicked Install, I did not get the "unable to locate the product" error dialog and repair appeared to start for me.  After a couple of minutes, I was prompted for the source location of the setup package for Windows Installer 3.1 with a dialog that looked like the following:

    Visual C# Express Edition setup missing file error dialog

    I was able to manually place the setup packages for each of the prerequisites in the locations that setup was expecting them and then click OK on the Insert Disk dialog to finally get repair to complete.

    Based on the above experience, I want to present a couple of options that you can use to repair the Visual Studio 2005 Express Editions without needing to access the internet.  This allows you to enable offline repair scenarios like the one I was trying to accomplish with my laptop.  There are 2 options that I was able to get to work successfully:

    1.  Repair only the main Express Edition MSI package using a Windows Installer command line

    In this option, you can repair the Express Edition you have installed without repairing any of the prerequisites.  This option works best if you already know that the prerequisites are correct and do not need to be repaired (or if you don't mind manually repairing the prerequisites separately since they each have their own Add/Remove Programs entry that you can use for repairing them).  This option does not require any manual downloading of packages.  However, you cannot use the setup UI provided in the Express Edition Add/Remove programs entry to perform this type of repair.  To use this option, you need to run a command line that looks like the following:

    msiexec.exe /fvecms "C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU\vcssetup.msi"

    The exact command line will vary based on what Express Edition you have installed and where it is installed.  The most reliable way to figure out the path to use is to search for the MSI file that you will need based on the following list, and then building the command line using the path that this file is located in:

    2.  Manually download and copy the prerequisite packages that setup tries to repair

    In this option, you will manually download each of the prerequisite packages that setup tries to repair and copy them to a location that setup can use when you launch a repair from the Express Edition Add/Remove Programs entry.

    The following steps should allow you to download and store the prerequisites and repair the Express Edition from Add/Remove Programs for a 32-bit OS:

    • Locate the folder that is similar to the following - C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU.  The exact name of this folder will vary based on which Express Edition you have installed and where it is installed.
    • Create a folder named WCU in this folder
    • Create a folder named msi31 in the WCU folder
    • Download Windows Installer 3.1 and save it into the msi31 folder
    • Create a folder named dotnetframework in the WCU folder
    • Download the .NET Framework 2.0 and save it into the dotnetframework folder
    • If you are installing a non-English Express Edition, download the matching language of the .NET Framework 2.0 language pack and save it into the dotnetframework folder
    The following steps should allow you to download and store the prerequisites and repair the Express Edition from Add/Remove Programs for a 64-bit OS:
    • Locate the folder that is similar to the following - C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU.  The exact name of this folder will vary based on which Express Edition you have installed and where it is installed.
    • Create a folder named WCU in this folder
    • Create a folder named dotnetframework in the WCU folder
    • Create a folder named x64 in the dotnetframework folder
    • Download the .NET Framework 2.0 and save it into the x64 folder
    • If you are installing a non-English Express Edition, download the matching language of the .NET Framework 2.0 language pack and save it into the x64 folder

    After following one of the above sets of steps to download the necessary prerequisite packages, you can do the following to repair the prerequisites and the Express Edition:

    • Launch Express Edition setup from Add/Remove Programs
    • Choose the radio button labeled Repair or Reinstall and click Next
    • Choose the radio button labeled Yes, I have the installation media
    • Browse to the folder that is similar to the following - C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual C# 2005 Express Edition - ENU.  The exact name of this folder will vary based on which Express Edition you have installed and where it is installed.
    • Click Install and repair will begin using the prerequisite packages you previously downloaded and saved in the WCU folder underneath the folder you browsed to


  • Aaron Stebner's WebLog

    .NET Framework 2.0 Japanese language pack is now available


    The .NET Framework 2.0 Japanese language pack is now available for download.  This page has more information about the language pack (the text is in Japanese) and you can download the language pack setup package from this location.

    I would also like to provide some helpful information about the setup package for the .NET Framework 2.0 Japanese language pack if you will be installing it as a part of your setup package:

    Silent install command line parameters

    The command line to silently install the .NET Framework 2.0 langauge packs is slightly different than it was in the .NET Framework 1.1.  Here is the command line syntax you should use to silently install the 2.0 language packs:

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

    Note that the same command line parameters that I documented for the .NET Framework 2.0 apply here, because the same setup wrapper is used for the language packs as for the core redistributable package.

    This command line will be the same for all additional .NET Framework 2.0 language packs when they are released.

    Detecting whether or not the language pack is installed

    You should use the following registry key/value to determine whether or not the .NET Framework 2.0 Japanese language pack is installed:

    • Registry root: HKEY_LOCAL_MACHINE
    • Key name: Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\1041
    • Value name: Install
    • Value data type: REG_DWORD
    • Value data: 1

    You can also use the same set of return codes that I documented for the .NET Framework 2.0 to determine success or failure of language pack installation, because the same setup wrapper is used for the language packs as for the core redistributable package.

    When the remaining .NET Framework 2.0 language packs are released, the detection method will be the same except the key name listed above will be the 4-digit language code corresponding to the language in question instead of 1041 (which is the language code for Japanese).

    Should I install the Japanese language pack with my Japanese .NET Framework application?

    The general answer to this is "yes."  The .NET Framework 2.0 is separated into a core and multiple language packs, and the common-language runtime (CLR) is MUI-aware.  That means that the CLR will use the OS language preferences to determine what strings to load when running managed applications.  If the language pack for the preferred language is not installed on the system, the CLR will fall back to the English string resources installed as part of the core .NET Framework 2.0 redistributable package.

    The .NET Framework 2.0 language packs provide localized string resources for the following:

    • Exceptions thrown by .NET Framework class libraries that are not caught by the calling application
    • Compiler messages from managed code compilers (such as csc.exe and vbc.exe)
    • Usage information for managed code tools that ship as part of the .NET Framework redistributable (such as caspol.exe)


  • Aaron Stebner's WebLog

    Resolving error creating smart device projects in Visual Studio 2005


    I heard from a customer this week who uninstalled all beta versions of Visual Studio 2005 and then installed the final release.  After doing this, he saw an error when trying to create a Smartphone 2003 Smart Device project using Visual C#.  The following error message consistenly appeared when trying to create the project:

    This project requires .NET Compact Framework v1.0, which is not installed on this machine.

    Visual Studio 2005 setup has logic to automatically install the .NET Compact Framework 1.0 SP3 and .NET Compact Framework 2.0.  The customer verified that .NET Compact Framework 1.0 SP3 is installed on his system by checking in Add/Remove Programs.

    The customer was able to resolve this problem by doing the following:

    1. Go to Add/Remove Programs and uninstall the version of Microsoft .NET Compact Framework 1.0 that you have installed
    2. Go to your Visual Studio 2005 installation DVD, and re-install the .NET Compact Framework 1.0 SP3 by running NETCFSetupv1.msi from the folder \wcu\NetCF

    There are some cases where beta versions of Visual Studio 2005 install an incompatible version of the .NET Compact Framework 1.0 SP3.  The MSI for this product has not changed since the early beta phase of VS 2005, so the cleanup tool does not attempt to uninstall it.  If you have installed very early beta versions of VS 2005, you might run into this error and the above steps should resolve it for you.


  • Aaron Stebner's WebLog

    Trick for setup developers - how to remove a setup package with a known uninstall bug


    I was recently working on developing an MSI-based setup package as a learning exercise to teach myself some of the fundamental concepts of Windows Installer XML (WiX).  During this process, I created a test MSI package and tried to install it on my development machine.  Then, when I tried to uninstall it, I found that one of my launch conditions was being triggered incorrectly, which blocked me from being able to uninstall the package.

    It was relatively simple to figure out why the launch condition was incorrect and fix it in my MSI package - I needed to schedule the AppSearch action to occur before LaunchConditions (since one of my launch conditions needed to use the results of one of my app searches) and also condition my AppSearch so it would happen in repair/uninstall cases and not only during initial install.  However, I was stuck with the buggy version of the MSI installed on my development machine and blocked from uninstalling it.

    I found a couple of options that allowed me to fix my development machine and work around the buggy uninstall logic that I had introduced and I wanted to share them here in case they are useful to any other setup developers reading this:

    1. Forcibly install a fixed version of the MSI - for this option, I took my newly fixed MSI that no longer had the uninstall bug and ran the following Windows Installer command line to force it to be installed over the top of the buggy one that was stuck on my system: msiexec.exe /fvecmus my_product.msi.  This command line forcibly replaced the old installation with the new one by running from the source MSI and recaching the copy of the MSI in %windir%\installer.  This removed the bug that blocked uninstall, and after that I was able to launch uninstall from Add/Remove Programs and everything worked as expected for me.
    2. Manually edit the cached MSI - for this option, I found the locally cached copy of the MSI in %windir%\installer (by looking at timestamps and finding the most recently created file in that folder), opened it in the Orca MSI editing tool, and then manually removed the entries from the LaunchCondition table that were blocking uninstall from running.  This option can be used to fix simple errors, but complex errors will likely be difficult to manually fix in an MSI editor such as Orca.


  • Aaron Stebner's WebLog

    Administrative tools shortcut has moved to the SDK in .NET Framework 2.0


    Some of you have noticed in the beta program or when installing the final release of the .NET Framework 2.0 that there are no longer any configurations or wizards shortcuts installed into the Administrative Tools program group in .NET 2.0 like there were in 1.0 and 1.1.  The .NET Framework team decided sometime during the development cycle for .NET 2.0 that these shortcuts were not really appropriate for a runtime redistributable program, and so the shortcuts were removed from the .NET Framework 2.0 redistributable and a configuration shortcut was added to the .NET Framework 2.0 SDK.  The wizards shortcut was cut in .NET 2.0 so you will no longer see that installed by any member of the .NET 2.0 or VS 2005 product family.


  • Aaron Stebner's WebLog

    How to resolve errors running Visual Studio on Windows Media Center


    I have heard from a few folks who have run into issues trying to install and run Visual Studio on the Windows Media Center 2005 OS.  One of the most common errors reported in this scenario is the following:

    The application for project '<project_name>.csproj' is not installed. Make sure the application for the project type (.csproj) is installed.

    This error will occur when trying to create or open a C# project in the Visual Studio IDE.  When I looked into this further on one customer's machine, I found that the root cause was similar to an issue I wrote about in this previous blog post.  In this scenario, the underlying problem occured when upgrading a system with Media Center 2004 and the .NET Framework 1.1 installed to Media Center 2005.  This upgrade scenario will cause %windir%\system32\mscoree.dll to be reverted from the .NET Framework 1.1 version to the .NET Framework 1.0 version, which breaks a lot of functionality that depends on the .NET Framework 1.1.

    If you run into this error when using the Visual Studio IDE, I suggest trying the workaround described in this blog post to uninstall and reinstall the version of the .NET Framework that is associated with the version of Visual Studio that you are using (.NET Framework 1.0 for Visual Studio .NET 2002, .NET Framework 1.1 for Visual Studio .NET 2003, or .NET Framework 2.0 for Visual Studio 2005).

    Please note that although I have described an upgrade scenario that will only happen on the Windows Media Center OS, this error could also happen on a non-Media Center OS as well.  The workaround has proven helpful in resolving this error in non-Media Center OS scenarios as well, so I suggest you try it if you run into it on a non-Media Center OS too.


  • Aaron Stebner's WebLog

    .NET Framework 2.0 source caching for repair mode


    Several folks have installed the final release of the .NET Framework 2.0 and then contacted me asking about a set of files that gets installed to the folder %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0 that they did not see installed with the .NET Framework 1.0 or 1.1.  I wanted to take this chance to explain some of the history that led to this behavior in .NET Framework 2.0 setup.

    The short explanation

    The files in this folder are a copy of the original setup files that are being stored by the .NET Framework 2.0 setup to allow you to repair the product later on without requiring you to re-download the original source setup package (dotnetfx.exe).

    The long explanation

    The .NET Framework is packaged as a self-extracting executable.  That means that when you run setup by double-clicking dotnetfx.exe or by installing some other application that runs dotnetfx.exe behind the scenes, setup extracts itself to a folder created on the fly in the %temp% directory, installs from there and then deletes the folder in %temp% that it just installed from. 

    By default, Windows Installer will store the source location that a package is installed from in the registry and then use that if it detects that any of the components are broken and needs to repair.  In the .NET Framework 1.0 and 1.1, after installation completed, the source location registered by Windows Installer was deleted and any future repair request would prompt the user to browse for the file netfx.msi and list the default path as %temp%\IXP000.tmp (the temporary folder that is deleted at the end of setup).

    This means that all resiliency repairs in .NET 1.0 and 1.1 will prompt for a path if they are invoked in UI mode, and they will fail silently if they are invoked in silent mode.  This also means that there is not a repair option if you look at the Add/Remove Programs entry for .NET 1.0 and 1.1 because there is not a guarantee that source files would be available to use to perform the repair.  To compensate for this limitation, we shipped a file named %windir%\Microsoft.NET\Framework\v1.0.3705\repair.htm and %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm to describe how to perform a manual repair of the .NET Framework if needed.

    After .NET 1.0 and 1.1 shipped and we started releasing hotfixes and service packs, this repair scenario became very bad.  When trying to install a patch, Windows Installer performs a component health check, and if anything is detected as broken, it will trigger a resiliency repair.  Because of the source files being deleted during installation as described above, the resiliency repair will fail or prompt for a path.  In most cases, .NET Framework hotfixes are installed silently via Windows Update.  Since setup is run in silent mode, any resiliency repairs will fail with no indication about why, and then the only message seen on Windows Update is a generic message that the .NET Framework hotfix failed to install.

    How source caching works in .NET Framework 2.0

    In the .NET Framework 2.0, we designed a feature to allow setup to store copies of the original installation files on the hard drive so that resiliency repairs could happen automatically and to allow the user to initiate a repair from Add/Remove Programs.  This strategy was inspired by the Office setup team's local cache feature.  The files that are used during the original setup are authored into the MSI and installed to %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0 during the initial setup.  In addition, the Add/Remove Programs entry is authored to point to the copy of install.exe in this folder instead of to the default msiexec /x command.  Finally, a Windows Installer API available starting in Windows Installer 3.0 (MsiSourceListSetInfo) is called to register the source path for the installation to be this folder instead of the default location (which in this case is the path that setup is originally run from that gets deleted automatically at the end of installation).  Calling this API allows resiliency repairs to occur without any user intervention.

    When we start releasing hotfixes for the .NET Framework 2.0, we expect to see a significantly lower failure rate, especially for hotfixes installed via Windows Update.  This lower failure rate will be partly due to the work done to store the source files for the .NET Framework 2.0 because it will make it much more likely that the .NET Framework will not fail the initial health check during hotfix installation, and even if it does, the resiliency repair will be able to silently succeed and allow hotfix setup to proceed in cases where it would have otherwise failed in .NET 1.0 and 1.1.


  • Aaron Stebner's WebLog

    KB910393 has been removed from Windows Update


    As I described in this blog post, we found an issue with a Windows Media Player hotfix (KB910393) if it is installed after KB908250 for Media Center 2005 and there is not a reboot in between them.  We have heard from a lot of people impacted by this issue ever since KB910393 went live on Windows Update (which happened on Tuesday, November 29).  So we have decided to temporarily remove KB910393 from Windows Update while we weigh our options and figure out the best possible fix.  If you visit Windows Update on a Media Center 2005 computer with Update Rollup 2 installed, you should not see KB910393 offered as a critical update as of some time earlier this afternoon.

    If you have already run into this interaction issue, you can use the workaround I listed in this blog post.  There is no need for you to uninstall KB910393 if you already have it installed.


  • Aaron Stebner's WebLog

    WinFX December CTP is available for download


    I was getting my laptop ready to take with me for the holidays (because my parents have a 56K modem that is not ideal for working on projects in an online setting), and one of the things I decided to install is the latest WinFX runtime and SDK so I can take a look at the development tools that are included with the WinFX platform and Vista.  I found that there is a new December 2005 CTP that just went live today.  You can get full details on the WinFX beta page.

    You will need to uninstall any previous WinFX beta versions that you might have previously installed (but there is an uninstall tool to automate this if you choose).  The good news is that this December 2005 CTP is compatible with the released version of the .NET Framework 2.0 and Visual Studio 2005, so if you already have the released version of those products you can leave them on your system.  The better news is that unlike the November CTP, the December CTP can be installed and used on Windows Vista.  However, it requires the December CTP of Windows Vista as well, and installation will likely fail if you try to install WinFX on any of the previous CTP builds of Vista.

    Here is a cheat sheet for what pieces of WinFX you should choose to install and what order you should install them for various WinFX scenarios:

    1.  Execution of WinFX applications only

    2.  SDK-style WinFX development

    3.  IDE-style WinFX development


Page 1 of 1 (22 items)