Aaron Stebner's WebLog

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

August, 2005

  • Aaron Stebner's WebLog

    How to locate the cause of error code 1603 in a verbose MSI log file


    There is a trick I use very often when trying to figure out why an MSI-based setup is failing that I wanted to share with everyone.  I believe it is commonly known among setup developers and people who have to troubleshoot failed setups, but I could not find any "official" documentation for it.  This trick helps narrow down the root cause of error code 1603, which is a generic catch-all error code that means "fatal error during installation".  The 1603 error code is returned when any action fails during an installation, and most commonly it indicates that one of the custom actions in the MSI failed.

    When I encounter a failed setup with return code 1603, here are the steps that I follow:

    1. Re-run the setup with verbose logging enabled using steps similar to those that I listed here (if there is not already a verbose log file available).  Those steps will generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed.

      Important note - some MSI-based setups, including the .NET Framework 2.0, 3.0, 3.5 and higher and Visual Studio, will not create log files named %temp%\msi*.log even if using the instructions listed below.  Please see this blog post for more details about why that is the case and also for a list of some products that I know of that use different log file creation logic and the locations of the log files that they create.

    2. Open the verbose log in a text editor such as notepad and search for the string "return value 3".  In nearly all cases, this takes me to the section in the verbose log that lists the action that failed that initially caused setup to rollback.
    3. Review the contents of the log file immediately above the "return value 3" string to determine which custom action or standard action failed.
    4. Depending on which action is failing, I will proceed to more detailed debugging from here

    I find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for "return value 3" ends up helping speed this process up in nearly all cases.  Of course, it does not work in 100% of scenarios.  Notably, if you are running setup on a non-English version of Windows, the string "return value 3" is written to the log file in the language of the operating system instead of in English, so string searches will not work.

    Also note that there is an MSI verbose log parsing tool in the Windows Installer PSDK that is also very useful in locating errors inside verbose log files.  You can read more about this parsing tool (called wilogutl.exe) by clicking here.  This tool is more thorough in identifying errors, but most often I end up not using it because it is faster to open the log in notepad and do a string search than it is to load up the parsing tool, browse to the log file, wait for it to parse the whole log and then read the output it produces.

    <update date="1/21/2009"> Added a caveat to these instructions indicating that some setups create their own verbose logs and enabling verbose logging using the Windows Installer logging registry keys will not work as expected for those setups. </update>


  • Aaron Stebner's WebLog

    How to fix some 1935 errors with HRESULT 0x80070005 (access denied) when installing the .NET Framework


    I was contacted by a customer this week who could not install the .NET Framework 1.1 due to a 1935 error that was not described in my previous blog posts (here and here for example).  The exact error was the following:

    MSI (s) (E0:80) [12:44:29:575]: Product: Microsoft .NET Framework 1.1 -- Error 1935.An error occurred during the installation of assembly 'Microsoft.Vsa.Vb.CodeDOMProcessor, Version="7.0.5000.0", PublicKeyToken="b03f5f7f11d50a3a", Culture="neutral", FileVersion="7.10.3052.4"'. Please refer to Help and Support for more information. HRESULT: 0x80070005. assembly interface: IAssemblyCacheItem, function: Commit, component: {7D4B5591-4C80-42BB-B0E5-F2C0CEE02C1A}

    As I described here, the HRESULT value 0x80070005 means "access denied".  Typically this happens due to a permission (ACL) problem on one of the directories under \windows\.  But in this case, the customer tried to reset the permissions and re-run setup but got the same error.

    I suggested looking at any anti-virus or anti-spyware software because they tend to lock down files and folders to prevent malicious programs from installing themselves, and it is very hard to detect the difference between a trusted setup program and a malicious one.  The customer found that they had the Sophos anti-virus program installed.  They were able to successfully install the .NET Framework 1.1 by stopping the Sophos service (sweepsrv.sys) and then running .NET Framework setup.

    Note that in this type of scenario, you should be very careful when stopping anti-virus and anti-spyware software.  What I typically do is the following:

    1. Download the setup package I want to install
    2. Disconnect from the network
    3. Stop anti-virus and anti-spyware software
    4. Install the software I downloaded in step 1
    5. Restart anti-virus and anti-spyware software
    6. Reconnect to the network


  • Aaron Stebner's WebLog

    How to manually reset folder and file permissions in Windows Explorer


    As I was typing out an earlier blog entry about resolving access denied (0x80070005) errors that can happen while installing the .NET Framework, I was intending to link to a post that listed the steps you can take to reset permissions (ACLs) for folders, files and registry keys.  Then as I searched through my previous blog posts I couldn't actually find a post where I listed those steps, so I figured I should list them as a standalone post.

    Resetting folder/file permissions

    1. Launch an instance of Windows Explorer
    2. Navigate to the parent of the folder that you want to reset permissions for
    3. Right-click on the folder and choose Sharing and Security...
    4. Click on the Security tab
    5. Click the Advanced button
    6. Set the permissions you want - typically you will want to allow Administrators, System, and Creator Owner to have full control
    7. Check the box labeled Replace permission entries on all child objects with entries shown here that apply to child objects
    8. Click OK
    9. Click Yes in the dialog box that appears asking if you are sure
    10. Wait while Windows recursively applies the specified permissions to all sub-folders and files

    Also note that there is a tool named subinacl.exe that can be used to automate the process of resetting folder, file and registry permissions so that you don't have to use the set of steps listed above.


  • Aaron Stebner's WebLog

    How to workaround errors installing .NET Framework 2.0 that are caused by registry permission problems


    I have had a few customers report problems installing the .NET Framework 2.0 with the following symptoms:

    • .NET Framework 2.0 setup fails and rolls back with no specific error message, just a generic "setup failed" message at the end
    • The action that fails is "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscoree.tlb" or "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscorlib.tlb" (you can find the error by using the steps described here)
    • The error code listed in the log file %temp%\dd_netfx20msi*.txt is 8002801c

    Examples of this problem are the comments located here and here, and the Product Feedback Center bugs located here and here and here.

    The underlying problem is that the Administrators group somehow was only granted read permission to some of the registry keys under HKEY_CLASSES_ROOT on these machines.  When the .NET Framework setup tries to register type libraries, it needs to create some new values under HKCR and it fails because of a lack of permissions (8002801c means "error accessing the OLE registry").  I have been able to confirm that this is the problem by having one of the customers use RegMon, but I haven't been able to figure out how the permissions got modified to be this way.  Up until now I also haven't been able to figure out how to fully reset the permissions so that .NET Framework setup will work.

    Fortunately one of the customers who had this problem contacted us with a solution that worked for them, and I wanted to list it here in case others run into this same problem in the future.  Here are the steps to follow to repair permissions to workaround this issue:

    1. Download the SubInACL tool from this Microsoft site and install it.  By default it will install to c:\Program Files\Windows Resource Kits\Tools
    2. Go to the Start menu, choose Run and type cmd
    3. Type cd /d %ProgramFiles%\Windows Resource Kits\Tools to change directories to the folder that SubInACL is installed to
    4. Type notepad reset.cmd and press yes to create a new file named reset.cmd in c:\Program Files\Windows Resource Kits\Tools
    5. Copy and paste the following contents into reset.cmd and then save and close it (or download it from here and rename it from reset.cmd.txt to reset.cmd):
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
      subinacl /subdirectories %SystemDrive% /grant=administrators=f
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
      subinacl /subdirectories %SystemDrive% /grant=system=f
    6. Type reset.cmd and press enter to run the SubInACL tool (you will need to have adminstrator privileges for this to run correctly).  This tool will take several minutes to run
    7. After reset.cmd completes, try to install the .NET Framework 2.0 or VS 2005 again

    Hopefully this will help.  If you try this and still have trouble getting setup to work correctly for the .NET Framework 2.0 or VS 2005, please contact me.


  • Aaron Stebner's WebLog

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


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

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


  • Aaron Stebner's WebLog

    How to install VS 2005 and MSDN for VS 2005 on XP without SP2


    Microsoft has an internal program for testing hotfixes that apply to Windows XP SP1 that asks some employees to not install XP SP2.  Some of the people in this program have wanted to install VS 2005 and when they tried, they ran into the blocks in VS setup that require XP SP2 to be installed.  VS 2005 setup does not have any technical requirements on XP SP2, but the block is in place to encourage everyone to upgrade to SP2, and also to reduce the test matrix.  If you are running into this block and really need to install VS 2005 on a system that is running Windows XP without SP2, you can use the following steps.  Please note that these steps are not officially supported and I would recommend installing XP SP2 before installing VS 2005 if at all possible:

    1. Navigate to the setup subfolder on the VS 2005 DVD and run VS 2005 as follows to skip all prerequisite checks - setup.exe /NO_BSLN_CHECK

    Important note - if you use the above option, none of the prerequisites for Visual Studio 2005 will be installed.  You need to make sure to manually pre-install Windows Installer 3.1, the .NET Framework 2.0 and the MSXML 6.0 Parser using the setup packages located in the wcu subfolder on the VS 2005 DVD.  Failure to do so will result in errors during the VS installation process.


    1. Launch regedit.exe
    2. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows
    3. Change the CSDVersion value to be 512 or higher (0x0000200 in hexadecimal)
    4. Close regedit.exe and install Visual Studio 2005
    5. Rerun regedit.exe and change the CSDVersion value back to what it was originally

    Once VS 2005 is installed, you will run into a separate block while trying to install MSDN.  To workaround this, you can use the same registry-based workaround listed above, or do the following:

    1. Install Orca if you haven't already (you can get a copy here without downloading the whole Windows Installer PSDK)
    2. Copy the contents of the VS 2005 DVD to your computer
    3. Right-click on the file msdn.msi and choose Edit with Orca
    4. Go to Launch condition table and remove the row with the following data in the condition column: "(VersionNT>501) OR (VersionNT=500  AND ServicePackLevel>3) OR (VersionNT=501  AND ServicePackLevel>1)    The minimum operating system requirement is Windows 2000 SP4,  Windows XP SP2, or Windows Server 2003"
    5. Save and close msdn.msi
    6. Install MSDN from the local copy

    Note: after changing the CSDVersion registry key or modifying msdn.msi using Orca, you will need to use the following command line to install MSDN:  msiexec /i msdn.msi SETUP_EXE=yes

    <update date="8/26/2005"> I didn't specify clearly enough when I posted this last night that these steps are not "officially" supported, I must have been a little tired and left off the disclaimer I normally write when I post tips like this.  I've added it above.

    <update date="11/8/2005"> After receiving email from Fabrice based on the comments posted here, I realized that there is an additional step needed to install MSDN after using the workarounds listed above.  I've updated the steps accordingly </update>

    <update date="4/5/2006"> Added a caveat to option 1 above that you must manually install prerequisites in order to use this option </update>


  • Aaron Stebner's WebLog

    How to fix error installing .NET Framework 1.1 SP1 on a computer that has MS05-004 installed


    I recently encountered a .NET Framework setup problem that is not described in my previously published .NET Framework hotfix/service pack troubleshooting guide while doing some testing for the upcoming version of Windows Media Center.  I installed a computer with Windows XP Media Center Edition 2005, the .NET Framework 1.1 and .NET Framework hotfix 886904 (MS05-004).  Then I went to Windows Update and found that it detected that I needed to install the .NET Framework 1.1 SP1 and it classified this as a high-priority update.  When I tried to install it from Windows Update, it failed for me with a generic "installation failed" error message.

    Of course, being the setup geek that I am, I wanted to figure out what was happening behind the scenes.  So I downloaded the setup package for the .NET Framework 1.1 SP1 from this location and ran it with full UI (instead of letting Windows Update run it for me in silent mode).  When I did this, I saw this error message:

    .NET Framework 1.1 SP1 error dialog

    This error message started me on the right track to find the solution to my problem.  I decided to check in Add or Remove Programs first to see if there were any hotfixes for .NET Framework 1.1 listed, and I found one named Microsoft .NET Framework 1.1 hotfix (KB886904).  Once I uninstalled that hotfix and rebooted, I was able to return to Windows Update and successfully install the .NET Framework 1.1 SP1.

    Ordinarily, .NET Framework service packs have logic built into their setup packages to automatically uninstall hotfixes and then apply the SP.  That was not possible in this scenario because the fix for MS05-004 was not included in .NET Framework 1.1 SP1.  The underlying security vulnerability was found after .NET 1.1 SP1 was tested and signed off on within Microsoft but before it went live on Windows Update.  Since .NET 1.1 SP1 did not have this fix, it did not have knowledge of the hotfix package for MS05-004 and was not able to automatically remove it.  That is also why you see a new version of MS05-004 offered on Windows Update immediately after you install .NET Framework 1.1 SP1 (this time it is named KB886903 instead of KB886904).  Future service packs for the .NET Framework 1.1 will have the fix for this issue included, so you will not see this error message if, for example, you try to install the .NET Framework 1.1 SP2 on a computer with 1.1 and KB886904 installed in the future when 1.1 SP2 is available.

    It is unfortunate that this type of setup scenario leads to a generic failure on Windows Update and does not help the average user find the solution to the problem.  I am not sure how many computers will have the exact combination of .NET 1.1 + MS05-004 installed before trying to install .NET 1.1 SP1, but hopefully if anyone does run into this they will be able to use the lesson I learned above to resolve the problem.


  • Aaron Stebner's WebLog

    How Windows Installer handles file replacement logic for versioned and unversioned files


    I ran into an interesting problem yesterday where a team had built an MSI-based setup package, and they were seeing sporadic problems where some of the files failed to install.  They enabled Windows Installer verbose logging and this is an example of an entry for one of the files that was failing to install:

    MSI (s) (B4:4C) [11:30:07:906]: Executing op: FileCopy(SourceName=eulatxt|eula.txt,SourceCabKey=FILE1,DestName=eula.txt,Attributes=512, FileSize=29239,PerTick=32768,,VerifyMedia=1,,,,, CheckCRC=0,,,InstallMode=58982400,HashOptions=0, HashPart1=-1713153497,HashPart2=58557210, HashPart3=1046945815,HashPart4=871163290,,)
    MSI (s) (B4:4C) [11:30:07:906]: File: C:\WINDOWS\system32\eula.txt; Won't Overwrite; Won't patch; Existing file is unversioned but modified

    After I saw this, I took a look at the MSI package and I found that this MSI was divided into one component per file, and each component used the one file that it contained as the key path.  This led me to understand the root cause of this issue.  Windows Installer has a specific set of rules for file versioning and how it decides when to replace files when they already exist in the destination location.  Here are the possible permutations for file versioning:

    • In the case when the source and destination files are both versioned files, these rules are straightforward - if the key path file does not exist in the destination location or if it exists in the destination location and it is of a lower version, Windows Installer will install the component (and all of the files in it, including the key path).  If the key path file exists in the destination location and it is of an equal or higher version, Windows Installer will not install the component but instead only reference counts the component.  It becomes trickier when only one of the files is versioned or neither of them are.
    • In the case when only one file is versioned, Windows Installer will install the component (and all of the files in it, including the key path file) if the source file is versioned and the destination file is not (meaning it will replace an unversioned file with a versioned one).  It will not install the component but instead only reference counts the component if the source file is unversioned and the destination file is versioned (meaning it will not replace a versioned file with an unversioned one).
    • In the case when both files are unversioned and have file hashes (as in the scenario I was debugging yesterday), Windows Installer will compare the created time and the last modified time of the destination file.  If the times are the same, Windows Installer will compare file hashes of the source and destination files.  If the file hashes are different, Windows Installer will install the component (and all of the files in it, including the key path).  If the file hashes are the same, Windows Installer will not install the component but instead only reference counts the component.  This means that if the key path file already exists in the destination location but has been changed sometime after it has been created, Windows Installer will not update this file, even if it is carrying a different copy of the file as part of the setup package.  The intent of this logic is to prevent Windows Installer from overwriting data files that customers may have modified on their machine before running setup
    • In the case when both files are unversioned and do not have file hashes, Windows Installer will compare the created time and the last modified time of the destination file.  If the times are the same, Windows Installer will install the component (and all of the files in it, including the key path).  If the times are different, Windows Installer will not install the component but instead only reference counts the component.

    This particular MSI I was investigating was trying to update a text file named eula.txt in %windir%\system32.  In some test cases, the file did not exist, in some cases it existed and was identical and in some cases it existed and was different.  The 3rd and 4th versioning rules above explains why this problem would only occur on some test machines but not others.  This illustrates one of the problems with using an unversioned file as the keypath for a component, especially if the file could be shared by other products on the system.  The solution I recommended to the team hitting this problem was to move this eula.txt file to be installed as part of another component that installed to %windir%\system32 and had a binary file as a key path.  In general you have to be careful about installing multiple files in one component (because of the Windows Installer component rules), but in this case it is a simple text file, which mitigates some of the drawbacks of including multiple files in a component (complicated servicing and incorrect uninstall behavior being the main risks here).

    <update date="9/6/2005"> I listed the logic incorrectly that Windows Installer uses when both the source and destination file are unversioned.  I have updated the 3rd bullet above based on the feedback in Stefan's comment. </update>

    <update date="4/29/2008"> MSDN links in this post were broken, so I updated them to work again. </update>


  • Aaron Stebner's WebLog

    .NET Framework 2.0 setup bug related to registry permissions and regtlibv12.exe is now fixed


    A little while ago I wrote a post explaining how to report a bug in the .NET Framework and Visual Studio setup.  I tried to encourage everyone who read that post to report bugs they find instead of giving up on installing VS 2005, reformatting their hard drive, or something like that.  I wanted to share a concrete example of what can happen when you do report a bug.

    A little while after .NET Framework 2.0 beta 2 and VS 2005 beta 2 shipped, I heard from a couple of customers who could not get the .NET Framework 2.0 beta to install correctly.  It repeatedly failed and rolled back while trying to register type libraries.  I had not heard of anyone running into an issue like this in .NET 1.0 or 1.1 or in any of the previous beta builds of .NET 2.0.  In addition, none of the teams working on VS 2005 and .NET 2.0 had seen this problem during daily testing, official test passes, etc.

    I worked closely with one of the customers and we narrowed down the problem to missing registry permissions.  The typelib registration is done by a custom action inside of .NET Framework setup, and the custom actions were marked with a flag that caused Windows Installer to "impersonate" the logged in user and run the action with the same permission as the user who is running setup.  In nearly all cases, that works fine because .NET Framework setup requires that the user be an administrator in order for setup to launch and run correctly.  However, on this customer's machine the Administrators group did not have permissions to the HKEY_CLASSES_ROOT hive that is needed to register type libraries.

    This investigation gave us a cause for the setup failure, but not any ideas about how the machine got into that state so that we could try to come up with a solution.  One other customer who reported this same bug on the Customer Feedback website provided us a workaround (described here), but the steps were pretty involved.  After some brainstorming with the .NET Framework setup team and the Windows Installer team, we decided to try marking these type library registration custom actions to not impersonate anymore.  This would cause Windows Installer to run the actions in system context.  We created a hand-modified version of the .NET Framework setup and asked the customer to try it for us.  This version succeeded where all other .NET 2.0 setup packages had failed on his machine.

    Now we had a cause and a solution, but we still had not seen anyone inside of Microsoft reproduce this problem, and the teams were steadily nearing the time to lock down the .NET Framework 2.0 to prepare for shipping.  So we needed more data to justify fixing this bug.  This is where the Customer Feedback site and Watson reports (the dialog boxes that appear after an error or crash and ask if you would like to send the information back to Microsoft) came in.  We were able to look at data from bugs reported by customers on the Customer Feedback site to determine that this particular .NET setup problem was not an isolated incident.  Then, we were able to look at data reported back to Microsoft when customers received errors during .NET 2.0 setup and chose to send the report back to Microsoft.  As Quan (a program manager on the VS and .NET setup team) described here, this issue turned out to be the #2 cause of setup failures for .NET 2.0 during beta 1 and beta 2.

    Now we had a cause, a solution, and data to support the case that this issue would lead to customer support calls if we decided not to fix it.  There were a couple final things to do to prepare this bug for the VS shiproom process.  The .NET setup team created a buddy build of the proposed fix and had to get test signoff.  Since the bug had not ever been reproduced inside of Microsoft, Quan and I each contacted a customer who had run into this issue in the .NET 2.0 beta program and they validated that the fix worked.  The .NET setup took this bug to shiproom and presented the problem, the solution, the Customer Feedback site and Watson data and the customer sign-off, and the bug was approved to be checked in.

    I'm very happy to say that this fix will be in the final release of .NET Framework 2.0.  This bug was never reproduced inside of Microsoft and would not have been fixed if it were not for customers who participated in the VS 2005 and .NET Framework 2.0 beta program.  The bug reports on the product feedback site and comments posted on my blog gave us valuable direct contact to customers who saw this problem first-hand so we could gather more data.  And each of the customers who saw this problem and chose to send the problem report back to Microsoft in essence provided "me too" votes to show us how frequent this bug would be if it were not fixed.  I want to say a big thank you to each customer who made this possible, and in particular to Michael.  Your detailed data and infinite patience made it possible for us to get to the bottom of this issue.

    If anyone reading this is running into this setup bug, you can find a hand-fixed version of .NET Framework 2.0 beta 2 here.  If you are running into this with some other build of the .NET Framework 2.0, please contact me and I can provide you an updated version that will work correctly for you.


  • Aaron Stebner's WebLog

    How to fix Visual Studio Class Designer Package load failure in VS 2005 after beta 2 uninstall


    I have been working with Hong and Andrey on an updated version of the VS 2005 beta cleanup tool.  During the course of investigating potential problems caused by uninstalling in the "wrong" order (by which I mean uninstalling the .NET Framework 2.0 beta 2 before uninstalling other parts of VS 2005), I found an interesting issue.  There are 2 assemblies installed by VS 2005 that shipped in beta 2 with no file version information.  These files are the following:

    • Microsoft.VisualStudio.EnterpriseTools.ClassDesigner.dll
    • Microsoft.VisualStudio.EnterpriseTools.SdmDesigners.dll

    When .NET Framework 2.0 beta 2 is uninstalled before VS 2005 beta 2, VS is unable to remove assemblies from the GAC because fusion binaries were removed during .NET 2.0 uninstall.  This causes all VS assemblies to be orphaned in the GAC.  Most of those assemblies will be updated in-place when installing a later build of VS 2005 because the assemblies in the later build have higher file versions.  However, these 2 assemblies do not get replaced because they were unversioned in beta 2 and have been updated to have valid file versions in later builds.  It appears that fusion will not replace an unversioned file with a versioned file in this type of scenario.

    When the old beta 2 versions of these files are left in the GAC and you try to use specific features in the VS IDE, you can receive package load failures.  For example, if you open a C# Windows Application and right-click on a .cs file and choose View Class Diagram, you will receive a package load failure error for the Visual Studio Class Designer Package.

    To work around this issue, you have to replace these 2 unversioned assemblies in the GAC with the versioned assemblies that ship with later builds of VS 2005.  The trick now becomes how to find these files on the VS 2005 source media.  Here is how I found them when I was verifying the fix on a test machine in our lab.  Please note that the VS 2005 troubleshooting tool will perform these steps automatically and I also posted a separate, simpler set of manual steps to fix this issue, but I am including them here for those who are interested in how I went about troubleshooting this issue.

    1. Open the VS 2005 MSI in Orca
    2. Go to the File table, press Ctrl + F and search for each of the files
    3. Take note of the Sequence value for each of them
    4. Go to the Media table and sort by LastSequence value in order to find the cab that each file is in on the VS 2005 source media
    5. Go to the VS 2005 source media and extract the files from the cabs listed in the Media table
    6. Rename each of the files after extracting them (becuase the files in the cabs will be named with the identifier from the File table and not the actual name so that Windows Installer knows how to find the files in the cab during installation)
    7. Open a cmd prompt and navigate to the proper locations in the GAC and copy the newly extracted files to the locations and overwrite the unversioned files that were left behind
    8. Relaunch VS and verify that the previously broken scenarios now work and do not show any package load failures

    The GAC locations for the 2 files in question are the following:

    • %windir%\assembly\GAC_MSIL\Microsoft.VisualStudio. EnterpriseTools.ClassDesigner\\ Microsoft.VisualStudio.EnterpriseTools.ClassDesigner.dll"
    • %windir%\assembly\GAC_MSIL\Microsoft.VisualStudio. EnterpriseTools.SdmDesigners\\ Microsoft.VisualStudio.EnterpriseTools.SdmDesigners.dll"

    If the above steps are too complicated, you can also use gacutil or a cmd prompt to remove the old versions of those 2 assemblies from the GAC and then run a repair of the newer version of VS 2005.  This is an easier process but will take much longer due to the time it takes to repair all of VS 2005.

    After re-reading all of the above, I realized what a pain this workaround is.  Fortunately, we're nearly done automating it so that if you inadvertantly uninstall VS 2005 beta 2 without using the prescribed uninstall order, you'll be able to use the updated version of the cleanup tool to fix this.  Stay tuned for a post very soon with details about where to download the updated cleanup tool.....

    <update date="11/7/2005"> Added links to automated cleanup tool and simpler set of manual cleanup instructions for this issue in case people find this blog post but not the other posts I've done about this issue </update>


  • Aaron Stebner's WebLog

    How to report a bug to Microsoft for Visual Studio and .NET Framework setup


    Microsoft has created what I think is a really cool mechanism for customers to report bugs and suggestions for our products - the Product Feedback center.  Right now, you can report bugs in Visual Studio 2005 and the .NET Framework 2.0 via this website.  The bugs from this site are transformed into the correct format and then reported directly into the same database that VS and .NET Framework product teams use to report bugs against daily builds of the products as they are being developed.  There is also a really nice process put in place by the Developer Division community team (Josh Ledgard, et al) that ensures that bugs reported via the Product Feedback center are given special attention so they do not end up swept under the rug due to the lack of a repro in our test lab, and so they are all responded to in a timely (and hopefully professional) manner.

    The Product Feedback site has increased the volume of bugs reported for VS and the .NET Framework, and in particular for setup (because setup is the first thing every customer sees in the product and because every customer must get through setup in order to use the product).

    I posted this article that describes the steps that we recommend everyone follow when reporting a bug in setup for the various versions of Visual Studio and the .NET Framework.  Included in this article are links to full lists of log files that are created by setup for each version of VS and the .NET Framework.  I'll put those links here too to make them a little more visible:

    I strongly encourage anyone who encounters a problem while installing or using VS or the .NET Framework and anyone who has a suggestion for how we can improve in the future to use the Product Feedback site.  If your problem appears setup-related, please take a quick look at this article and include the requested information in your bug report if possible (but don't skip reporting the bug because you can't find a log file or something like that).

    For those of you who have already used the Product Feedback site, thank you very much!


  • Aaron Stebner's WebLog

    Looking behind the scenes of the setup wrapper used for the .NET Framework 2.0


    In the past, I've written a little bit about the packaging for the .NET Framework setup, including changes that have been made for the .NET Framework 2.0 (notably, the post here).  I wanted to talk a little bit more about the underlying setup wrapper package and how it works.  The setup wrapper is an MSI external UI handler that we specifically designed to be generic so that different types of MSI-based setup packages could use it.  In fact, the same underlying wrapper is used to install the .NET Framework 2.0, the J# redistributable 2.0, the .NET Framework 2.0 SDK, .NET Framework and J# redistributable language packs, and a lot of the smaller MSI-based products that are a part of Visual Studio setup.

    Let's take a quick look at the contents of the setup wrapper by downloading a build of the .NET Framework 2.0 (for example, from here).  You'll see the following files:

    • install.exe - the main setup executable
    • install.ini - the  settings file that controls some of the behaviors and appearances of the setup
    • install.res.XXXX.dll - languages resource DLL that provides strings for the setup UI in each supported UI language
    • eula.XXXX.txt - EULA files for each supported UI language
    • unicows.dll - support DLL used to enable the setup wrapper to work on ANSI operating systems like Windows 98 and ME
    • netfx.bmp - bitmap to display in the top right corner of the setup UI pages; it is specified in install.ini; in the case of the .NET Framework this bitmap is just a blank picture
    • netfx.msi - the MSI for the product
    • mscoree.dll - this file is included specifically because the product being installed is the .NET Framework and we are trying to optimize some files-in-use scenarios to minimize reboots

    Since this setup wrapper is designed to be generic, it can actually be used to install most MSI packages and not just the one it is packaged with.  As an exercise, I decided to try to swap out the UI handler and use this setup wrapper to install the Orca MSI viewer/editor package.  Here are the steps I took:

    1. Download the .NET Framework 2.0 from here
    2. Run dotnetfx.exe /t:c:\temp /c to extract it to a temporary folder
    3. Download Orca from here and save it to the same folder as in step 2
    4. Install Orca so that I can use it to edit the Orca MSI
    5. Open the Orca MSI in Orca and drop all of the contents of the Dialog table (because we are not going to use the built-in UI)
    6. Open install.ini and change the ProductName and ProductMsi
    7. Save and close install.ini
    8. Right-click and choose to uninstall Orca so that we can test the installation scenario
    9. Run install.exe from the temporary folder used in steps 2 and 3 above and install Orca using the same UI as the .NET Framework
    10. Re-run install.exe and choose the uninstall radio button

    I will explore more details about this setup wrapper in a future blog post, including the following:

    • Describing the settings in the install.ini
    • Outlining strengths and weaknesses of this setup wrapper and explain why some of the design decisions were made the way they were
    • Show an example about how to configure a more complex setup (such as the .NET Framework 2.0 SDK) using this setup wrapper.


  • Aaron Stebner's WebLog

    Possible cause of .NET Framework setup failures on NT4


    Since I originally posted these instructions that describe how to gather callstack information when the .NET Framework setup fails while registering System.EnterpriseServices.dll or running regsvcs.exe /bootstrapi, I have gotten a few problems reported for installations on Windows NT4 SP6a.  After looking at the callstack data and looking at past cases logged by our product support team, we found a common pattern that can cause .NET Framework setup failures.

    All of these cases shared a common pattern - the NT4 SP6a OS was originally installed on one machine and then imaged with a disk imaging utility, then restored onto another machine that had different hardware (such as a newer processor).  There are some instances where imaging and restoring the OS on different hardware will cause .NET Framework setup to fail.  The case notes from one support incident indicate the following:

    Analysis of the crash dump revealed that the .NET jitter was generating Intel Pentium SSE2 instructions and when such an instruction was executed, it failed with "Illegal instruction".  These functions were repeated and eventually a stack overflow crashed the regsvcs process.

    Further investigation of the hardware revealed that this CPU supported the SSE2 instruction set, but the OS had not loaded the driver (INTLFXSR.SYS) because this machine was imaged using an image generated from an older CPU (which did not support the SSE2 instruction set).

    So far, we have only seen this imaging problem affect NT4 SP6a and not other OS types, but it may be possible for this to happen on other OS types as well.  Also, imaging your OS and restoring it on a different machine will not necessarily always cause .NET Framework setup to fail.  It is very dependent on the type of hardware on the source and destination machine.

    Unfortunately, there is not a good workaround if your machine is hitting this problem other than reinstalling NT4 SP6a directly on the machine (as opposed to restoring a pre-existing image), or installing a newer version of Windows on the machine.


  • Aaron Stebner's WebLog

    Interesting bug in the LaunchCondition table for .NET Framework 2.0 64-bit setup


    I was looking at the setup package for the x64 version of the .NET Framework beta 2 recently.  I needed to try to install it on a Windows Vista machine in order to work on an issue related to Media Center, and I got an interesting error telling me "Microsoft .NET Framework 2.0 (x64) is not supported on Windows 95, Windows NT, Windows 2000 without Service Pack 3 or greater, and Windows Server 2003 without Service Pack 1 or greater."  Granted, it isn't really a valid scenario to try to install the MSI-based .NET Framework 2.0 package on Vista because the .NET Framework 2.0 is already part of the OS, but since I got this error message that blocked me but listed a completely wrong set of OS's, I had to dig a little deeper at least to satisfy my own curiosity.

    While I was looking at the MSI, I came across this condition in the LaunchCondition table:

    (Version9X >= 410) OR ((VersionNT = 500) AND (ServicePackLevel >= 3)) OR (VersionNT = 501) OR ((VersionNT = 502) AND (ServicePackLevel >= 1))

    I stared at this set of conditions for a while because something just felt wrong about it.  Then it came to me - this launch condition is listing the OS's that the MSI will allow the .NET Framework 2.0 x64 version to install on.  Notice that the supported versions stop with VersionNT = 502.  Since the VersionNT value 502 is equivalent to Windows Server 2003, it would block installation on any OS with a version number higher than Windows Server 2003.  That is fine for Vista because .NET 2.0 will already be a part of the OS, but that is not fine for future versions of Windows after Vista.

    To make a long story short, I reported a bug on this issue and they're considering a fix for it for the final version of .NET Framework 2.0 x64 and ia64 editions.  However, I thought it illustrated a couple of more important points to keep in mind when designing an MSI-based setup:

    1. Be careful with using LaunchConditions.  The logic can be confusing and convoluted and getting them wrong will block your setup from being allowed to run, which is fairly painful to try to patch or recover from.  We put a launch condition in for the .NET Framework 1.1 to block installation on 64-bit platforms but then after 1.1 shipped Microsoft started releasing 64-bit OS's, and the application compatibility team had to add a shim to the OS to override this launch condition that was no longer valid.
    2. Try to keep the future in mind when designing your setup whenever possible.  In my experience, this is really hard to do but very important.  For example, do not limit your setup authoring to only account for operating systems that are available when your product ships.  Think about making your version detection generic unless there is some specific reason you would not want your users to install your product on some future OS.  Also, think about whether you will be releasing future versions of the product and whether or not you want to have both versions co-exist on the same machine - and if so, learn and know the MSI component rules and apply them to the design of all versions of your product.  We did not get things exactly right for the .NET Framework 1.0 and that is why you will see files named sbs*.dll installed to %windir%\Microsoft.NET\Framework with all versions 1.1 and higher - these files bail us out in uninstall scenarios by adding extra component ref-counts to some resources that would otherwise be uninstalled incorrectly.


  • Aaron Stebner's WebLog

    WiLogUtl.exe does not work with Windows Installer 3.1 log files


    A little while back I described a method of searching for errors in a verbose MSI log file.  At the end of that post, I listed an MSI log parsing tool named wilogutl.exe that ships as a part of the Windows Installer Platform SDK.  I found out today that this tool does not parse log files created by Windows Installer 3.1.  If you try to parse an MSI 3.1 log file with wilogutl.exe, you will see an error dialog that says "Log file created with version higher than this tool supports".

    This is a known issue with wilogutl.exe that still needs to be addressed.  In the meantime, you can do the following to workaround this:

    1. Open the verbose log file in a text editor such as notepad
    2. Change the version number in the first line of the log file from 3.01.xxxx.xxxx to 3.00.xxxx.xxxx
    3. Save and close the verbose log file
    4. Run wilogutl.exe again and load the log file

    For example, the following appears in the verbose log file created on my development machine (which is running Windows Server 2003 with SP1) when I installed Visual Studio .NET 2003:

    === Verbose logging started: 8/4/2005  10:40:02  Build type: SHIP UNICODE 3.01.4000.2435  Calling process: C:\Documents and Settings\astebner\Local Settings\Temp\SIT12447.tmp\setup.exe ===

    When I changed it to the following, wilogutl.exe started working correctly for me:

    === Verbose logging started: 8/4/2005  10:40:02  Build type: SHIP UNICODE 3.00.4000.2435  Calling process: C:\Documents and Settings\astebner\Local Settings\Temp\SIT12447.tmp\setup.exe ===

    <update 8/23/2005> The newest version of the Windows Installer PSDK contains an updated version of wilogutl.exe that will correctly parse log files produced by Windows Installer 3.1.  The above steps can be used to enable older versions of wilogutl.exe to parse 3.1 log files.


  • Aaron Stebner's WebLog

    How to pass MSI command line parameters to Visual Studio setup


    I was helping a Microsoft team customize Visual Studio 2005 setup this week.  They needed to make some modifications to the VS MSI for some of their development scenarios and in order to do so, they created a transform that needed to be applied during VS setup.  As I was helping them, I realized that there is a command line switch for VS setup that is not documented that could be useful to others so I thought I'd write up a quick description here.

    Ordinarily, you would be able to install VS by running msiexec /i vs_setup.msi.  But, VS setup uses an external UI handler, and we use a strategy similar to what is described here to limit users from running setup without using the UI handler we provide.  In order to support passing any arbitrary MSI command line parameters to the VS MSI using the UI handler, we introduced the /msipassthru command line switch.  The switch looks like the following:

    • setup.exe /msipassthru=BEGIN"<msi string here>"END

    As an example, if you have a transform you want to apply, the command line would be the following:

    • setup.exe /msipassthru=BEGIN"TRANSFORMS=my_transform.mst"END

    There are a couple of important things to note when using this command line switch:

    1. The /msipassthru switch only works for the setup.exe that resides in the setup subdirectory on the VS source CD/DVD.  It will not work for the setup.exe on the root of the first CD or DVD.
    2. The /msipassthru switch will work for all Visual Studio .NET 2002, Visual Studio .NET 2003 and Visual Studio 2005 products


  • Aaron Stebner's WebLog

    Good references for the ARPSYSTEMCOMPONENT MSI property


    I found a couple of recent posts by Heath Stewart that describe the ARPSYSTEMCOMPONENT property that is used by Windows Installer along with some tips, tricks and gotchas associated with it.  These posts are especially interesting and timely because I just wrote about some of the details of the external UI handler that the .NET Framework 2.0 setup uses.  One of the cases where it is helpful to use the ARPSYSTEMCOMPONENT property is when your MSI-based setup uses an external UI handler and you want the Add/Remove Programs entry for your product to launch the external UI handler instead of the standard Windows Installer UI for repair/uninstall.  The .NET Framework and Visual Studio both use this property in their MSI to suppress the standard Windows Installer Add/Remove Programs entry and then create registry keys/values in the registry table to point to their external UI handlers instead.

    So, without further ado, here are Heath's articles.  Hopefully you'll find them as interesting and useful as I did:


  • Aaron Stebner's WebLog

    Tips and tricks for authoring the MSI Media table for a setup


    Since Visual Studio is one of the few multi-disk MSI packages that I am aware of, our team has had more experience using the Media table and run into more problems while trying to release builds on CD and DVD than any other team I know of within Microsoft.  The Media table is documented in the Windows Installer MSDN documentation (this is a good starting point).  Here is a list of some random information (and a couple of bugs in our products) that we discovered about the Media table during the process of shipping VS .NET 2002 and 2003 and the .NET Framework 1.0 and 1.1:

    1. The value listed in the VolumeLabel column of the table much match the volume label of the physical disk being installed from if the product is being installed from a removable media drive.  If the physical disk has a different volume label than what is listed in the Media table for the file that the MSI is attempting to install, you will get a dialog asking you to swap disks.
    2. The documentation shows that you can leave the VolumeLabel column blank, but if you do this, make sure that your entire setup package fits on a single disk or else your users will not receive proper disk swap notifications and the installation will fail because Windows Installer won't be able to find files it needs to install.
    3. Windows Installer treats local CD and DVD drives as removable media, and uses the values in the VolumeLabel column of the Media table if installation happens from one of those locations.
    4. Windows Installer does not treat a shared network drive that maps to a CD/DVD drive as a removable drive, and if you install from such a shared drive you will receive a 1308 (file not found) error for the first file that is expected to appear on disk 2.  When that happens you will have to swap disks on the machine that has its CD/DVD drive shared out and then press retry on the 1308 error dialog on the machine you are installing on.
    5. If you provide a volume label for one of the entries in the Media table of an MSI and there are multiple entries, then MSI will check the volume label to make sure it matches even for an installation that does not span multiple disks.  We ran into this for the .NET Framework - the product is small enough to fit on a single disk, but we had several embedded CAB files (which each require their own Media table entry) and a set of files in an external cab that we listed with the volume label URTSTDD1.  When installing from the self-extracting dotnetfx.exe package, setup always copies itself to the local hard drive (in a folder under %temp%) so MSI never considered that to be a removable media installation.  When one of our partners tried to extract the contents of dotnetfx.exe and ship this on their installation media and install by calling netfx.msi directly, they started getting prompted to swap disks.  We have fixed this in the .NET Framework 2.0 by calculating in our build process that the .NET Framework is less than the size of a burned CD and leaving the VolumeLabel columns in the Media table blank for all entries.
    6. Windows Installer does not support CD/DVD jukebox installation scenarios.  Once you start installing from a specific CD/DVD drive letter, you will have to swap disks on that drive to complete installation even if you have other CD/DVD drives on your machine.


  • Aaron Stebner's WebLog

    Automating performance optimizations for Windows Media Center


    I recently stumbled across a KB article that lists some performance optimization tips and tricks for Windows Media Center and I also saw some of the steps that we recommend to folks inside of Microsoft, which are roughly the same as the KB article.  What seems to be missing from all of these performance recommendations is steps for how to automate these steps.  Here are ways to run some of the key Media Center performance optimization steps automatically so that it can be scripted and run as a scheduled task if desired.

    Run Disk Defragmentation

    • %windir%\system32\defrag.exe <drive letter>

    Run Disk Cleanup

    • %windir%\system32\cleanmgr.exe /d <drive letter>

    More info about command line options for disk cleanup can be found in this KB article

    Remove Temporary Files

    • rd /s /q *.tmp

    Remove Memory Dump Files

    • rd /s /q *.dmp

    Disable System Restore

    System restore monitors system changes and saves the system state as a restore point.  These restore points are created when any hotfix is installed and in other scenarios, and the files they use to store system state cannot be defragmented using the utility listed above.  Therefore, you may want to disable system restore by setting the following registry keys/values:

    Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore
    Registry Value: DisableSR
    Data Type: REG_DWORD
    Value Data: 1

    Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sr
    Registry Value: Start
    Data Type: REG_DWORD
    Value Data: 4

    Disable Disk Indexing

    Disabling disk indexing is one of the optimization steps not listed in the current KB article for Media Center performance.  However, I have not been able to find a way to disable disk indexing automatically, but it can be done with these steps.  If anyone reading this knows how to automate disabling disk indexing, please post a comment!

    1. Navigate to My Computer 
    2. Right click on each drive letter and choose Properties 
    3. Uncheck the item labeled Allow Indexing Service to index this disk for fast file searching and click OK 
    4. Choose the radio button labeled Apply changes to <drive letter>, folders and files and click OK


  • Aaron Stebner's WebLog

    How to manually patch the .NET Framework 2.0 MSI to fix registry permission bug


    Yesterday, I posted a description of a registry permission bug that was preventing the .NET Framework 2.0 from installing in certain circumstances.  This bug has been fixed, but it still affects all of the publicly available versions of the .NET Framework 2.0.  If you need to install a build of the .NET Framework 2.0 that still has this bug, you can use the following steps to manually patch the .NET Framework 2.0 MSI to workaround this bug.

    1. Download the .NET Framework 2.0 setup package you are trying to install (named dotnetfx.exe) and save it to your local hard drive
    2. Download and install Orca if you don't already have it
    3. Extract the .NET 2.0 setup package by running dotnetfx.exe /t:c:\temp /c
    4. Go to the c:\temp folder you extracted the setup package to in step 3 above and right-click on netfx.msi and choose Edit with Orca
    5. Go to the CustomAction table and click the Action column header to sort by action name
    6. Find the set of custom actions that begin with the name DD_CA_Regtlib
    7. Change the Type value for each regtlib action that is currently listed with value 1025 (which means a deferred DLL custom action) to 3073 (which means a deferred DLL custom action with no impersonation)
    8. Change the Type value for each regtlib action that is currently listed with value 1089 (which means a deferred DLL custom action that does not check return value) to 3137 (which means a deferred DLL custom action with no impersonation that does not check return value)
    9. Save the MSI and close Orca
    10. Go to c:\temp and run install.exe from that location to install the .NET Framework 2.0

    Also note that if you are trying to install the .NET 2.0 beta 2 build you can download a version that already has this patch applied, you can download it from here.


  • Aaron Stebner's WebLog

    My adventure creating a Media Center add-in, part 3


    I'm going to shift course a little bit from my previous entry regarding creating a Media Center add-in.  For one thing, I still haven't had enough time to sit down and really dig into the code of the example add-ins that are installed as part of the Media Center SDK.  For another, I have had a couple of folks ask me more in-depth technical questions about how to install an add-in and what exactly comprises the payload of an add-in setup package.  So I set out tonight trying to figure out the deployment part of creating a Media Center add-in.

    Based on my previous research, I knew that the contents of an add-in are basically a .NET assembly, an XML registration file that you pass into the application RegisterMCEApp.exe that ships in the %windir%\ehome directory as part of Media Center 2005, and any additional files (like bitmaps or data files) that the add-in might require.  I had previously looked at an add-in written by Ethan Zoller, and the "setup" for his add-in was a simple batch file that copied the assembly to %windir%\ehome, called RegisterMCEApp.exe, and xcopied a few other files it needed to %windir%\ehome or a subdirectory.

    This seemed straightforward enough, but being the setup geek that I am, I'm not a big fan of installations that use batch files and don't give the user a clearly defined, robust uninstall and transactional installation process.  So I sought out better recommendations in the SDK documentation for creating a real setup package for installing and uninstalling add-ins.  I found this page with a few links that describe how to perform various deployment related tasks:

    There is not really any other information in MSDN about deploying Media Center add-ins that I could find, but I suppose this is not too surprising considering that the installation process itself is fairly simple.  Unfortunately, these docs assume the average add-in writer has a copy of Visual Studio .NET 2002 or 2003 and a good working knowledge of the Visual Studio setup/deployment project type.  The good news is that the SDK ships a custom action DLL that can be consumed to run code that is the equivalent of RegisterMCEApp.exe during an MSI-based add-in setup process.  I wonder why this registration has to be done with a black-box executable instead of just by creating some registry keys that Media Center knows how to read.  I know I said when I started this add-in project that I was going to approach it as someone who did not have access to all of the Microsoft internal employee resources, so I will have to answer that question for myself with some side research some other time.

    OK this is all I have time for tonight.  I know this didn't really advance my ultimate goal of creating an add-in, but this research did fill in some background knowledge I'm going to need down the road, and it started me thinking about whether or not there are any ways to make the deployment of add-ins easier for customers.

    Next time I'll look into some of the sample add-in code, I promise...

    [to be continued]


  • Aaron Stebner's WebLog

    Possible bug installing VS 2005 beta 2 on Windows Vista (Longhorn) beta 1


    We have seen a few reports inside of Microsoft of problems installing VS 2005 beta 2 on Windows Vista (previously codenamed Longhorn) beta 1 now that Vista beta 1 has been released and teams are using it more widely.  In addition we have seen at least one report on the product feedback site from an external customer (the bug report located here).

    This bug does not reproduce 100% of the time and is related to a performance issue or possibly a race condition in the file system code somewhere (the bug is still under investigation and a cause has not yet been fully identified).  The symptoms seen during VS 2005 setup will be that MSXML6 fails to install and setup stops there, or that some of the components installed after VS 2005 beta 2 (specifically the 2 versions of the .NET Compact Framework and SQL Mobile) report that they failed to install.

    The workaround to resolve this bug if you run into it is to to the following:

    1. Navigate to the WCU subfolder on the VS 2005 beta 2 DVD
    2. Go to the each of the MSXML, NetCF and SQLCE folders
    3. Install the MSI packages in each of those folders by right-clicking on them and choosing Install
    4. After these complete, re-run VS 2005 beta 2 setup and it should complete with no further problems on Windows Vista beta 1.

    Also, as a side note, I wanted to mention that Windows Vista beta 1 includes the equivalent of the .NET Framework 2.0 beta 2 bits (with a few additional post-beta 2 bug fixes).  Since the beta 2 bits are installed as part of the OS, you cannot replace them with later builds of the .NET Framework 2.0.  Therefore, you will be able to install the beta 2 versions of VS 2005 on Vista beta 1.


  • Aaron Stebner's WebLog

    MSDN for VS 2005 beta 2 will fail during uninstall if .NET Framework 2.0 beta 2 was uninstalled first


    While working on some of the new steps needed in the cleanup tool that will help folks moving from VS 2005 beta 2 to post beta 2 CTP builds and eventually to the final released version (you can get a preview version of this tool here), I found a bug that I wanted to alert people of just in case.  If you uninstall the .NET Framework 2.0 beta 2 before you try to uninstall MSDN for VS 2005 beta 2, MSDN uninstall will fail and report a fatal error.  To workaround this I had to re-install .NET Framework 2.0 beta 2.

    Of course, I know that the .NET Framework 2.0 beta needs to be installed last when removing previous beta bits to prepare to update to a newer beta, but not all customers will read the fine print on the web or in the readme.  And this uninstall order is not enforced in the code at all.  So I wanted to give a heads up just in case.

    I ran the MSDN uninstall with verbose logging and this is the exact error that caused uninstall to fail:

    MSI (s) (58:10) [20:12:54:810]: Executing op: CustomActionSchedule(Action=CA_RepairArchive.3643236F_FC70_11D3_A536_0090278A1BB8,ActionType=3073,Source=BinaryData,Target=RepairArchive,)
    MSI (s) (58:8C) [20:12:54:830]: Invoking remote custom action. DLL: D:\WINDOWS\Installer\MSI737.tmp, Entrypoint: RepairArchive
    Action ended 20:12:54: InstallFinalize. Return value 3.

    Apparently this custom action needs something in the .NET Framework to run correctly in beta 2.  Fortunately, this scenario was discovered and fixed and I validated that MSDN will uninstall correctly even if the .NET Framework 2.0 is not installed in more recent builds.

    As a side note - this is a really frustrating user experience to have uninstall fail and rollback.  In this case I was trying to remove the product, and removal fails so it rolls me back to the state where it is still installed.  In addition, in order for MSI to support rollback it has to reserve extra disk space to cache the rollback data in case of a failure and uninstall takes longer because it has to cache rollback data before starting to uninstall.

    We faced similar issues in Visual Studio setup, and after examining the data and getting bugs reported about setup reporting that the machine did not have enough disk space to uninstall, we made a decision early in the development cycle for VS .NET 2002 to disable rollback during uninstall.  This ended up speeding up the uninstall time from about an hour to less than 5 minutes (in most cases), plus we no longer received bug reports about not having enough disk space to uninstall.  We were initially worried that uninstall failures would leave the machine in a bad state and prevent future installs, but found that to be extremely rare in beta versions of VS .NET 2002 and ended up shipping that way (and we also shipped VS .NET 2003 that way and intend to ship VS 2005 that way as well).


  • Aaron Stebner's WebLog

    Updated VS 2005 uninstall instructions for beta 2 and post beta 2 CTPs


    Hey all, now that we have released some post beta 2 community tech preview versions of Visual Studio 2005, I've been getting questions about using the cleanup tool that was originally created for removing beta 1 to remove beta 2 instead.  The bad news is that the version of the cleanup tool posted at this location will only work correctly for removing things that are left over from VS 2005 beta 1.

    The good news is that we're working on an updated version that will work for beta 2 and beyond.  An early preview version is already available at this location.  This version of the cleanup tool currently only automates the uninstall of the previous beta packages in the order specified in the updated manual uninstall instructions (which can be found in this post on Hong Gao's blog).  These steps are essentially the same as the steps published for VS 2005 beta 1, but have been updated to include new components that were not a part of beta 1 or have been renamed since beta 1.  Please pay special attention to the order of uninstall.  Most of the problems we see migrating from beta to beta come from uninstalling the .NET Framework 2.0 beta build before the other stuff.  You need to uninstall the .NET Framework 2.0 beta last.

    Stay tuned to my blog and to Hong's blog for updates about the cleanup tool.  We're nearly ready to post an updated version of the tool that will identify and repair some of the known problems that we have seen after migrating from one beta/CTP to a newer beta/CTP in addition to automating the uninstall of the various pieces of VS 2005.


  • Aaron Stebner's WebLog

    .NET Framework 1.1 deployment guide


    There is a pretty good document published on MSDN that provides a technical overview of various topics related to deploying the .NET Framework 1.1.  It provides information related to mass-deployment to a network of computers, and also information related to redistributing the .NET Framework 1.1 as part of another setup package (for managed applications that want to bootstrap the .NET Framework if it is not installed instead of blocking and forcing the user to install it themselves).

    You can find this article at this location.  Here are a few of the important topics covered in this article:

    1. How to deploye the .NET Framework 1.1 via SMS (listed in the section named "Deploying the .NET Framework using Systems Management Server")
    2. How to deploye the .NET Framework 1.1 via Active Directory (listed in the section named "Deploying the .NET Framework using Active Directory")
    3. Detecting whether or not the .NET Framework 1.1 is installed (listed in the section named "Detecting that the .NET Framework 1.1 is installed")
    4. Detecting whether or not .NET Framework 1.1 language packs are installed (listed in "Table 2. .NET Framework Registry Locations")
    5. How to determine whether or not installing the .NET Framework 1.1 succeeded when it is chained as part of another product's setup package (there is a list of options in the section named "How to Determine If the .NET Framework, J# Redistributable Package, or Language Pack Installed Successfully From a Setup Package That Installs It As a Prerequisite")

    Now if I can only get all of the setup developers inside of Microsoft who redistribute the .NET Framework to follow these guidelines, I'll be making some progress.  I see way too many cases where setup developers choose random registry values or files and start using them to detect the presence or absence of the .NET Framework.  Invariably, if someone follows undocumented strategies and relies on behaviors that are observed but not officially supported, it can lead to compatibility issues when later versions of the .NET Framework are released if the behaviors are changed.  Microsoft product teams will not scrutinize or question behavior changes as much if they are not publicly documented because they tend to assume that others (inside and outside of Microsoft) will rely on officially documented behaviors when designing their own solutions.

    <update date="1/14/2009"> Fixed broken link to the .NET Framework 1.1 deployment guide on MSDN. </update>


Page 1 of 2 (35 items) 12