Aaron Stebner's WebLog

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

April, 2005

  • Aaron Stebner's WebLog

    Version of VS 2005 beta cleanup tool now available on the Download Center


    The most recent version of the VS 2005 cleanup tool has been posted to this location on the Microsoft Download Center.  This version matches the version on my WinISP site as of right now, plus it is digitally signed and posted as an EXE instead of a ZIP file so it does not have to be saved to the desktop and unzipped before you can use it.  This version on the Download Center will likely not be updated until VS 2005 releases because it has proven to work correctly in beta 1 and CTP uninstall scenarios.  I will update the version on my WinISP site if/when any additional beta 1 or CTP issues are found in the future.  We are currently working on updating the uninstall instructions on the VS 2005 site to include a link to this tool and more specific instructions, so stay tuned for that.

    5/1 UPDATE: The new uninstall known issues page has been posted.  You can view it by clicking this link.


  • Aaron Stebner's WebLog

    Channel9 interview with Jim Allchin


    I just got word from a couple of friends that there is a nearly hour-long interview with Jim Allchin (Microsoft group vice president, in charge of Windows among other things) posted up on the Channel9 site.  I listened to a bunch of it and there are some really interesting insights.  It is a big video (~200 megs) but if you have the bandwidth to handle it I highly recommend giving it a listen.  The Channel9 page also has a handy index so you can skip directly to questions that sound most interesting if you want to.


  • Aaron Stebner's WebLog

    Update about J# redistributable package installation in VS 2005 setup


    Now that Visual Studio 2005 beta 2 has been released, I have gotten a handful of questions about my blog post from last August explaining why VS setup forces the user to install the J# redistributable package when they don't intend to do J# development in the IDE.  In that blog post I explained the reasons behind the behavior in VS .NET 2003 setup and also stated that it was being changed in VS 2005.  Some folks have noticed that running VS 2005 beta 2 setup and unchecking the J# language tool item in the setup selection tree still results in setup installing the J# redistributable package.  A couple of other folks wondered why there wasn't a separate check-box in the setup selection tree to turn off the J# redistributable package.

    Back when I wrote that blog post, the code hadn't yet been written to allow us to make the J# redistributable package an optional component, so I couldn't elaborate on exactly how VS 2005 setup would work with respect to that component because it was only a conceptual design.  Now that the code has been implemented, I wanted to explain exactly how VS 2005 setup controls the installation of the J# redistributable package.

    First of all, the J# redistributable package is one of a group of components that can be thought of as "feature-dependent chained components."  Other examples of this type of component include the VS Tools for Office Runtime and the .NET Compact Framework.  All of these components are required prerequisites for specific features that the user can select or deselect in the VS setup selection tree.  Because they are required, we decided to not show them as items in the tree themselves or provide checkboxes to allow the user to uncheck them.  The only indication setup gives that they will be installed is in the UI on the install progress page.

    The tricky part about these feature-dependent chained components is that there is no way to tell in setup UI which feature(s) require the component.  In the case of the J# redistributable, most people would expect that it is only needed by the J# language tools and are naturally surprised if they unselect J#, click Install Now and still see the J# redistributable package in the list of components to be installed.

    What happens behind the scenes is that setup looks at data listed in the file baseline.dat (which is located in the setup subdirectory on the VS 2005 DVD or CD1).  That file has a set of attribute/value pairs for each component that setup might need to install.  For example, the J# redistributable package is listed as [gencomp68] in baseline.dat in VS 2005 beta 2.  Components that are feature-dependent chained components have their ComponentType value set to 3 and also contain an attribute called DependentFeatures.  The value of the DependentFeatures attribute is a semi-colon separated list of GUIDs, and each GUID represents a possible FeatureID in the Feature table of the VS MSI (vs_setup.msi).  When the user presses Install Now in VS setup UI, the setup engine processes each of those FeatureID values and determines whether or not they were selected in the setup tree.  If at least one of those features was selected, setup will add the feature-dependent chained component to the list of items to be installed.

    In the case of the J# redistributable, if you use Orca and manually search for each of the DependentFeature GUIDs in vs_setup.msi, you will see that Visual Web Developer also requires the J# redistributable (because you can create web projects using J# in addition to VB and C#).

    In the case of the J# redistributable package, there is also a secondary check in the VS IDE.  So if you have J# and/or Visual Web Developer installed and then uninstall the J# redistributable package, you will see an error message indicating that the J# redistributable was not found.  Dismissing that will give a secondary error message stating that the Visual J# Language Service Package has failed to load.  If you press Yes to this package load failure dialog, the IDE should not attempt to load the Visual J# Language Service Package in the future and you should not see these errors when launching the IDE anymore.

    In summary and to make a really long story short, if you uncheck both J# and Visual Web Developer during VS 2005 beta 2 setup, you should not see the J# redistributable package installed.


  • Aaron Stebner's WebLog

    Summary: using the VS 2005 beta cleanup tool to prepare a machine to use VS 2005 beta 2


    I have posted bits and pieces of information in different blog posts about the issues we have found on customer machines during the process of removing VS 2005 and .NET Framework 2.0 beta 1 and installing VS 2005 and .NET Framework 2.0 beta 2.  I wanted to write an overall summary that explained all of the issues and outlined how and when to use the beta cleanup tool in one place now that things have settled down a little bit and we have discovered most of the major issues and added steps to the cleanup tool to address them.

    Information about the VS 2005 beta cleanup tool

    1. What is the cleanup tool?

      The VS 2005 beta cleanup tool is an automated tool that is designed to resolve common issues seen by customers while trying to uninstall VS 2005 and .NET Framework beta 1 or Community Tech Previews (CTPs) and install VS 2005 and .NET Framework beta 2.  It automates the officially published uninstall steps for
      Express Editions and for other versions of VS.  It also automates cleanup of various files and registry keys that are known to cause problems if beta 1 or a CTP has already been uninstalled in a different order different than the uninstall steps describe.
    2. Where can I find the cleanup tool?

      The VS 2005 beta cleanup tool can be downloaded from
      this location.  It is packaged as a ZIP file, and the tool itself is a self-extracting EXE inside of the ZIP file.  If future problems are found and the tool has to be revised, it will be updated and made available at the same download location.
    3. How can I run the cleanup tool in silent mode with no UI?

      If you want to run the cleanup tool silently and avoid displaying any UI to the user, you can do the following:

      • Download vs2005_beta_cleanup_tool.zip
      • Extract vs2005_beta_cleanup_tool.exe from inside the ZIP package
      • Run the following command line:  vs2005_beta_cleanup_tool.exe /c:"cleanup.exe /p Visual Studio 2005 Beta 1"
      • The cleanup tool will produce log files in the %temp% folder named cleanup_actions.log, cleanup_errors.log and cleanup_main.log
      • Return code 0 indicates that the cleanup tool ran successfully; return code 3010 indicates that the cleanup tool ran successfully and the computer needs to reboot to complete removing files or folders that were in-use; any other non-zero return code indicates that the cleanup tool encountered an error
    4. What if the cleanup tool does not solve my problem?

    5. Why doesn't VS 2005 uninstall and reinstall work as expected?

      In most cases, we have found that .NET Framework 2.0 beta 1 was uninstalled before trying to uninstall VS 2005 beta 1.  If that happens, VS 2005 beta 1 uninstall fails to remove assemblies from the GAC because it needs the .NET Framework 2.0 beta 1 in order to perform GAC uninstallation.

      In other cases, we have seen Package Load Failures for Microsoft.VisualStudio.QualityTools.TestCaseManagement.QualityToolsPackage when launching the VS IDE.  This will occur if you uncheck the Team Foundation Client feature in the setup tree.  This can be fixed by re-running setup and adding the Team Foundation Client feature.


  • Aaron Stebner's WebLog

    VS 2005 beta 2 Package Load Failure that is not fixed by the cleanup tool


    We have discovered a case where one of the Visual Studio 2005 beta 2 Package Load Failure error dialogs will happen even after running the beta cleanup tool.  If you installed VS 2005 beta 2 and unchecked the item named Team Foundation Client in the setup feature selection tree, you will see an error loading the package named Microsoft.VisualStudio.QualityTools.TestCaseManagement.QualityToolsPackage when launching the VS IDE.

    To workaround this issue, you can locate the Visual Studio 2005 Team System Beta 2 - English item in the Add/Remove Programs control panel and launch setup again.  Then check the item named Team Foundation Client and update your installation.

    Please let me know if you have tried the cleanup tool and also installed the Team Foundation Client item in the setup tree and still see any Package Load Failures when using VS 2005 beta 2.


  • Aaron Stebner's WebLog

    Updated cleanup tool that fixes package load failures in VS 2005 beta 2


    I've posted an updated version of the VS 2005 and .NET Framework 2.0 cleanup tool that will fix Package Load Failure error dialogs that might occur after uninstalling VS 2005 beta 1 or any of the Community Tech Preview (CTP) versions and then installing VS 2005.

    You can click on this link to download the latest version of the VS 2005 beta cleanup tool.


    Post-cleanup steps

    One of the steps performed by this version of the cleanup tool removes some of the native images generated for VS 2005 beta 2.  These native images are used to improve the startup time when you launch the VS IDE.  You can regenerate these native images by running the following from a cmd prompt:

    • %windir%\Microsoft.NET\Framework\v2.0.50215\ngen.exe update /queue

    If you are using VS 2005 beta 2 for web development on a local IIS server, you may see that ASP.NET 2.0 extensions for IIS are missing.  In order to resolve this, run the following from a cmd prompt after running the cleanup tool:

    • %windir%\Microsoft.NET\Framework\v2.0.50215\aspnet_regiis.exe -i

    If the cleanup tool doesn't work for you

    The cleanup tool has been tested by several people inside of Microsoft who had been receiving errors when trying to use the VS 2005 beta 2 IDE.  However, I'm still not certain that it will correctly clean up 100% of machines that have previously had beta 1 or a CTP installed.  If you try to run the tool and still encounter errors while using VS 2005 beta 2, please try to gather the following data and post a comment on my blog or contact me directly and we will take a look:

    1. Run %programfiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe /log
    2. Gather the file \Documents and Settings\<your_username>\Application Data\Microsoft\VisualStudio\8.0\ActivityLog.xml for us to look at

    Why do these errors happen?

    If you are interested, I described the root causes of why certain uninstall/reinstall scenarios will encounter these problems in this blog post.


  • Aaron Stebner's WebLog

    Update on root cause of Package Load Failures in VS 2005 beta 2


    I got a chance to investigate a couple of machines from Microsoft employees who ran into issues after trying to uninstall VS 2005 and .NET Framework beta 1 and installing VS 2005 and .NET Framework beta 2.  The machines I looked at had problems because Package Load Failure dialogs appeared when launching the IDE or creating projects in VS 2005 beta 2.  I was able to fix the machines by doing the following;

    1. Locate all of the files in %windir%\assembly that had file versions starting with 2.0 or 8.0 where the 3rd part of the file version (not the assembly version) does not equal 50215 (the VS 2005 and .NET Framework 2.0 beta 2 build number)
    2. Open a cmd prompt and manually delete the files and folders that were in that list

    The most common problem I saw was that there were 2 copies of the file Microsoft.VisualStudio.Shell.Interop.8.0.dll in the GAC, one from beta 1 and one from beta 2.  For some reason, the beta 1 version takes precedence when devenv.exe launches and the VS IDE package fails to load.

    I am working on compiling a full list of assemblies that exhibit this behavior and once I get that, I will update my cleanup tool to automatically remove these files.  However, I probably will not be done until sometime tomorrow so I wanted to post a manual workaround in the meantime for anyone who reads this blog post.  Hopefully I'll be able to save some drive reformatting and make beta 2 installation and usage a little less painful.

    Technical details if you are interested

    In both cases that I investigated today, the .NET Framework beta 1 was uninstalled before VS 2005 beta 1, and that caused VS 2005 beta 1 uninstall to fail to remove some assemblies from the GAC because fusion.dll is used to install/uninstall assemblies and since fusion.dll was installed as a part of .NET Framework 2.0 beta 1, it was removed by the uninstall and was therefore not present to perform the GAC uninstall during VS 2005 beta 1 uninstall.

    This uninstall issue should cause all VS assemblies to be orphaned in the GAC.  However, installing VS 2005 beta 2 should update the versions of the files in the GAC because they have higher file versions in beta 2 than in beta 1 (since the bug I described here has been fixed).  But there is one critical issue that causes a few of the assemblies to not be updated.  In the case of the file Microsoft.VisualStudio.Shell.Interop.8.0.dll that I listed above, it contained metadata that identifed it as an MSIL assembly in beta 1, but the MSIL tag was removed for beta 2 for some reason.  So Fusion treats it as a completely different assembly and uses a different physical location on disk to store it in the GAC, and as a result the machine ends up with 2 copies of that file.  I haven't gotten a complete list of orphaned files yet, but my theory is that all of the other orphaned files are caused by similar metadata changes.

    Really in-depth technical details if you are really interested

    This problem theoretically exists for VS 2002/.NET 1.0 and VS 2003/.NET 1.1, but there is a design change we took in the .NET Framework 2.0 that makes this problem worse.  In 1.0/1.1, you will see the .NET Framework create a folder under %windir%\system32 named UrtTemp that contains copies of a few files that Windows Installer uses to install assemblies.  These files are needed because the .NET Framework contains the code needed to install assemblies using the MsiAssembly and MsiAssemblyName tables, but it also needs to install assemblies itself (the classic chicken-and-egg problem).

    In 2.0, we wrote a custom action to call fusion APIs directly to install assemblies because of a limitation in Windows Installer that would not let us use the DuplicateFile table if we needed to install files to the file system and the GAC.  This liimitation had caused us to carry 2 copies of each assembly in dotnetfx.exe, which caused the download size to be unnecessarily high.  In order to reduce size of the .NET Framework we had to use this custom action, which is why you see Assembly and AssemblyName tables in netfx.msi and do not see anything in the MsiAssembly and MsiAssemblyName tables.

    Because we implemented this custom action, we were also able to eliminate the part of setup that copied files to UrtTemp.  In the past, uninstalling .NET Framework would leave behind the files in UrtTemp so that assembly uninstall could be accomplished by using those copies of the fusion files.  However, in 2.0 we don't use UrtTemp so after 2.0 is uninstalled, there are no files left behind to use for future GAC uninstalls.  Visual Studio setup does not fail and rollback if GAC uninstall fails because we decided that if a user chooses to uninstall and files are left behind, we should not rollback and add all the files back to the machine.  For a released product that is probably OK, but for beta versions, that can cause orphaned files that interfere with future releases of the same product as seen above.

    The other complicating factor here is that the .NET Framework is a prerequiste for any application that is written in managed code (such as parts of Visual Studio), but we do not have any way of reference-counting the .NET Framework to prevent the user from uninstalling the .NET Framework out from under any applications that need it.  Because of this, even though we know that uninstalling .NET Framework 2.0 beta 1 will cause orphaned files when you try to uninstall VS 2005 beta 2 later on, we cannot prevent the user from performing the uninstall.  We have iterated over several proposed designs to create a reference-counting scheme but found too many confusing scenarios where we would pop up dialog boxes strongly suggesting that the user not uninstall, or scenarios where we block uninstall when we should not, or scenarios where 3rd party applications failed to increment reference counts because it requires extra work that was too obscure or difficult.  So for 2.0, we will have to live with this type of behavior.

    I suppose the ultimate answer will be close to what I always wanted to see - the .NET Framework is a system component that is not uninstallable.  You see that on Windows Server 2003 where .NET Framework 1.1 is part of the OS and is always present, and you will likely also see this on Longhorn for .NET 2.0.


  • Aaron Stebner's WebLog

    Visual Studio 2005 previous beta removal tool


    Hey all, I'm sorry for the delay posting this.  I've got a version of the cleanup tool that I wrote that I specifically tailored to automate that long list of removal steps listed here and here.

    You can download and try out the VS 2005 beta removal tool by going to this link.

    Note that this tool isn't "officially" supported by Microsoft or me.  That being said, please let me know if you have any trouble getting this to work on your computers.  My next step is to create a version of this tool that will automate all of the manual removal steps for the .NET Framework 2.0.  Stay tuned....

    As a side note, I was hoping to have it ready when VS 2005 and .NET Framework 2.0 beta 2 went live on Sunday, but obviously that didn't happen.  I apologize to the folks who have contacted me with broken machines and wasted days cleaning them up (and also those who have gotten burned by the manual uninstall but haven't contacted me).  I know it is not really any consolation now, but we're really working hard to do what we can to fix any broken machines without forcing you to reformat and also to get any of the underlying setup bugs fixed by the time VS 2005 ships.  Thank you for your patience and interest in VS 2005 and .NET Framework 2.0.


  • Aaron Stebner's WebLog

    Interesting article about Visual Studio 2005 shiproom process


    I stumbled upon a pretty interesting Eweek article while I was reading some of the internet coverage of the Visual Studio 2005 and .NET Framework 2.0 beta 2 release that happened yesterday evening.  The author of the article appears to have worked with some Microsoft folks while researching and writing the article, and based on the first few paragraphs it sounds like he attended at least one of the shiproom meetings leading up to the VS 2005 beta 2 release.  When I was on the VS and .NET Framework setup team, I attended shiproom towards the end of major shipping milestones for the VS 2002/.NET 1.0 and VS 2003/.NET 1.1 releases, and I can say that the impressions in the article are pretty accurate.  The shiproom meetings are not populated exclusively by developers as the article suggests.  There are representatives from program management, test, localization, user assistance, and other disciplines.  Actually I found that developers are sort of in the minority at these meetings.

    Most of the times when I attended shiproom, my role was to present the technical details behind the bugs in our setup features that we wanted to fix before the products shipped.  This can be challenging because you have to be able to rapidly get to the point and bring 50 people up to speed who have no knowledge of your features and explain what the defect is, why it was not found until now, what the customer impact is of fixing it (or not fixing it), what the fix is (sometimes down to the exact lines of code, particularly as it gets closer to the final day before sign-off), and the risk that making the fix presents in terms of causing regressions in other known working code.  Not only this, but you have to be prepared for basically any random question that might come up from anybody in the room while you explain any of the above.  And the tricky part of this is that you need to focus on keeping the focus of the conversation headed in the right direction because Microsoft folks seem to have a tendency to "rat-hole" or drill down really deeply to discuss a sub-point that is really minor in the overall scope of the issue being discussed.

    From my experience in shiproom, I found that it became pretty easy to pick out the bugs that the people presenting them did not really understand well.  It also became pretty easy to pick out the people who went into too much depth and quickly lost track of the bigger picture and couldn't explain customer impact to justify fixing a bug.  This tended to happen more to developers than other disciplines because they spend a lot of their time in the details of the code rather than looking at end-to-end customer scenarios, but everyone was susceptible, particularly those new to presenting at shiproom).

    The other interesting dynamic that I saw emerge in shiproom was that it appeared to me that achieving a leadership role in the meetings worked as a kind of meritocracy.  Basically, if you cared enough to show up regularly, and then showed good insights in the questions you asked or opinions you offered, others in the room would recognize this and start looking to you to step up and continue to offer opinions and help determine whether to accept or reject bug fixes.  Ultimately, there always needs to be a "moderator" (in the words of the author of the article) because sometimes discussions will get particularly heated or hopelessly off-track or folks just won't agree on an issue and the buck has to stop somewhere.  But it is really cool to see that individuals really can make a difference in the overall shipping process and it is also really cool to see that not just anyone can, but those that do really earn that privilege.

    Of course, all of the above is just my impression of the process and it may be somewhat different for VS 2005 since I haven't been in that group in a while.  It also probably varies somewhat from product to product.  But I thought it might be interesting for folks out there to see a bit of detail about how the process works.

    There is also a blog that the Developer Division Release Team maintains that might be interesting for more insights into the process of shipping VS and the .NET Framework.  The lead of that team is the "moderator" of shiproom and I've worked closely with most of the folks on that team.


  • Aaron Stebner's WebLog

    Visual Studio 2005 and .NET Framework 2.0 beta 2 now available


    I know I'm a little late jumping on this particular bandwagon and posting a blog item about it, but just in case you haven't seen yet, Visual Studio 2005 and .NET Framework 2.0 beta 2 are now available for download.  You can find more info at the VS 2005 Developer Center.  It looks like you can order a DVD for the Visual Studio Team System beta 2, but the VS 2005 Express Edition beta 2 versions can be downloaded from the developer center.  Also, if you are only looking for the .NET Framework redist package and/or SDK, you can download them at this .NET Framework site.

    Another interesting item listed on the beta 2 download site is a Go Live license that lets you use VS 2005 beta 2 and deploy your applications in a production environment in some cases.  Check out this link for more info.

    One thing I want to mention again, and I can't stress this enough - I really hope that you'll provide any feedback you have about these beta products (good or bad) at the MSDN Product Feedback Site.  I have seen the process for what happens to the issues reported to that site, and they all get reported to the product team's bug tracking tool.  And best of all, they all get looked at by real members of the teams.  So please let us know how things are looking and report bugs that we need to fix before VS 2005 officially ships or for future versions.

    Here are some useful links for setup problems you might encounter and some other known issues in beta 2:


  • Aaron Stebner's WebLog

    Uninstalling previous Visual Studio 2005 betas to prepare to install beta 2


    Now that Visual Studio 2005 and .NET Framework 2.0 beta 2 is about to be available, I wanted to communicate a couple of issues we have seen related to uninstalling previous beta and Community Tech Preview (CTP) versions that can cause problems when you try to install beta 2.

    Uninstall should be done in the reverse order of installation

    I'm sure you've noticed the large number of entries that are added to your Add or Remove Programs control panel after installing Visual Studio.  There are a lot of sub-products being installed silently as a part of Visual Studio setup and there are some specific ordering issues that are enforced during install because Visual Studio manages the chaining of the installation.  But the ordering is not enforced during uninstall.  The biggest problem we have seen is that uninstalling the .NET Framework before trying to uninstall Visual Studio, the J# redistributable, MSDN, or SQL Express will cause those other products to leave behind files in the GAC.  This is because the .NET Framework is the ship vehicle for Fusion, which is the technology that manages GAC install/uninstall.  So, in general the safest way to uninstall is to treat the list of products as a computer science stack and uninstall them in the reverse order they were installed.  Hong Gao, a program manager on the setup team, has posted sets of instructions on her blog for the Visual Studio 2005 Express SKUs and for other Visual Studio 2005 SKUs that I strongly recommend you follow.

    Update - Whidbey Beta 2 is now available, and there is now a more official list of uninstall steps and the correct order to uninstall in.  Click here to see the uninstall list/order.

    Uninstall for previous versions of the .NET Framework 2.0 may not be completely clean

    Most often, the way you will notice this issue is if you see a failure while installing a future version of the .NET Framework 2.0 after uninstalling a previous version.  You can find a detailed explanation for how to workaround this issue in my previous blog post.

    After installing Visual Studio, the IDE may fail to launch or you may see multiple Package Load Failure error dialogs

    This is caused by some known issues in previous beta and CTP versions related to installing native Win32 assemblies to the %windir%\WinSxS cache.  To workaround these issues please try the following steps:

    • From a cmd prompt, run eventvwr.exe
    • Go to the System event log and look for error logs with the event source SideBySide
    • Find the name of any assemblies mentioned in these entries in the System event log
    • Go to %windir%\WinSxS and rename the folders with names that are the same or similar to the entries in the System event log (for example *.VC80.*)
    • Launch Visual Studio 2005 setup again, and choose to repair the product

    As always, please let me know if any of these workarounds do not work for you.  Also, I strongly encourage you to use the MSDN Product Feedback site to report any bugs that you find with uninstalling previous versions or installing new versions.  I'll update my blog with other common issues and suggested workarounds as they arise.


  • Aaron Stebner's WebLog

    How to manually cleanup a failed .NET Framework 2.0 install


    In response to the blog article I posted last week where I provided a link to a .NET Framework manual cleanup tool, I got some questions about whether or not a comparable version is available for cleaning up the .NET Framework 2.0.  I am currently working on a couple of small work items in the code for the tool to enable it to work with 2.0, but in the meantime I wanted to post some manual steps.  I know there have been a lot of uninstall/reinstall issues because we have released an alpha, a beta and numerous Community Tech Preview (CTP) versions and not all of them will uninstall completely cleanly in order to allow a future beta version of 2.0 to install correctly.


    The following steps will help resolve .NET Framework 2.0 installation failures/hangs in most cases. Before proceeding please note these important caveats:

    • These steps will only work for the .NET Framework 2.0 installed by dotnetfx.exe (the MSI-based setup).  There is a version of .NET Framework 2.0 that is installed as part of the OS if you are running any pre-release builds of Windows codename Longhorn.  You should not use these steps on Longhorn.
    • These steps will damage the .NET Framework 1.0 or 1.1 if you have either of these versions installed on your computer.  This is because you are instructed to rename the file mscoree.dll that is shared by all versions of the .NET Framework.   If you have 1.0 or 1.1 installed, you will need to immediately install a later build of .NET Framework 2.0 to update mscoree.dll or perform a repair of the .NET Framework 1.0 or 1.1.  To repair .NET Framework 1.0 or 1.1, go to the Add or Remove Programs control panel, click on the link for support information, and then click on the Readme link.
    • If you are running Windows Server 2003, Windows XP Media Center Edition or Windows XP Tablet PC Edition, there is a version of the .NET Framework that ships as part of the OS.  In those situations, you cannot repair by using the instructions in Add or Remove Programs under the readme link.  In those scenarios it is strongly recommended that you immediately install .NET Framework 2.0 to provide an updated version of mscoree.dll.  If that is not an option, you must repair your OS to fix the issue.

    Steps to clean up a machine to fix a failed .NET Framework 2.0 installation:

    • Using Add or Remove Programs, locate any versions of the .NET Framework 1.2 or 2.0 and choose Remove to uninstall them
    • Using regedit, navigate to HKLM\Software\Microsoft\.NETFramework and delete any keys and values that have 1.2 or 2.0 in it, including keys/values that are in subkeys underneath .NETFramework.
    • Using regedit, navigate to the sub-hive HKLM\Software\Microsoft\.NETFramework\Policy and delete any key or value that has 1.2 or 2.0 in it. 
    • Using regedit, navigate to HKLM\Software\Microsoft\ASP.NET and delete any key or value that has 1.2 or 2.0 in it, including keys/values that are in subkeys underneath ASP.NET. 
    •  Right-click on My Computer and choose Manage. Expand Computer Management (Local), then Local Users and Groups, then click on the Users folder. In the right-hand pane, right-click on the ASPNET user account and choose Delete to remove it.
    •  Go to %windir%\assembly and delete anything with *1.2* or *2.0* in the folder name. Delete the GAC_32 and GAC_MSIL folders as well.

      You can not view the contents of %windir%\assembly in Windows Explorer when the .NET Framework is installed.  In order to view the contents, you will need to set the following registry value and reopen Windows Explorer

      Key name:
      Value name: DisableCacheViewer
      Data type: REG_DWORD
      Value data: 1

      Note: You should remove the DisableCacheViewer value after you complete this step because this is only used for debugging purposes.

    • Go to %windir%\Microsoft.NET\Framework and delete any folders named v1.2.* or v2.0.* along with all of the files and subfolders they contain.  You may get errors when trying to delete some of the files because they are in use.  In most cases, rebooting the machine and trying again will work.  If not, you can rename the files to be <filename>.old and then delete them after a future reboot.
    •  Rename %windir%\system32\mscoree.dll to mscoree.dll.old.
    •  After doing all of this, try to install the previously failing version of the .NET Framework 2.0.

    If you have any trouble getting these steps to work correctly please let me know.  Also stay tuned for a future post once I get the cleanup tool updated to work with .NET Framework 2.0 and post it for download.


  • Aaron Stebner's WebLog

    Removal tool to fix .NET Framework install failures


    I wrote an application late last year that is designed to clean up computers that have problems getting the .NET Framework 1.0 or 1.1 to install correctly.  I have been working on refining the tool for the past couple of months, working out some bugs, adding additional cleanup features, etc.  The .NET Framework setup Product Support team has been using this cleanup tool for the past few months to help resolve many cases, and the internal Microsoft helpdesk has also started using it to solve internal cases where employees cannot get .NET Framework service packs or hotfixes to install correctly.  I have also been sending this tool out to individuals who email me via my blog and ask for help resolving setup problems - most commonly this is because of issues installing .NET Framework service packs or hotfixes such as MS05-004.

    Since I have been seeing really good success rates for using this cleanup tool and it has proven to speed up the process of resolving issues so customers can get the .NET Framework installed correctly and start using managed code on their computers, I decided to try to get a KB article written up with a copy of the tool that customers could download on their own without needing to contact me directly or call our PSS team.  The KB publishing process can sometimes take a while with technical reviews and things like that, so in the meantime I am going to post a link to the tool here on my blog.

    You can download the tool by visiting the .NET Framework Cleanup Tool User's Guide and using one of the download links listed there.

    There are a couple of very important caveats that you should read before using this tool to cleanup .NET Framework bits on your machine:

    1. You should try to perform a standard uninstall first.  This tool is not designed as a replacement for uninstall, but rather as a last resort for cases where uninstall or repair did not succeed for unusual reasons.
    2. This cleanup tool will delete shared files and registry keys used by other versions of the .NET Framework.  So if you use it, be prepared to repair or reinstall any other versions of the .NET Framework that are on your computer to get them to work correctly afterwards

    The tool itself has been fairly well tested, but I'm sure it is still not perfect.  I'm still in the process of fixing bugs as I find them and adding features to make it more effective at cleaning up known issues and to make it more intelligent about identifying root causes so we can fix the underlying bugs in .NET Framework setup for future releases.  As I update it, I will post updates to my blogs and update the copy of the tool located at the link above.

    I hope this tool will be helpful in resolving problems installing the .NET Framework.  Please let me know if you run into any issues while using the cleanup tool or if you are still unable to install the .NET Framework (or any service packs or hotfixes) after running it.

    <update date="3/3/2009"> Added a link to the .NET Framework Cleanup Tool User's Guide, which contains the most up-to-date download location for this tool. <update>


  • Aaron Stebner's WebLog

    Better detailed instructions for chaining Visual Studio, Prerequisites and MSDN


    Ever since I posted my original instructions for chaining unattended installation of the Visual Studio .NET Prerequisites, Visual Studio and MSDN, I have had a few customers who tried these steps out and had problems getting the steps to work.  So as a result I want to write a new post where I give better detail and clarify each of the steps to make this unattended installation process easier to understand and implement.

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

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

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

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

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

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

    There are a couple of advanced tricks that you can use when creating these unattend scripts as well:

    1. If you want to perform a full install of MSDN to the local hard drive instead of a default installation, you can read the steps at this blog post to learn how to update your vs.ini file to call MSDN setup with the correct parameters to accomplish this.
    2. If you want to run the unattended installation via a batch file or script and wait for the process to exit and check the return code, you will notice that by default Visual Studio setup copies itself to the %temp% folder, kills the current process and restarts to perform the actual installation.  This logic breaks batch files or scripts that listen for return codes.  To prevent setup from copying itself to the %temp% folder and starting a new process, you can open up setup.sdb in the \\server\vs2003\vs\setup folder, locate the [Product Information] section, and add the following line to that section:  NoInitialFileCopy=1.  You must add this entry to setup.sdb before you create any of the INI files above.

    As always, let me know if you have questions or problems with any of the above steps....


  • Aaron Stebner's WebLog

    Why does .NET Framework setup hang for several minutes with the progress bar full?


    If you have ever installed the .NET Framework 1.0 or 1.1 package by running dotnetfx.exe directly (as opposed to installing it silently via Windows Update or via an application that redistributes it), I'm sure you've seen strange behavior where it appears to hang for several minutes right before setup completes.  Normally when this happens the progress bar is full or very nearly full and the time remaining says "0 seconds" (or possibly it hits one of my favorite Windows Installer bugs and says "1 seconds").

    During this time, setup is not actually hung.  The .NET Framework setup is running several custom actions to launch ngen.exe to generate native images (also called pre-jitting) for several .NET Framework assemblies.  Depending on the speed of the machine that setup is running on, this process can take several minutes. 

    Unfortunately we also shipped with a couple of problems in the .NET Framework setup package that prevented us from updating progress while this was going on:

    • We neglected to author action text for some of these custom actions in the ActionText table of the MSI.  The action text is what Windows Installer uses to show messages above the progress bar during setup, and if there is not action text for a particular action it does not update the message for that action, which can create the impression that setup is hung.
    • We did not include any ability to provide live progress bar updates while running these ngen.exe custom actions.  These custom actions call an executable that is installed as a part of the .NET Framework.  In order to update the progress bar, a custom action has to interact directly with Windows Installer in the code, and ngen.exe does not do that.  If you are interested in reading more about how to interact with the main MSI progress bar from within a custom action, there is a really good doc on MSDN with step-by-step instructions and some sample code.  Check it out by clicking here.

    So the bad news is that setup sometimes looks hung towards the end for the .NET Framework 1.0 and 1.1.  The good news is that there was some custom action work done specifically around how we do native image generation in the .NET Framework 2.0 and partially as a result of this, progress UI now looks and behaves interactively for the entire length of setup and doesn't appear hung at the end anymore.

    Ironically, when we install the .NET Framework as part of Visual Studio setup, we are able to give a more realistic sense of progress because of the "fake progress" strategy we implemented there.


Page 1 of 1 (15 items)