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 fix Media Center remote control if it breaks when installing IR update rollup

    • 15 Comments

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

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

     

  • Aaron Stebner's WebLog

    How to pass MSI command line parameters to Visual Studio setup

    • 0 Comments

    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

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

    • 49 Comments

    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

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

    • 5 Comments

    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

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

    • 1 Comments

    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

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

    • 17 Comments

    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

    • 23 Comments

    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\ 8.0.0.0__b03f5f7f11d50a3a\ Microsoft.VisualStudio.EnterpriseTools.ClassDesigner.dll"
    • %windir%\assembly\GAC_MSIL\Microsoft.VisualStudio. EnterpriseTools.SdmDesigners\ 8.0.0.0__b03f5f7f11d50a3a\ 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

    Please fill out the ISV runtime deployment survey

    • 1 Comments

    I found a link to a survey targeted to setup developers.  It asks some specific questions about deployment of runtime components such as the .NET Framework, DirectX, MDAC, MSXML, Flash, Java, MSDE, etc.  If you are a setup developer who has had to implement bootstrapping/deployment solutions for any runtime components, I highly encourage you to fill out this survey to help influence the next generation of developer tools.  This is an area that I've seen a lot of pain around in my experience on the .NET Framework setup team and in working with other setup groups inside of Microsoft and in the field.  The more detailed data we can get, the better we can tailor future solutions to address key pain points.

    Also, if you are going to be attending PDC 2005, there is a question on the survey that you can answer that will add you to the invitation list for a couple of software design reviews (SDRs) that will be held during the PDC on September 14th and 15th.

     

  • Aaron Stebner's WebLog

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

    • 38 Comments

    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.

    -or-

    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

    Hong is famous :-)

    • 0 Comments

    I thought this was cool and wanted to blog it - I was reading an eWeek article this morning about VS 2005 and Hong Gao got mentioned by name.  I've been working with her on the side a little bit to get the VS 2005 cleanup tool updated to work with beta 2 uninstall/cleanup scenarios and it was exciting to see this project mentioned like that.  It is too bad that they refer to it as "his" blog though since she is female....

    <update 8/25/2005> They fixed the eWeek article!  Hong is now a "her"  :-)

     

  • Aaron Stebner's WebLog

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

    • 4 Comments

    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

    Possible cause of .NET Framework setup failures on NT4

    • 6 Comments

    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

    Visual Studio tips and tricks

    • 1 Comments

    A friend just sent me a link to the Visual Studio tip of the day category that is hosted on Sara Ford's blog.  This is really good reading for some features of Visual Studio .NET 2002, 2003 and 2005 that you might not otherwise know existed.  It isn't technically updated daily as the category name might suggest, but it is updated often enough to stay fresh and interesting.

     

  • Aaron Stebner's WebLog

    Documentation for new Windows Vista OS setup and deployment technologies

    • 2 Comments

    Now that Windows Vista beta 1 is available, there is some useful information that has been made publicly available about new and improved OS features.  One of the significant changes is a ground-up rewrite of OS setup and the technologies/tools that are used to deploy Windows.  Most of the world won't care about this (and in fact, they hopefully won't even notice as long as setup does its job and installs correctly and quickly the first time).  But for setup geeks like myself, there is some really interesting stuff to read and observe about these new OS setup technologies, even if you don't have a copy of Vista beta 1 (or don't have access to daily builds like I do).

    To get started learning about new Vista deployment technologies, I suggest that you take a look at this site.  It provides a high level overview of some of the improvements being made in Windows Vista to improve and simplify OS deployment.

    Then, you can dig into a 147 page (!!!) user's guide that go into significantly more detail about Windows Vista deployment features.  You can download this guide, named the Windows Automated Installation Kit (WAIK) by clicking on this link.  I've been digging into some of these technologies and I'm planning to write about them in more detail in the near future.

    One of the really cool things is that the underlying componentization of Windows that forms the basis for the new OS setup architecture originally came from ideas from my previous team - Windows Embedded.  The Windows setup team looked at how Windows XP Embedded was broken into individual components that expressed dependencies on other components and how Target Designer and other embedded tools could create various sized bootable images of Windows XP, and sought to bring this kind of modular design and explicit dependency mapping ability to the desktop version of Windows.  This is still a work in progress and there will be continued improvements in the remainder of the Vista development cycle and on into future versions of Windows.

     

  • Aaron Stebner's WebLog

    Working around a bug in .NET Framework 1.0 and 1.1 setup related to international settings

    • 1 Comments

    A couple of months ago, I posted a set of debugging instructions for the .NET Framework setup that describes how to use MsiBreak to set a break point and then gather callstack information for some setup custom action failures.  One of the troubleshooting tips I listed towards the top of that post seems to have gotten lost in the shuffle because I've had a few customers post comments or send me email about .NET Framework setup failures that we ended up tracking back to international language settings.  The tip at the top of that post would have resolved the problem much sooner if it wasn't buried and easy to miss like it is there.  So I'm going to post it here separately in the hope that it will get some hits in search engines and help some people who would have otherwise missed it.

    If you see a failure to register System.EnterpriseServices.dll or a problem running RegSvcs.exe /bootstrapi during .NET Framework 1.0 or 1.1 setup, it might be caused by the international language settings for the operating system that you are installing on.

    If you are running Windows 2000, Windows XP or Windows Server 2003, you can use these steps to resolve this issue.  Note that my post that lists the workaround specifically describes the bug in the context of Windows XP SP2, but the steps to resolve the issue are the same for all of the other operating systems as well (assuming that you have a non-default user or system locale configured on your machine and you are hitting this instance of the bug).

    On other operating systems such as Windows NT 4, you can workaround the issue by doing the following to manually verify that the data in the registry:

    1. Look at the Locale registry value located at HKEY_USERS\.Default\Control Panel\International using regedit
    2. Verify that the Locale value contains one of the values listed at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Nls\LocaleMapIDs
    3. If it does not, change the Locale to 00000409 (which represents English) temporarily
    4. Install the .NET Framework 1.0 + 1.0 SP3 or 1.1 + 1.1 SP1
    5. Change the Locale value back to the previous setting

    One interesting note here - just this week I noticed that the custom action that runs RegSvcs.exe /bootstrapi in .NET Framework 2.0 setup is now configured to allow setup to continue even if it fails.  Therefore, you should no longer see .NET Framework setup fail due to this custom action starting in .NET Framework 2.0.  Of course, the problem is that since there is generally some underlying bug in the runtime itself when this custom action failed, setup will now fail in some new place in 2.0.  I'll have to research a bit more and figure out what the new point of failure will be for this type of problem in .NET 2.0....

     

  • Aaron Stebner's WebLog

    How to manually reset folder and file permissions in Windows Explorer

    • 8 Comments

    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

    Visual Studio 2005 Express Edition August CTPs are now available

    • 3 Comments

    I noticed some new links today, it looks like the August Community Tech Preview (CTP) version of the VS 2005 Express Editions are now available for download.  Check out this page for more information.

    Also, here are the direct links to the setup packages for each of the August CTP Express editions:

     

  • Aaron Stebner's WebLog

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

    • 5 Comments

    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

    Good references for the ARPSYSTEMCOMPONENT MSI property

    • 5 Comments

    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

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

    • 41 Comments

    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

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

    • 6 Comments

    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

    .NET Framework 1.1 deployment guide

    • 4 Comments

    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>

     

  • Aaron Stebner's WebLog

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

    • 7 Comments

    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

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

    • 4 Comments

    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

    Why smart people defend bad ideas

    • 1 Comments

    A couple of weeks ago, a friend of mine sent me a link to an essay I found really interesting - Why smart people defend bad ideas.  I've worked at Microsoft for 6 years this coming Tuesday (August 16, 1999 is my 6 year anniversary as a full-time Microsoft employee; I was an intern in the summer of 1998 but Microsoft doesn't count internships towards service time anymore....) and this essay comes the closest to describing what it is like to work at Microsoft of anything I've read.  It drives me a little bit crazy each time I hear someone start a sentence in a meeting or an email with the word "So...", but it seems like it is second nature to a lot of people who I work with every day.  I can't remember encountering this kind of tendency until I started working at Microsoft.  I can also relate to a lot of the other themes discussed in this essay.  I think it makes for an interesting read, if for nothing else than to give some perspective about what it can be like to work with people who are self-identified as "smart."

     

Page 1 of 2 (35 items) 12