Aaron Stebner's WebLog

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

July, 2005

  • Aaron Stebner's WebLog

    Using MsiInv to gather information about what is installed on a computer


    As I was reading one of the posts on Quan To's new blog, I noticed that someone posted a link to a tool named msiinv.exe on their tools page.  This tool (which stands for MSI Inventory) wraps some of the publicly documented MSI APIs to provide information about the state of all Windows Installer products, features and components that Windows Installer thinks are installed on your computer.  I say "thinks are installed" because there are some rare cases where the actual installation state of a given product can get out of sync with the information Windows Installer has stored in its internal data structures, which can cause confusion for setup packages.

    I use this tool nearly every day as one of the first troubleshooting tools for setup problems because it allows me to get a baseline snapshot of what the current state is for a machine before I start trying to make changes to fix any problems a customer might be having.

    Example usage of msiinv.exe

    One of the common uses of msiinv.exe is if someone is trying to install one of the recent beta builds of VS 2005 or .NET Framework 2.0 and the setup UI states that you are not allowed to install because a previous beta version of <insert product name here> is on the machine and you must uninstall that first.  Sometimes after receiving this error message, a user will look in Add/Remove Programs and the product that setup is complaining about is nowhere to be found, or there is an Add/Remove Programs entry for that product but trying to remove it claims that the product is not on the computer and asks if you would like to remove the entry from the Add/Remove Programs list.

    In these cases, you can use the following steps:

    1. Download msiinv.zip from the following location:

    2. Extract the contents of msiinv.zip to the folder c:\msiinv on your system
    3. Click on the Start menu, choose Run, type cmd and click OK
    4. Type this command:  c:\msiinv\msiinv.exe -p > c:\msiinv\msiinv_output.txt

      Note: This command must be run from a cmd prompt or it will not create a log file as expected.

    These steps will create a text file named c:\msiinv\msiinv_output.txt with a list of each product that Windows Installer thinks is installed on the system.  Then you can open the text file in any text editor and search the list of products for the name of the product that setup told you to uninstall.  The output will look something like this (I am using an example from a machine that has .NET Framework 2.0 beta 2 installed):

    Microsoft .NET Framework 2.0 Beta 2
     Product code: {7A1ADD0C-17F3-47B8-B033-A06E189C835D}
     Product state: (5) Installed.
     Package code: {856D48D2-6F94-466D-9732-534DB5854FB3}
     Version: 2.0.50215
    <note: there is more info after this but I am omitting it because it isn't useful to the rest of my example>

    Now we have the Windows Installer product code and we can use that to uninstall the product by running msiexec /x <product code> (make sure that you include the curly braces in this command line).  If the product is actually installed on your system you will see a progress screen and uninstall will complete, and from there you should be able to re-run VS or .NET Framework setup and successfully install.

    If Windows Installer thinks that the product is installed but it really isn't, then running msiexec /x <product code> will give you an error stating that this command is only valid for installed products.  If this happens, you will need to perform an extra step to remove the data that causes Windows Installer to think this product is installed.  You can download the Windows Installer Cleanup Utility and install and run it on your machine to fix this.  In the list of applications that this tool displays, choose the one that matches the product name displayed when you first ran VS or .NET Framework setup and choose to remove it.  After this removal completes, you should be able to re-run VS or .NET Framework setup and successfully install.

    Advanced usage of msiinv.exe

    The msiinv.exe tool has several command line parameters that you can see by running it with the /? switch.  A couple of the more interesting options are the following:

    • msiinv.exe -v - This option will list all feature GUIDs and component GUIDs for each Windows Installer product that is installed on the machine.  This can be useful to see which products share components (which can help track down why running uninstall for one product leaves behind some files and/or registry).  If you have a lot of products installed on the machine, running with the verbose switch will take a long time.
    • msiinv.exe -x - This option will list Windows Installer components that are installed on the machine that do not have any products that hold reference counts on them anymore.  In most cases, this is caused by one or more setup being installed on the machine at some point in the past that violated the MSI component rules. (more info about component rules can be found here and here if you are interested)

    <update date="12/1/2008"> Updated the link to msiinv.zip because the old location was no longer available. </update>

    <update date="2/12/2009"> Updated command line for running msiinv.exe so it will work on Windows Vista and Windows Server 2008. </update>

    <update date="4/1/2009"> Removed broken link to msiinv.exe tool </update>

    <update date="10/11/2012"> Embedded new SkyDrive link to msiinv.exe tool </update>


  • Aaron Stebner's WebLog

    What .NET Framework version numbers go with what service pack


    I got a comment from a customer in response to a previous blog post asking about file versions for the various versions and service packs of the .NET Framework.  I was planning on just navigating to an MSDN site and replying with a link, but I couldn't find anything like that in any MSDN article or any KB article, so I figured I could come up with a quick table listing them.  Keep in mind that not every file is updated by every service pack, so you may not see this exact version for all of the files that are part of the .NET Framework.  Also, because of some of the magic that the Visual Studio and .NET Framework build lab uses to build some of the files that are part of the .NET Framework, you may see a .NET Framework-like version number (one that starts with 1.0, 1.1, or 2.0) or a Visual Studio-like version number (one that starts with 7.0, 7.10, or 8.0).

    .NET Framework product version

    Service pack level


    .NET Framework 1.0

    Original release

    1.0.3705.0 and 7.0.9466.0

    .NET Framework 1.0

    Service pack 1


    .NET Framework 1.0

    Service pack 2

    1.0.3705.288 and 7.0.9502.0

    .NET Framework 1.0

    Service pack 3

    1.0.3705.6018 and 7.0.9951.0

    .NET Framework 1.1

    Original release

    1.1.4322.573 and 7.10.3052.4

    .NET Framework 1.1

    Service pack 1

    1.1.4322.2032 (if you have the MSI-based 1.1 SP1 installed) or 1.1.4322.2300 (if you have the OCM-based 1.1 SP1 installed on Windows Server 2003) and 7.10.6001.4

    .NET Framework 2.0

    Beta 1

    2.0.40607.16 and 8.0.40607.16

    .NET Framework 2.0

    Beta 2

    2.0.50215.44 and 8.0.50215.44

    .NET Framework 2.0

    Original release

    2.0.50727.42 and 8.0.50727.42

    .NET Framework 2.0

    Service pack 1

    2.0.50727.1433 and 8.0.50727.1433

    .NET Framework 2.0

    Service pack 2

    2.0.50727.3053 and 8.0.50727.3053

    .NET Framework 3.0

    Original release

    3.0.04506.26 (on Windows Vista) and 3.0.04506.30 (on downlevel operating systems)

    .NET Framework 3.0

    Service pack 1


    .NET Framework 3.0

    Service pack 2


    .NET Framework 3.5

    Original release

    3.5.21022.8 and 9.0.21022.8

    .NET Framework 3.5

    Service pack 1

    3.5.30729.1 and 9.0.30729.1

    .NET Framework 4

    Original release

    4.0.30319.1 and 10.0.30319.1

    Please note that it is definitely not reliable to use the file versions in the above table to detect the installed service pack level.  If you're interested in accurately determining what version of the .NET Framework is installed and what service pack is installed I would recommend checking out the blog post and sample code that I previously posted at this location.

    <update date="1/31/2006"> Added another possible version number for 1.1 SP1.  The files have different versions depending on whether you have the MSI-based .NET Framework 1.1 package installed or the OCM-based .NET Framework 1.1 package that is included as a part of Windows Server 2003 </update>

    <update date="3/3/2006"> Added a column to the table for the final release of the .NET Framework 2.0 now that it has shipped </update>

    <update date="3/20/2007"> Added a column to the table for the final release of the .NET Framework 3.0 now that it has shipped </update>

    <update date="3/6/2008"> Added columns to the table for the .NET Framework 2.0 SP1, the .NET Framework 3.0 SP1 and the .NET Framework 3.5 now that they have shipped </update>

    <update date="8/14/2008"> Added columns to the table for the .NET Framework 2.0 SP2, the .NET Framework 3.0 SP2 and the .NET Framework 3.5 SP1 now that they have shipped </update>

    <update date="4/27/2010"> Added a column to the table for the .NET Framework 4 </update>


  • Aaron Stebner's WebLog

    Error installing .NET Framework on Windows XP SP2 caused by Data Execution Prevention (DEP)


    Note - the issue described in this blog post was originally presented as an issue on Windows XP SP2.  However, it can also affect .NET Framework 1.0 and 1.1 installation on any OS released after the .NET Framework 1.0 and 1.1 shipped - specifically, I have seen reports of this issue on Windows Vista.  The steps listed here are applicable to this type of install failure on other newer OS's like Windows Vista and not just Windows XP SP2. 

    As I was researching the bug in .NET Framework 1.0 and 1.1 that is related to regional language settings on Windows XP SP2 (see this blog post for full details), I discovered an additional issue introduced in Windows XP SP2 that can cause .NET Framework 1.0 or 1.1 setup to fail.  Just like the other bugs, this one causes .NET Framework setup to report an error while registering System.EnterpriseServices.dll.  In the case of .NET Framework service pack setup, it will cause an error to occur while extracting the service pack to a temporary location before even starting setup.

    Windows XP SP2 introduced a new security feature known as Data Execution Prevention (or DEP for short).  There is a good article introducing DEP here.  If a computer running XP SP2 has hardware that supports DEP and DEP is enabled in boot.ini, installation of the .NET Framework will fail while trying to register System.EnterpriseServices.dll (which happens to be the first time that managed code gets run during setup and therefore is the first time the bug is hit).  Also, installation of .NET Framework service packs will fail while trying to extract the service pack setup to a temporary location because the .NET Framework service pack wrapper is written in managed code.

    The DEP feature was introduced after the .NET Framework 1.0 and 1.1 shipped and unfortunately the .NET Framework is not compatible with DEP without applying a service pack.  Like the language settings bug, this DEP compatibility bug has been fixed in the .NET Framework 1.0 SP3 and 1.1 SP1.  However, this bug causes the initial installation of the .NET Framework to fail and rollback, and you cannot install the service pack without first getting the product installed (unless you use a method like I describe here, which will work but is not "officially" supported).

    If you are running into this bug on your Windows Vista, Windows Server 2008 or Windows 7 computer, you can use steps like the ones in this blog post to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed. 

    If you are running into this bug on your Windows XP SP2 computer, you can use the following steps to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed:

    1. From the Start menu, type sysdm.cpl in the Run box or go to Control Panel and choose the System item
    2. Click the Advanced tab
    3. Click the Settings button in the Startup and Recovery section of this tab
    4. In the Default operating system dropdown, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=Optin to /NoExecute=AlwaysOff.  This will update the settings in boot.ini on the computer
    5. Click OK
    6. Restart
    7. Install the .NET Framework 1.0 or 1.1
    8. Install .NET Framework 1.0 SP3 or 1.1 SP1
    9. Return to the System control panel, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=AlwaysOff back to /NoExecute=Optin

    For reference, here is what the Startup and Recovery item in the Advanced tab of the System control panel looks like (this is the screen you will see in step 4 of the instructions above):

    System control panel Advanced tab

    <update date="4/17/2008"> Added a note indicating that the issue in this post can affect the .NET Framework 1.0 and 1.1 setup on Windows Vista and not just Windows XP SP2 </update>

    <update date="6/23/2009"> Fixed broken image link, and added a link to a separate blog post that provides steps for turning DEP on and off on Windows Vista and higher. </update>


  • Aaron Stebner's WebLog

    Error installing .NET Framework on Windows XP SP2 caused by language settings


    Note - the issue described in this blog post was originally presented as an issue on Windows XP SP2.  However, it can also affect .NET Framework 1.0 and 1.1 installation on any OS released after the .NET Framework 1.0 and 1.1 shipped - specifically, I have seen reports of this issue on Windows Vista.  The steps listed here are applicable to this type of install failure on other newer OS's like Windows Vista and not just Windows XP SP2.  

    I was contacted by a customer last week who could not get the .NET Framework 1.1 to install correctly.  It reported an error while registering System.EnterpriseServices.dll just like I describe in this post.  In the end, the customer discovered that the system locale of the computer was set to Maltese, and he was able to install the .NET Framework by temporarily changing the system locale back to English.

    I did a little research, and found that there is a bug in the .NET Framework that causes it to not work correctly when the default system locale is set to a language that the .NET Framework does not recognize.  This bug has been fixed in the .NET Framework 1.0 SP3 and 1.1 SP1.  However, this bug causes the initial installation of the .NET Framework to fail and rollback, and you cannot install the service pack without first getting the product installed (unless you use a method like I describe here, which will work but is not "officially" supported).

    With the release of Windows XP SP2, Microsoft shipped Enabling Language Kits (ELKs) for 25 new locales (click here for a complete list and a nice description of what features ELKs provide).  Because of the bug in the .NET Framework that I described above, if a computer running XP SP2 has the system locale set to one of these 25 new locales, installation of the .NET Framework will fail while trying to register System.EnterpriseServices.dll (which happens to be the first time that managed code gets run during setup and therefore is the first time the bug is hit).

    If you are running into this bug on your Windows XP SP2 computer, you can use the following steps to work around this bug in the .NET Framework and get it installed:

    1. From the Start menu, type intl.cpl in the Run box or go to Control Panel and choose the Regional and Language Options item
    2. Click the Advanced tab
    3. Change the language in the dropdown box labeled "Select a language to match the language version of the non-Unicode programs you want to use:" to English (this setting represents the system locale for the computer)
    4. Check the box labeled "Apply all settings to the current user account and to the default user profile"
    5. Click OK
    6. Restart
    7. Install the .NET Framework 1.0 or 1.1
    8. Install .NET Framework 1.0 SP3 or 1.1 SP1
    9. Return to the Regional and Language Options control panel and change the language in the Advanced tab back to the original setting

    For reference, here is what the Advanced tab of the Regional and Language Options control panel looks like.  This screenshot is from my laptop, where I was able to reproduce the failure to install the .NET Framework by changing my system locale to Welsh (one of the 25 new ELKs included in XP SP2):

    Regional and Language Options control panel Advanced tab

    <update date="7/26/2005> As Michael Kaplan points out, the underlying bug affects both the .NET Framework core setup and the .NET Framework service pack setup.  Once a computer has .NET Framework 1.0 + SP3 and/or 1.1 + SP1, the bug will not affect any future .NET Framework service packs.  In addition, the bug can happen if your computer has a default user locale set to one of the new ELK languages, not just a default system locale. </update>

    <update date="4/17/2008"> Added a note indicating that the issue in this post can affect the .NET Framework 1.0 and 1.1 setup on Windows Vista and not just Windows XP SP2 </update>


  • Aaron Stebner's WebLog

    Installing .NET Framework 2.0 breaks Windows Media Center


    I got some feedback from Paul Ballard based on my blog post yesterday about why we block users from installing the .NET Framework 1.0 SDK on Windows Media Center and Tablet PC.  In it, he noted that he tried to install beta versions of the .NET Framework 2.0 on his Media Center computer and it caused all sorts of problems and asked when this issue would be fixed.  I posted a reply in the comments of the other post, but I wanted to post a standalone blog item to make this issue more visible.

    The version of Media Center we're currently working on will have this fix so that you can install .NET Framework 2.0 and not have it interfere with Media Center functionality.  In the meantime, you can use the following steps to manually fix your machine to work around this issue:

    1. Go to %windir%\ehome on your Media Center machine
    2. Create files named ehrec.exe.config, ehrecvr.exe.config, ehsched.exe.config, ehshell.exe.config and medctrro.exe.config
    3. Open each of these files in notepad and add the following information to them:
      <supportedRuntime version="v1.0.3705" />
    4. Restart your machine so that the config file changes will take effect for processes that might have already been running when you created the files

    Also, as a convenience, I created copies of these config files with the correct contents.  So if you prefer, you can skip steps 1-3 above and instead simply download the config files from this location and extract the contents to %windir%\ehome on your machine and reboot and you should be good to go.


  • Aaron Stebner's WebLog

    Tricks for deciphering HRESULTs not listed in my previous 1935 error article


    Ever since I published my blog post describing 1935 errors in more detail, I have been contacted by customers who have received various different 1935 errors during setup that have HRESULT values that are not listed in the table of common error codes in that post.  Most of the HRESULT values correspond to common Win32 error codes, and so I decided to post a link to a table of those common errors.  However, over the course of this weekend I was not able to find a good page to link to.  However, I did find a nice resource that my former team (Windows Embedded) published that provides a handy way to translate some of the error codes.  You can look at the page here, and I'll provide a brief summary as well.

    Many common Win32 HRESULT values take the form 0x8007xxxx, where "xxxx" is some 4 digit number.  You can open a cmd prompt and type net helpmsg xxxx (where xxxx is that additional 4 digit number left over after dropping the first 4 digits after 0x) to display a text explanation of what this error code means.  For example, here are some common HRESULTs that are seen in some 1935 errors

    • net helpmsg 2 prints out "the system cannot find the file specified" (info about this 1935 error can be found here)
    • net helpmsg 3 prints out "the system cannot find the path specified"
    • net helpmsg 5 prints out "access denied"
    • net helpmsg 126 prints out "the specified module could not be found"

    Sometimes error codes will be displayed as very large negative numbers like -2147024891.  In order to use net helpmsg, you need to first convert this number to hexadecimal.  To do this, I usually do the following:

    1. Run calc.exe
    2. Go to the View menu and choose Scientific
    3. Choose the Dec radio button at the top
    4. Type in the large negative number
    5. Click on the Hex radio button to convert it to hexadecimal
    6. Drop the leading F's and then the first 4 digits after the F's
    7. Run net helpmsg xxxx with the number that remains

    I also use a tool called errlook.exe to translate HRESULT values into human readable error strings.  This tool is a utility that ships as part of some versions of Visual Studio and it will index header files if you have any Platform SDKs installed on your machine, so it will provide translations for a lot of errors that net helpmsg cannot.  In addition, I found a link to a command line tool called err.exe that is available for download here.  It is listed as an Exchange Server tool but it appears to be a generic error code lookup utility and you don't have to have Visual Studio to get it.

    Hopefully this will help you narrow down some of the common root causes of 1935 errors that can occur during .NET Framework or other product setups.  Also, if anyone knows of a nice web page that contains a comprehensive list of error codes that I can link to in addition to the above tricks, please post a comment....


  • Aaron Stebner's WebLog

    How to unblock Windows Server 2003 SP1 setup if a beta version of SP1 is installed on the machine


    I received this comment from a customer last week, and some investigation led to an interesting problem and solution I wanted to share here.  This customer was having trouble and getting some odd errors while installing and trying to use Symantec System Center on Windows Server 2003.  The customer reported that they have Windows Server 2003 service pack 1 installed on this machine.  Initial troubleshooting showed that the version number of the Windows Installer files on this machine were 3.1.4000.1289.

    Based on some past experience, I knew that build 1289 was not the final build number for Windows Server 2003 SP1 (it is actually 1830), so I asked the customer for some additional information to try to figure out how the machine got into the state it was currently in and then figure out how to upgrade it to the final release of SP1.  It turned out that this machine had a beta build of SP1 installed, but SP1 was installed using a slipstream method that caused it to not allow the user to uninstall it.  This was complicated by some setup logic in the final release of SP1 and in the installer package for Windows Installer 3.1 that blocked the customer from being able to install the final build of SP1 or the final release of Windows Installer 3.1.  The setup UI for SP1 told the customer to go uninstall the beta version of SP1 first, but since SP1 was installed via slipstream, there was no Add/Remove Programs entry, and the files were not cached in the %windir%\$NtServicePackUninstall$\spuninst folder to allow for manual uninstall either.

    Since this machine was currently being used in production, we wanted to try to avoid needing to rebuild it from scratch.  I used some knowledge I had from previous projects about how Windows service pack setup logic works to see if I could trick the installer into letting me run it even though there was a beta build of SP1 installed.  Windows service packs and hotfixes use the following registry key/value to determine what OS service pack is installed and then decide whether or not to allow the user to run setup based on this data:

    • Key Name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows
    • Value Name: CSDVersion
    • Data Type: REG_DWORD
    • Value Data: multiples of 256 - for example, if SP1 is installed the value = 256, if SP2 is installed the value = 512, etc

    So, what I saw on the customer's machine was tha tthis value was set to 256, which made SP1 setup think SP1 was already installed.  I changed this value back to 0 and re-ran Windows Server 2003 SP1 setup and it allowed me to install and correctly updated all of the files and registry to the final released version of SP1.  Once I did this, I saw that the version of Windows Installer files now showed 3.1.4000.1830.  Then, the customer re-tried the Symantec System Center scenarios that were failing previously, and things started working as expected.

    Please note that this method of working around the beta block inside of Windows Server 2003 setup is not an officially supported method.  But if you are stuck and want to try to avoid rebuilding your server, this might be an option for you.  Just make sure that you make a system backup of some sort before doing so (or be willing to accept rebuilding if things don't work as well as they did in this customer's scenario).


  • Aaron Stebner's WebLog

    Why can't I install the .NET Framework SDK v1.0 on Media Center (or Tablet PC for that matter)?


    I've been meaning to tell this story for a while, and now that I'm working on the Media Center team, this story ends up being a nice intersection between my first team at Microsoft and my current team.  So, here it goes....

    When I was on the Visual Studio and .NET Framework setup team, one of the most interesting projects I got to work on was the integration of the .NET Framework 1.1 into OS setup for Windows Server 2003.  This project required our setup team to convert our MSI-based installer into an OCM installer that can be run during OS setup.  We started this project in between beta 1 and beta 2 for .NET Framework 1.0 in order to be able to test with pre-release versions of Windows Server 2003, and we checked in beta builds of .NET Framework 1.0 to Windows Server 2003 periodically throughout the .NET 1.0 product cycle (if you were in the beta program for Windows Server 2003, you might have noticed .NET Framework 1.0 being installed with the OS back then).

    Somewhere during the final phases of the .NET Framework 1.0 and Visual Studio .NET 2002 ship cycle, the Windows XP service pack 1 project was getting going.  The Media Center and Tablet PC teams were working on their first releases to coincide with XP SP1 and they were writing their features in managed code using the .NET Framework 1.0.  There was a decision made to create new editions of Windows XP for Media Center and Tablet PC, and we needed a way to get the .NET Framework 1.0 installed as part of those OS's so managed code would run correctly out of the box to support their new features.  Since our team was already in the process of doing this setup conversion work, the decision was made to back-port this work and make it work for the .NET Framework 1.0 on Media Center and Tablet PC OS's.

    The final decision to use an OCM installer to deliver the .NET Framework 1.0 to these new Media Center and Tablet PC editions of Windows XP was made right after we shipped the MSI version of .NET Framework 1.0, and this introduced a new set of scenarios that we had not designed for or tested.  Specifically, we had not planned for any kind of interations between a version of the .NET Framework 1.0 installed by OCM and a version of .NET Framework 1.0 installed by MSI.  Because the .NET Framework 1.0 MSI had already shipped, this limited our engineering options, and we already knew based on our knowledge of installation technologies and some high-level proof-of-concept testing that if we allowed the user to install and uninstall the .NET Framework 1.0 MSI on Media Center or Tablet PC, the reference counting schemes would not work correctly and some files and registration would be removed out from under the features in these OS's that needed them.  In addition, creating and installing service packs and hotfixes for the .NET Framework would have become more complicated if we alllowed a computer to have the .NET Framework 1.0 installed on it using both the OCM and MSI technologies.

    As a result of these scenarios and some others that I am probably forgetting (since this all happened back in early 2002), we decided to block the user from installing the .NET Framework 1.0 MSI on Media Center and Tablet PC computers since it will already be installed by OS setup using the OCM version.  We worked with the Windows application compatibility team to have them implement a hard-coded block for the .NET Framework 1.0 MSI on these OS's.  This block intercepts MSI installation requests and compares the product code against a known list, and if the product code is on the list then the installation is blocked.  It is basically impossible to get around this block without some serious hacking/reverse engineering that would be unsafe for future servicing of the product.

    This decision was complicated by a couple of poor setup designs that existed in the .NET Framework 1.0 timeframe that have since been fixed:

    1. The .NET Framework 1.0 shipped a separate dotnetfx.exe for each non-English language of the product.  Each of these packages contained an MSI that installed about 90% of the exact same files and some additional language-specific resource files, and this MSI had a different product code for each language.  Because 90% or more of the product was the same for each language, all of the uninstall and servicing issues existed for non-English versions and we had to block the non-English .NET 1.0 packages from installing on Media Center and Tablet PC using the same application compatibility feature described above.  However, this would have meant that users would have no way to install language-specific resource files on these OS's.  So we decided to bundle all 9 languages of the resource files that shipped with the original .NET Framework 1.0 and install them on all langauge OS's for Media Center and Tablet PC.  This was not exactly pretty and added a small amount of size bloat to those OS's (around 1 megabyte on the OS installation disk and around 10 megabytes on the OS after setup completed), but overall the solution has proven to work pretty well for us, and I can't recall getting any questions or complaints about this issue.
    2. The .NET Framework 1.0 SDK included the .NET Framework 1.0 redistributable files as part of their product MSIs.  This made the SDK susceptible to the exact same set of uninstall and servicing issues described above.  Since the SDK is a couple of hundred megabytes in size, we could not use the same strategy as we used for language resources.  We decided to block the user from installing the .NET Framework 1.0 SDK on Media Center and Tablet PC using the same application compatibility feature described above.  This means that a developer who wants to install the standalone .NET Framework SDK on these OS's is not able to.  This decision was one of the hardest ones we made for this .NET Framework 1.0 OCM project, but we had to weigh the significant uninstall and servicing problems against the size of the market of people who would really want or need to install the standalone .NET 1.0 SDK on these OS's and against the available workaround of installing any version of VS .NET 2002 to gain access to .NET 1.0 SDK bits on these OS's if necessary.  In retrospect, I think we made the best decision available to us considering these constraints.  We have had a few customers inside and outside of Microsoft ask us why they can't install the .NET Framework 1.0 SDK and also ask why it tells them that the SDK is part of their operating system (this is the error message that appears when the application compatibility block kicks in and stops them from installing the .NET 1.0 SDK).

    As a side note - if you are familiar with the setup and packaging for the .NET Framework 1.1 and 2.0, you will notice that both of the complicating issues listed above that affected the .NET Framework 1.0 were addressed starting in .NET 1.1.  We split the language resources into separate satellite language packs and consolidated the common files into a single "core" redistributable package with a single MSI product code.  In addition, we decoupled the redistributable files from the SDK files and made the .NET Framework SDK setup block and require the user to install the redistributable package as a prerequisite.

    The other cool thing about this .NET Framework 1.0 OCM project was that we got some practice working through OCM/MSI setup technology interaction issues.  As a result, we learned some key lessons before we shipped .NET Framework 1.1 as a part of Windows Server 2003 and engineered solutions before that product shipped.


  • Aaron Stebner's WebLog

    How to silently install MSDN to a non-default location


    I got a question from a customer who is trying to use the instructions in this blog post to perform a silent installation of VS 2005 and MSDN.  They ran into a problem where MSDN installation failed, and tracked it down to an issue where the C drive on the machine did not have enough available disk space to install all of the help content.  Setup was silently failing because it was being run in silent mode, and the customer had to rerun MSDN setup with verbose logging (using the steps here) to figure out why it rolled back.  Once the customer figured this out, they noticed that if MSDN setup is run with full UI, they could change the path in the UI and install successfully.  So the next question logical question was how to modify the silent install command line parameters to allow MSDN to install to a non-default path.  After digging through the verbose log file, the MSDN MSI, and finally talking to a developer I know on the MSDN setup team, here is a command line that can be used to install MSDN setup silently to a non-default path:

    setup.exe MSDN_QTR.3643236F_FC70_11D3_A536_0090278A1BB8="MyPath" /qn
    In this command line, MyPath can point to any non-default location - for example d:\Program Files\MSDN\.  The path does need to be quoted in this command line.  Also note that if you want to, you can change /qn to /qb to cause a small progress dialog to appear during MSDN setup.


  • Aaron Stebner's WebLog

    VS 2005 July CTP now available for MSDN subscribers


    Hey, I just noticed that the first phase of the VS 2005 July Community Technology Preview (CTP) is available on the MSDN subscriber download site.  Unfortunately, it looks like downloads for non-subscribers won't be available until phase 2.  Here is the wording from the subscriber download page:

    The Visual Studio 2005 July Community Technology Previews will be delivered in three phases during the month of July:

    • Drop 1: Visual Studio 2005 Standard Edition, Visual Studio 2005 Premier Partner Edition, and the Visual Studio 2005 SDK for use with Drop 1 and Drop 2
    • Drop 2: Visual Studio 2005 Professional Edition, Visual Studio 2005 Express Editions, Visual SourceSafe 2005, and Visual Studio 2005 Tools for the Microsoft Office System
    • Drop 3: Visual Studio 2005 Team Suite, Visual Studio 2005 Team Foundation Server, and the Visual Studio 2005 SDK for use with Drop 3

    It looks like the Express editions in drop 2 will be available for free download, but the others will be in the subscriber section only.

    The site http://channel9.msdn.com/ctpmadness/ has also been updated to provide a quick way to check compatibility issues between SQL 2005 builds and VS 2005 July CTP builds.


  • Aaron Stebner's WebLog

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


    I've been reading Rob Mensching's series about the MSI directory table in his blog (here, here, here and here so far) and I really liked the format of telling a technical story in smaller parts, so I decided to try to find a topic that I could write about in a format like this.  I have been searching for more Media Center-centric themes to write about so that I can start immersing myself more deeply into the features of the product as opposed to just the setup technologies that help us install it.   So I thought I would try the end-to-end experience of creating some kind of Media Center add-in and write about it in stages as I try things out (partially because I'm not sure how much spare time I'm going to have to dedicate to this project over the next few weeks since I've got family and friends visiting this summer to enjoy the beautiful Seattle weather and writing it in a series like this allows me to space it out if I need to....).  At any rate, here goes nothing....

    I decided to try to learn how the process works for a 3rd party developer who wants to develop content/applications that can plug into Media Center.  Granted, I work on the team and at Microsoft and as such have more knowledge about how things work behind the scenes in our product than a 3rd party developer would (I have a source code enlistment and can start reading code and debugging if I get really stuck for example).  But I'm going to try my best throughout this process to limit myself to the same set of resources a non-Microsoft employee would have in order to better understand the pain points and see what things are really like for our customers and partners.

    I begin my adventure tonight armed with relatively little knowledge about how to develop apps for Media Center.  I know at a really high level that Media Center has an extensibility model and that there is an SDK that customers can download, so I figured the best place to start would be to download and install the SDK.  I started by going to the main Microsoft Windows Media Center site to find the SDK download location.  Try as I might, I could not find any information about the SDK by looking at the content accessible from this site.  It does a really good job of highlighting why someone would want to use Media Center, and it gives advanced tips for setting up some of the trickier aspects of Media Center (HDTV recording for example), but the only downloads I can find are some power toys and some generic Windows XP downloads that are not specific to Media Center.  Note to self - I'll have to ask around at work and see if I'm missing something obvious here or if it really isn't possible to find any SDK info from the main Media Center page....

    Since I know from talking to friends who are Media Center enthusiasts that there is an SDK somewhere on the web for download, I used the search box in the top right corner to search for "Media Center SDK" and found the Media Center Developer Center and also what appears to be the SDK documentation site.  After a couple of clicks on the Developer Center, I've arrived at the download page for the Media Center SDK.  This page "recommends" that I validate that I'm running a genuine copy of Windows, but it appears the only way to get to the actual download link is to go through the validation page (even though it is not "required").  On the next page, there is a radio button where I can opt out of this validation, so I skip it for now just to see if it is really mandatory or still optional.  Ah hah, finally I arrive at the page where I can download and run the setup MSI package for the Media Center SDK.  After a few clicks through the setup wizard (which appears to have been developed using the Visual Studio setup and deployment project wizard, and which I confirmed to be the case by glancing at the MSI in Orca), I've got it installed and it conveniently opens C:\Program Files\Microsoft\Microsoft Windows XP Media Center SDK for me to start browsing through the stuff I just installed.

    Since it is pretty late and I'm getting tired, I'm going to stop here for now.  I'll pick this up again soon and see if I can figure out where I want to start now that I've got this SDK installed and I appear to be ready to start developing an add-in for Windows Media Center....

    [to be continued]


  • Aaron Stebner's WebLog

    Suggest a topic for me to write about


    I have been keeping a folder on my computer where I drop emails that I send myself with ideas for future blog posts.  However, I was browsing for some information yesterday and stumbled across Michael Kaplan's blog.  I really liked how he had a set of articles called "administrivia" where he outlined his editorial, comment and contact policies and also provided a way for readers to suggest interesting topics for the future.  So I decided to add a similar section to my blog.  I am starting out by creating a post where you can suggest topics and also where I'll keep the list of topics I've got in my queue for the future.  I'll try this out for a while and see how it goes - it has to be better than my current method of scanning a folder and re-reading emails I've sent to myself...


  • Aaron Stebner's WebLog

    Sample code to enumerate .NET Framework versions


    I found an interesting post that lists some sample code to enumerate the installed versions of the .NET Framework using APIs inside of mscoree.dll (which is the shim DLL that decides which version of the .NET Framework to load for each managed application that runs on a computer).  This code comes directly from the development team that works on mscoree.dll itself, and it is going to eventually be shipped in the .NET Framework SDK.  Check it out here.


  • Aaron Stebner's WebLog

    Check out the Windows Installer team blog....


    Hey, I just recently noticed that there is a new blog that the Windows Installer team created to post information about upcoming releases of Windows Installer, offer troubleshooting techniques and general tips and tricks.  You can check out their blog here, and I also added a link to it in my Setup Blogs section.  One of the other blogs in my Setup Blogs section is written by Robert Flaming.  He recently joined the Windows Installer team, and he has been posting some FAQ items on the Windows Installer team blog that are being gathered from one of the Windows Installer question-and-answer aliases that exists within Microsoft.  It is really cool to see some of the questions asked by setup developers here at Microsoft being propagated out to help shed light on some of the mysterious behaviors of Windows Installer.


Page 1 of 1 (14 items)