I have been exploring creating MSI packages to install Media Center add-ins as part of my ongoing project to create my own Media Center add-in.  During this process, I have discovered a couple of interesting behaviors of the RegisterMceApp.exe tool that we provide for add-ins to register themselves with Media Center:

1. If you try to register an add-in that is already registered, RegisterMceApp.exe throws an exception and returns a non-zero value
2. If you try to unregister an add-in that is already unregistered, RegisterMceApp.exe throws an exception and returns a non-zero value

These 2 facts make it somewhat complicated to launch RegisterMceApp.exe as a custom action to register an add-in using an MSI-based setup package.  I talked to the developer who worked on this EXE and he provided the following suggestions that do not appear to be documented in the Media Center SDK currently:

1. An MSI that calls RegisterMceApp.exe as a custom action should first call it in unregistration mode.  This will ensure that any currently registered version of the add-in is removed.  The custom action should be flagged to ignore the return code in case the add-in is not currently registered so that a failure to unregister will not cause setup to rollback
2. An MSI should call RegisterMceApp.exe in registration mode during install and repair/reinstall, and it should obey the return code.  However, it should make sure to call unregister first to avoid the exception that can be thrown if a previously registered add-in is registered again.

I realize that all of the above is fairly complicated.  I am working on an example MSI package using WiX to demonstrate how to create a well-behaving Media Center add-in.  Hopefully this example will demonstrate all of these concepts in a clearer way.  I hope to have this example published soon (in the next week or so....)

I decided to create a new post category for my blog entitled Mailbag.  Periodically, I will pick out interesting questions that come from readers who post comments on my blog or send them directly to me via my contact link and answer them as standalone blog posts.

I will probably tend to pick questions that relate to interesting design or implementation decisions regarding features of Microsoft that I have worked on and that I know about some of the background behind.  I will still continue to post about issues and workarounds to specific bugs in separate posts as I have time as well.  I am planning to play this idea by ear and see how it works out over the next few weeks and then decide whether or not to keep it going long-term.

Without further ado, here is the first edition of my mailbag....

Question

When I installed Visual Studio 2005, I found SQL Express in the feature tree and chose to install it.  Then I decided to uninstall SQL Express (in order to install SQL Server 2005 Developer Edition), so I went to Add/Remove Programs and launched Visual Studio 2005 setup again and chose Add or Remove Features.  However, SQL Express was not in the feature tree anymore.  Why not?  And how can I uninstall SQL Express?

Answer

In order to uninstall SQL Express, you can go to Add/Remove Programs and choose the item named Microsoft SQL Server 2005.  Uninstalling this item will remove all relevant SQL 2005 items from your system (even though you will see several SQL-related items if you look around in Add/Remove Programs).

SQL Express is chained during Visual Studio 2005 setup so that it appears to be a feature in the VS setup feature tree.  However, behind the scenes, it is actually a separate setup package that can be installed and uninstalled independently of VS.

Visual Studio 2005 setup contained a new feature designed to support chaining optional products after the main vs_setup.msi is installed.  These optional products are separate standalone setup packages that can be installed as part of VS or on their own.  We made a simplifying assumption when designing this setup feature - during initial installation of Visual Studio 2005, setup would detect whether or not the package is installed and offer to install it if it was not already present.  However, VS does not offer the ability to uninstall the package as part of maintenance mode setup (though it will attempt to repair it if you choose to repair VS).

We decided not to integrate the uninstall because it would be overly complicated and error-prone to attempt to keep track of whether or not Visual Studio was the one to originally install the package and also keep track of whether or not other products on the system needed the package.  Making an incorrect decision about uninstalling the package could leave other products on the system in a non-functioning state.  For example, if some product other than Visual Studio 2005 relied upon SQL Express, Visual Studio 2005 could break that product if it uninstalled SQL Express out from under it.

The major benefit of this design decision was that it provided VS 2005 setup with the ability to selectively install packages via user choices in the feature tree.  The primary scenario this solved was the common complaint from VS .NET 2003 that users were forced to install the J# redist even if they did not plan to do any J# development.

The major drawbacks of this design decision are the following:

1. It creates a more complicated uninstall if you want to remove the entire VS 2005 product.  This is seen most clearly in a lot of the beta uninstall issues where VS was uninstalled in the "wrong" order, which ended up orphaning old beta files on the system
2. Installing VS 2005 creates a large number of entries in Add/Remove Programs

One other note about this question - it is not technically necessary to uninstall SQL Express in order to install SQL 2005 Developer Edition.  It is a little bit redundant to have both installed, but it won't hurt anything because Windows Installer will reference-count things correctly.  You will end up with an additional SQL instance on the system however.

I have written several posts in the past about 1935 errors that can happen during the installation of the .NET Framework and other applications that install managed code to the GAC (most notably, this troubleshooting guide).

Starting in version 2.0, you will no longer see 1935 errors during .NET Framework redistributable setup.  This is because we created a new custom action to install assemblies to the GAC instead of using the built-in MsiAssembly and MsiAssemblyName tables.  This custom action was created to eliminate the need to carry 2 copies of each assembly in the setup package for the .NET Framework in order to install to both the GAC and the local file system.  More information about why we would otherwise need to carry 2 copies of each assembly can be found in this previous blog post.

The custom action that installs assemblies to the GAC during .NET Framework setup calls fusion APIs directly and uses information in the custom MSI tables named Assembly and AssemblyName (instead of MsiAssembly and MsiAssemblyName) to determine what assemblies to install to the GAC.  The custom action also logs a new set of error codes in case of any failures.

The following is a list of all possible assembly installation errors that can occur during .NET Framework 2.0 setup:

• 25000 = "Unexpected error occurred during assembly configuration. This setup package may be bad."
• 25001 = "Unexpected error occurred during assembly configuration. Function '[2]()' returned [3]."
• 25002 = "Error occurred while initializing fusion. Unable to load [2]. System error: [3]"
• 25003 = "Error occurred while initializing fusion."
• 25004 = "Failed to execute query '[2]'. Is table AssemblyName missing in the MSI package?"
• 25005 = "There's no matching record for component '[2]' in AssemblyName table."
• 25006 = "Error occurred while initializing fusion. Setup could not find function 'LoadLibraryShim' in mscoree.dll. System error: [2]"
• 25007 = "Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: [2]"
• 25008 = "Unexpected error occurred during assembly installation."
• 25010 = "Failed to install assembly '[2]' because the check of the module's hash failed." (the equivalent of fusion error code

  0x80131039 - COR_E_MODULE_HASH_CHECK_FAILED)
  25011 = "Failed to install assembly '[2]' because one or more modules specified in the manifest cannot be found." (the equivalent of fusion error code 0x80131042 - FUSION_E_ASM_MODULE_MISSING)

• 25012 = "Failed to install assembly '[2]' because one or more modules were streamed in which did not match those specified by the manifest. Invalid file hash in the manifest?" (the equivalent of fusion error code 0x80131043 - FUSION_E_UNEXPECTED_MODULE_FOUND)
• 25013 = "Failed to install assembly '[2]' because strong name signature could not be verified. Was the assembly built delay-signed?" (the equivalent of fusion error code 0x80131045 - FUSION_E_SIGNATURE_CHECK_FAILED)
• 25014 = "Failed to install assembly '[2]' because of invalid file or assembly name. The name of the file must be the name of the assembly plus .dll or .exe." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during install)
• 25015 = "Failed to install assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during installation)
• 25020 = "Failed to uninstall assembly '[2]' because the strong name is not valid." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during uninstall)
• 25021 = "Uninstall of assembly '[2]' is not allowed." (the equivalent of fusion error code 0x80131049 - FUSION_E_UNINSTALL_DISALLOWED)
• 25022 = "Failed to uninstall assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during uninstallation)

I have heard from several customers who have asked me what the differences are between the .NET Framework 1.1 to the .NET Framework 2.0 and whether or not they should migrate their existing .NET applications from 1.1 to 2.0.  This question does not have one simple answer, but one of the big factors in this type of analysis is whether or not a given application that was designed to run on the .NET Framework 1.0 or 1.1 will continue to function on the .NET Framework 2.0.  To help answer this question, Microsoft has published a list of APIs that have been marked as obsolete starting with the .NET Framework 2.0.  You can check out this MSDN site to take a look at the full list of .NET Framework APIs that have been flagged as obsolete between 1.1 and 2.0.

In a future blog post, I will look at some other facets of this question, including how publisher policy plays a role in deciding what version of the .NET Framework an application should target.

I just noticed today that several additional language packs for the .NET Framework 2.0 have been released and are now available for download:

• Chinese (Traditional)
• French
• German
• Italian
• Korean
• Spanish

I previously blogged about the Japanese language pack when it was released last month.  There is a lot of information in that previous post about how to detect the presence of the .NET Framework 2.0 language packs, how to install them silently, and so on.  Please let me know if you have any questions about the language packs that I have not yet covered in my blog.

We have released a couple of new update rollup packages to fix some issues that have been seen with Update Rollup 2 for Media Center 2005.  They are the following:

1.  January 2006 Update Rollup for Windows XP Media Center Edition 2005 (KB912067)

This package replaces the previous update for Media Center 2005 (KB908250).  It will only be offered if you have Update Rollup 2 for Media Center 2005 installed.  It contains all of the fixes released in previous hotfix packages, and fixes some additional issues:

• A playback initialization error occurs on resume when you suspend or hibernate a computer that is playing a DVD
• Teletext subtitles disappear after you use pause, rewind, fast forward or play controls
• Electronic Program Guide shows scrambled DVB-T channels
• DVB-T services are not found
• Support for additional optical media drives for DVD burning
• Interoperability with some third-party TV software

You can read more details about the bug fixes in this package in this knowledge base article.

This package is available on Windows Update as a recommended update as of January 24, 2006.

2.  Update Rollup 2 for eHome Infrared Receiver for Windows XP Media Center Edition 2005 (KB912024)

This package replaces the previous update for eHome Infrared Receivers (KB888795).  It will only be offered if you have Update Rollup 2 for Media Center 2005 installed.  It contains all of the fixes released in previous hotfix packages, and fixes some additional issues related to installation of updated driver files while the device is already connected to the computer.  You can read more details about the bug fixes in this package in this knowledge base article.

This package will be available on Windows Update as a recommended update sometime in February 2006.

<update date="1/24/2006"> Added information about the availability of these packages on Windows Update </update>

Ever since I posted this blog entry last month about how the Administrative Tools shortcuts were moved from the .NET Framework 2.0 redistributable to the SDK, I have gotten multiple follow-up questions and comments from customers about this scenario.  In most cases, the folks who contacted me are system administrators who manage servers and want to change .NET Framework security settings but do not want to incur the overhead of installing the entire SDK on their server.

I was on the .NET Framework setup team when the decision was originally made to move the configuration tool to the SDK and remove the wizard tool altogether.  At the time, the setup team and the feature teams decided that these type of graphical user interfaces were advanced features more appropriate to an SDK than to a redistributable that is intended to be installed on end-user machines.  For example, many end users on XP Home found it strange to see administrative tools related to a product called the .NET Framework that they did not know was even installed on their system (because it was pre-installed by their OEM or via some other application).

However, after hearing so much feedback I decided to dig into this scenario in a bit more detail, especially considering that I hadn't thought through the scenario where a system administrator would have to install a 300+ megabyte SDK in order to manage security policy settings.

According to the folks I know on various .NET Framework teams, the official way to administer security settings on a system that only has the .NET Framework 2.0 redistributable installed (and not the .NET Framework 2.0 SDK or Visual Studio 2005) is to use the command-line tool named caspol.exe that ships in %windir%\Microsoft.NET\Framework\v2.0.50727 as part of the .NET Framework 2.0 redistributable.  There is some in-depth information about how to do this in this MSDN document.

That being said, I decided to look into the .NET Framework 2.0 SDK setup to see exactly how the configuration tool is installed and determine whether or not there is an easy way to extract that information and transplant it onto a machine with only the .NET Framework 2.0 redist installed.  I started by downloading the .NET Framework 2.0 SDK, extracting netfxsdk.msi from the setup.exe package and opening it in Orca.  I found the following information:

• The configuration tool appears to be comprised of 4 files - mscorcfg.dll, mscorcfg.msc, mscormmc11.cfg and mscormmc.dll
• The file mscorcfg.dll is installed to the GAC and to the local file system
• There are several registry entries associated with the component that installed mscormmc.dll
• There is a shortcut to mscorcfg.msc that gets installed to the Administrative Tools folder on the system

Armed with this data, I decided to experiment a bit and see if I could build an MSI package that would install the configuration tool on a system that already had the .NET Framework 2.0 installed.  I used the WiX toolset and created an MSI with the information described above.  Then I installed it on a system that had only the .NET Framework 2.0 redistributable and it appeared to work correctly, though I haven't used this tool much in the past to truly know how well it was functioning.

If you are curious, you can see the WiX source (WXS) file that I created for this experiment to get a better idea of how things are structured, and you can compile it into an MSI yourself by downloading the latest build of the WiX toolset.  Alternatively, you can download a compiled version of this MSI from this location.

Please note that while it appears to work correctly, this method of installing the .NET Framework 2.0 configuration tool is unsupported.  For example, if any security related issues were to be found in any of these files, they would not be serviceable if installed on a system using a means such as this.

<update date="12/17/2008"> Updated the WiX source code from WiX v2.0 to WiX v3.0 and added a download link for the compiled MSI. </update>

<update date="3/11/2009"> Updated download links to point to my new file server. </update>

I have heard from several customers who have run into problems installing Visual Studio 2005 because the component named Microsoft Document Explorer 2005 fails to install and Visual Studio setup quits when that happens.  I wanted to give a bit more information about what this component is and where logging information can be found to attempt to track down why this installation might fail.

Document Explorer 2005 is a redistributable package that delivers the 8.0 version of dexplore.exe.  This is the help viewer that is used by Visual Studio 2005, and by other products such as the Windows SDK.  In previous versions of Visual Studio, dexplore.exe was installed as a part of the main Visual Studio MSI or as a part of the MSDN MSI, but in VS 2005, it was separated into its own standalone package, and it is installed as a prerequisite before the main Visual Studio MSI.

The setup for Document Explorer 2005 uses the same external UI handler as the .NET Framework 2.0 redistributable and SDK (described in more detail in this blog post and in this blog post).

Visual Studio 2005 setup runs the setup package for Document Explorer 2005 in silent mode.  In cases where this package fails during Visual Studio 2005 setup, you can run dexplore.exe directly from the folder <VS install disc>\wcu\DExplore\ in order to see the error message that is being generated.

This package creates the following log files in the %temp% directory on a system:

• dd_dexploreui*.txt
• dd_dexploremsi*.txt

In both of these cases, the * in the name of the files is a randomly generated ending to ensure that each time you run setup it will create a unique file and not overwrite existing log files.

If you do not get any useful error information by running the setup package directly, it can be useful to examine the contents of these log files.  In particular, you can search for the string return value 3 in dd_dexploremsi*.txt and that will usually lead you to the error that causes the setup package to fail.

If you have trouble locating error information, please contact me or leave a comment on this blog post and I will try to help.

We found an issue over the holidays related to unattended installations of Visual Studio 2005 on Windows Vista.  This issue was reported by a Microsoft employee trying to create a script to deploy Visual Studio 2005 in a lab of computers running Windows Vista.  What he found is that creating the unattended INI file on Windows Vista incorrectly detects that it needs to install the .NET Framework 2.0, and then the installation fails because the .NET Framework 2.0 is already installed as part of the OS on Vista.

In order to workaround the issue we found, you will need to use the following steps to deploy Visual Studio 2005 using unattended mode on Windows Vista:

1. Launch Visual Studio 2005 setup on a Windows Vista machine that does not already have VS 2005 installed by running <VS install location>\setup\setup.exe /createunattend vs_2005_vista.ini
2. Select the components you want to install in the VS setup selection tree and save the INI file
3. Open the INI file in a text editor such as Notepad
4. Locate the [PreInstallOrder] section and remove the lines gfn_mid framework, gfn_mid framework ia64 and gfn_mid framework amd64
5. Locate the [InstallOrder] section and remove the lines gfn_mid framework, gfn_mid framework ia64 and gfn_mid framework amd64
6. Locate the [PostInstallOrder] section and remove the lines gfn_mid framework, gfn_mid framework ia64 and gfn_mid framework amd64
7. Locate the [gfn_mid framework] section and change the line that says InstallActionInteger=5 to say InstallActionInteger=1
8. Locate the [gfn_mid framework ia64] section and change the line that says InstallActionInteger=5 to say InstallActionInteger=1
9. Locate the [gfn_mid framework amd64] section and change the line that says InstallActionInteger=5 to say InstallActionInteger=1
10. Save and close the INI file
11. Run <VS install location>\setup\setup.exe /unattendfile vs_2005_vista.ini

Important notes about the above steps:

• Please note the folder location in the command line to run both /createunattend and /unattendfile mode.  Those parameters only work for the copy of setup.exe in the setup subfolder.  They do not work for the copy of setup.exe in the root of the installation disc.
• You must create the INI file on the same OS that you plan to install it on.  For example, you cannot create an INI file on Windows XP and then install using that INI file on Windows Vista.
• You can use the steps listed in this blog post to stage Visual Studio 2005 on a network and chain MSDN setup after VS setup if desired.

These steps have been documented in the online version of the Visual Studio 2005 administrator mode readme.  Note that this item was added after VS 2005 shipped, so if you look at the copy of the administrator mode readme located at \setup\adminreadme.htm on your VS 2005 installation disc, you will not see this additional note about Windows Vista.

The underlying bug in Visual Studio unattended mode is that it tries to re-install a component even if it is already on the system.  Since the .NET Framework 2.0 is already present as an OS component on Windows Vista, this will cause Visual Studio unattended setup to fail.  This issue can also affect Windows XP and other non-Vista operating systems if the .NET Framework 2.0 SP1 or .NET Framework 2.0 SP2 are already installed on the computer.  If you are running Visual Studio setup in unattended mode on Windows XP or Windows Server 2003 and that system already has the .NET Framework 2.0 SP1 or 2.0 SP2 installed, then you will need to use the workaround listed in this blog post there as well.

<update date="11/25/2009"> Added a note about how this scenario can affect other operating systems besides Windows Vista. </update>

I heard from a customer recently who installed the final release of Visual Studio 2005, launched the VS 2005 IDE and received an error message stating that the J# redistributable package was not correctly installed.  After some investigation, we discovered that the final release of the J# redistributable was not actually installed on the system.  It turns out that there is another potential issue related to VS 2005 beta uninstall that is very similar to the .NET Framework issue described in this previous blog post.

The underlying problem on this customer's system was that VS setup detected that the J# redistributable package 2.0 was already installed and skipped trying to install that package during VS setup.  However, the system did not actually have the J# redistributable package 2.0 installed, but instead only had the registry key that VS setup uses to detect whether or not the J# redist is installed.  I found that the machine had the following orphaned registry key/value that VS setup uses to determine whether or not the J# redist 2.0 is already installed:

• Key name: HKLM\Software\Microsoft\Visual JSharp Setup\Redist\v2.0.50727
• Value name: Install
• Data type: REG_DWORD
• Value data: 1

Once the customer deleted this key/value and re-ran the J# redistributable package 2.0 setup from the \wcu\JSharpRedistCore\ folder on their original install disc, they were able to launch the VS IDE with no further errors related to the J# redistributable package 2.0.

As a side note if you're really interested, you could use some of the setup reverse engineering tricks that I describe in this blog post to determine the exact location of this registry key.  In this case, the key/value are listed in the [gencomp68] section of the file named baseline.dat in the setup subdirectory of the VS 2005 DVD or in the self-extracting setup package for the Express Editions.

I have previously posted blog entries (here, here and here) about protected content playback errors that we have seen in some cases after installing Update Rollup 2 for Windows XP Media Center Edition 2005.  I created a new article that contains detailed information about this problem as we work on a fix.  I have posted the following information in this article:

• A combination of all of the previous information in a central location
• Additional information about how to troubleshoot and diagnose the root cause
• How to try to workaround the problems until we can finish testing and publish a fix
• Some of the causes of the issue we have seen so far

I know that it is very painful to not be able to view your content in Media Center due to these issues, and I assure you that we are dedicating significant time and effort in understanding the root causes and fully testing fixes that we hope to have available soon.  I apologize for the inconvenience in the meantime.

I heard from 2 customers yesterday who had both run into an issue on their Media Center 2005 systems.  They had navigated to the More Programs menu in the Media Center start menu and inadvertantly chose to remove the Create CD/DVD item from the menu by clicking the More Info button and choosing the Remove option.  They tried several options but could not figure out how to add it back, and asked how to restore the item to the menu on their system.

I tried this out on my Media Center 2005 system, and restoring this menu item was trickier than I expected.  Here is what I had to do to re-enable the Create CD/DVD option on the More Programs menu:

1. Close Media Center
2. Click on the Start menu, choose Run and type cmd
3. Run reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Categories\Listmaker\Disc Burning\{1beb699f-dc1e-41a7-a31a-d4b339d21f42}" /v Enabled /t REG_SZ /d True /f
4. Re-open Media Center and navigate to More Programs to verify that the Create CD/DVD option appears in the list again

There is a button under Settings | General | More Programs Options named Edit More Programs that is designed to allow you to show or hide items in the More Programs list, but unfortunately, I found that this menu item does not work correctly in all cases.  In this particular instance, the Create CD/DVD option was installed as an extensibility application for all users (meaning the settings are located under HKEY_LOCAL_MACHINE).  However, when you choose to remove the item in the More Programs menu, Media Center sets an Enabled registry value to False under HKEY_CURRENT_USER.

It appears that the HKEY_CURRENT_USER setting will override the HKEY_LOCAL_MACHINE setting, which causes the menu item to be hidden.  It also appears that the Edit More Programs button in the Settings section of Media Center tries to change the registry value under the hive where the application was originally registered, which in the case of Create CD/DVD is HKEY_LOCAL_MACHINE.  I will have to try some experiments with this functionality in the current builds of Media Center that we are working on and report a bug to get this fixed for the future if it is still happening there.

I recently tried to burn a video DVD on my Media Center 2005 system.  I tried to fit 2 hours of recorded TV content on the DVD, and Media Center told me it would need to compress the content in order to fit it on the DVD.  I pressed OK and left my Media Center going overnight to burn the DVD for me.  Then, when I came back in the morning I found an error message stating that my system was out of disk space.  I have my system configured with a 10 gigabyte C drive where I installed the Media Center OS and and then a 200+ gigabyte D drive where I store my music, photos and recorded TV.

After some further investigation, I found that the Sonic DVD burning software that is included with Media Center uses the default temporary folder (%temp%) when it transcodes recorded TV to compress it for burning to a video DVD.  In my case, I only have about 2-3 gigabytes free on my C drive, but I have 150+ gigabytes free on my D drive.  I found that I was able to change the default temporary folder location that Windows uses in order to allow my Media Center to use the D drive for temporary storage and correctly burn my video DVD.

Here are the steps I used to change the default temporary folder location and fix the Media Center video DVD burning issue I was running into:

1. Click on the Start menu, choose Run and type sysdm.cpl
2. Click on the Advanced tab and click the Environment Variables button at the bottom
3. Double-click on the User variable named TEMP and change it to a path on your D drive
4. Double-click on the User variable named TMP and change it to a path on your D drive
5. Double-click on the System variable named TEMP and change it to a path on your D drive
6. Double-click on the System variable named TMP and change it to a path on your D drive
7. Click OK to officially change these environment variables
8. Restart your computer so that Media Center will pick up the changes to these folder locations
9. Try to burn your television show to a video DVD again

I posted some instructions earlier this weekend about how to perform unattended installations of the .NET Framework 2.0 redistributable and SDK.  I got a couple of comments with some really good follow-up questions, and I want to address them as a separate post because that will make the answers easier to find than if they were only posted in the comments on the previous post.

Question 1

What is the most common way to have an application install .NET Framework on to a computer along with an application?  Do they typically just include dotnetfx.exe and call that using silent/unattended command-line switches?  Or are there merge modules available that an MSI can include to automatically install the .NET Framework?

Answer 1

There are not merge modules available for any versions of the .NET Framework.  We worked on one for early versions of the .NET Framework 1.0 but it was cut because of some major serviceability issues.  Once a merge module is consumed into another MSI, the bits in the merge module generally have to be serviced using the product code for the MSI that consumes it.  That makes it very difficult for a redistributable package like the .NET Framework because there is not a way of knowing exactly which applications will consume your merge module.  This issue affected SQL MSDE when the slammer virus hit because a lot of applications consumed the MSDE merge module and there were active, vulnerable versions of MSDE that could not be patchable by our standard patches.

If you plan to install the .NET Framework as part of your setup, you can use one of the following options:

1. Carry dotnetfx.exe with your setup package, and have a bootstrapper that will check for the existence of the .NET Framework on the system and spawn dotnetfx.exe for the user if it is not already installed
2. Have your setup check for the existence of the .NET Framework on the system and block and point the user to a web site to download and install the .NET Framework themselves if it is not installed.

You will have to weigh the tradeoffs of these options - carrying the .NET Framework results in a larger package size, but also provides a more seamless user experience.  Blocking results in a smaller package size because you don't have to carry dotnetfx.exe, but likely will result in user frustration because they will have to find and install the .NET Framework themeselves before being able to install your product.

Question 2

How will the .NET Framework installer respond if the .NET Framework is already installed on a system?  Is it acceptable for a setup package to skip detecting whether the .NET Framework is already installed and always launch dotnetfx.exe, or should we write code that detects if it is installed first, and then invoke dotnetfx.exe only if necessary?

Answer 2

The .NET Framework setup will run in repair mode if it is already installed.  Despite this, I recommend that your setup package detect whether or not the .NET Framework is already installed and only run the dotnetfx.exe setup package if it is not already installed for the following reasons:

1. This results in a faster installation for users who already have the .NET Framework installed.
2. I have seen issues where re-running dotnetfx.exe on a system that already has the .NET Framework plus a service pack installed will result in error messages.  You can see this by downloading and running the .NET Framework 1.1 setup package on a system that already has .NET 1.1 and 1.1 SP1 installed.

Question 3

What is the officially-supported method for detecting whether .NET 2.0 Framework is already installed and the correct version?

Answer 3

The officially supported method of detecting the presence of the .NET Framework 2.0 is to check the following registry key/value:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Net Framework Setup\NDP\v2.0.50727]
Install = 1 (REG_DWORD)

You can take a look at some sample code I wrote to check for the presence of each shipped version of the .NET Framework and the installed service packs (if any).

Question 4

Regarding the three different versions of the .NET Framework 2.0 - is it correct that the Intel 64 version is for Itanium and that the AMD64 version also covers Intel Xeon with 64-bit extensions?

Answer 4

The Intel 64 version of the .NET Framework 2.0 is intended for Itanium systems.  I have not personally used a computer with Intel Xeon hardware with 64-bit extensions.  However, based on the information I found in some quick web searches, it appears to be considered an x64 system.  That means that you can install the AMD64 version of the .NET Framework 2.0 if you are running an x64 OS, and you can install the the 32-bit version of the .NET Framework 2.0 if you are running a 32-bit OS.

I received a question from a customer about how to perform a sequential unattended install of the .NET Framework 2.0 redistributable package and SDK.  I have written a couple of different posts in the past about the various command line parameters available for the .NET Framework 2.0 setup and some of the options for silent installs (for example, the posts here, here and here).  However, I realized that I've been sort of scattering this information across multiple blog posts and not providing simple, easy to understand examples of real world scenarios like this unattended install, so I'm going to try to start addressing that with this post.

Here are example command lines you can use to perform unattended installations for the .NET Framework 2.0 redistributable and SDK.

Silent installation

These command lines will run the .NET Framework 2.0 redist and SDK setups in fully silent mode.  The setup package will extract to a temporary location and installation will begin with no user interaction and no visible UI.  The user will see no visible indication that setup is running.

1. dotnetfx.exe /q:a /c:"install.exe /q"
2. setup.exe /q:a /c:"install.exe /q"

Standard unattended installation

These command lines will run the .NET Framework 2.0 redist and SDK setups in standard unattended mode.  The setup package will extract to a temporary location and installation will begin with no user interaction.  A progress dialog will appear on the screen during installation, and it will disappear when setup is complete.  Errors encountered during installation might pop up message boxes during installation if they occur.

1. dotnetfx.exe /q:a /c:"install.exe /qb"
2. setup.exe /q:a /c:"install.exe /qb"

Unattended installation with no cancel button available in the UI

These command lines will run the .NET Framework 2.0 redist and SDK setups in unattended mode with no cancel button.  The behavior of setup is the same as with the command lines above except the cancel button will be hidden on the progress page during installation.  This allows the user to know that a setup is in progress but prevent them from cancelling it (unless they kill the process in Task Manager).

1. dotnetfx.exe /q:a /c:"install.exe /qb!"
2. setup.exe /q:a /c:"install.exe /qb!"

Important notes to consider

• The .NET Framework 2.0 has 3 versions - a 32-bit version, an Intel 64-bit version and an AMD64 version.  You will need to select the correct versions of the setup packages for the .NET Framework 2.0 redist and SDK to install on your system using these command lines
• The .NET Framework 2.0 SDK requires that the redistributable is already installed.  Your unattended installation script will need to start the redistributable setup, wait for it to complete, and check the return code to determine whether or not it installed successfully before trying to run the SDK setup.  A return code of 0 means success with no reboot required, 3010 means success with a reboot required and any other return code means failure

One of the folks I talked to at CES 2006 last week asked me about how to use Media Center extensibility APIs to access the closed captioning (teletext) stream from a TV broadcast.  At a high leve, he wanted to be able to monitor some television channels, store the teletext data to a database and then do searches on the data later on.  I asked around a little bit when I got back to the office this week and found that we don't have any officially supported means of accessing teletext data with our extensibility APIs.

However, I also found that Stephen Toub has written an interesting white paper, blog post and some excellent sample code that parses and exposes all of the closed captioning data from an NTSC, non-high definition DVR-MS file.  Here are links to the things he has written about the DVR-MS file format and how to parse it:

• Fun with DVR-MS white paper - discusses the DVR-MS file format, introduces DirectShow, and shows how to use DirectShow to work with DVR-MS files; you should read this first to get an overview of DVR-MS files and the data they contain in addition to the video stream
• DVR-MS closed captioning parser - blog post (which is as in-depth and well written as a white paper) that introduces a managed library Stephen wrote to parse closed captioning data
• Sample code for closed captioning parser

Using and extending the techniques that Stephen describes in these articles should allow you to parse a closed captioning (teletext) stream from a recorded TV show, and once you have parsed the data you can store it in a database or manipulate it in other ways as needed for your scenarios.  For inspiration, check out the list of cool ideas at the bottom of Stephen's blog post...

<update date="2/8/2006"> Fixed the link to the sample code for the closed captioning parser </update>

I found a link with a nice write-up of the features of the Next Generation Home that was located across the street from the Central Hall at CES 2006 this year.  The home was located near the exhibitor's registration tent and the Yahoo tent where Tom Cruise and Katie Holmes apparently made an appearance on Friday the 6th.  I spent some of my time at CES on Thursday and Friday doing demonstrations in a couple of rooms of the house, and it was cool to see some of the home automation features in action that I've been hearing about from some of the folks on the Media Center team.

I worked mostly at the kitchen Media Center station, which was unfortunately not all that interesting for most of the attendees because a lot of the features of Media Center were also demonstrated in the room that folks were in immediately before coming into the kitchen.  I found a cooking show that had an on-screen recipe so I could show off pausing and rewinding live TV, which was one of the features they didn't show in the room before the kitchen.  There were a couple of ovens in the kitchen - one standard oven next to my station (that was put there just to take up space in the room) and one smart oven across the room that could be controlled via a web page.  It was funny to see folks take pictures of the oven next to my station every once in a while.

I also worked for a bit in the game room and got to show off the Xbox 360 running as a Media Center Extender.  I had heard how nice they looked from friends of mine who have them at home, but this was my first chance to see an Xbox 360 Extender in action.  I have the kit that lets you use the original Xbox as an Extender, but it is night-and-day different to see the Xbox 360.  Aside from the remote control that has the big X logo on it to bring up the Xbox dashboard and the lack of a My DVDs menu in the Media Center start menu (since you cannot view DVDs remotely through an extender), it would be nearly impossible to tell that the Media Center experiences that you're viewing are actually being remotely displayed by an Extender.

One random funny story I heard about the home from some of the other staff was related to the sign taped to the toilet in the bathroom that said the toilet was non-functional.  Apparently that was a new addition to the home based on some "issues" they ran into at last year's CES with folks who couldn't find the restrooms in the Convention Center....

I have heard from a few folks over the past weeks who started running into guide download errors on systems that they had made no recent changes to.  In one case, the customer rebuilt the machine from scratch only to hit the same error on a brand new system.  I found out that there have been some server-side certificate issues in the past month or so that can result in guide download failures with error code 14 or 33 being reported in the application event log.  These issues should be corrected now, so if you have been unable to download guide data with error code 14 or 33, please try to launch Media Center and download guide data again and hopefully this issue will be cleared up.

If you are still running into issues, please refer to the Guide Download Errors section of my Update Rollup 2 Troubleshooting Guide for some additional suggested workarounds.

A customer asked a question last week about how to detect whether or not Visual Studio 2005 is installed on a computer, and if so, which edition is installed and what location it is installed to.  There are a ton of registry keys written by VS 2005 setup, so deciding which keys are safe to use to detect the presence and location of this family of products can be tricky, especially when you factor in all of the various editions and non-English languages.  In addition, we unfortunately have not yet designed a registry hive specifically to allow applications to detect the presence of Visual Studio like we have in the .NET Framework and other redistributable packages that are installed as a part of Visual Studio setup.

Here is a list of the registry keys/values that can be used to detect each of the editions of Visual Studio 2005.  In each case below, ProductDir is a REG_SZ value that contains the install root (which by default will be c:\Program Files\Microsoft Visual Studio 8).

• Visual Basic 2005 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VBExpress\8.0\Setup\VS\ProductDir
• Visual C++ 2005 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VCExpress\8.0\Setup\VS\ProductDir
• Visual C# 2005 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VCSExpress\8.0\Setup\VS\ProductDir
• Visual J# 2005 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VJSExpress\8.0\Setup\VS\ProductDir
• Visual WebDev 2005 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VWDExpress\8.0\Setup\VS\ProductDir
• Visual Studio 2005 Standard - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\Std\ProductDir
• Visual Studio 2005 Professional - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\Pro\ProductDir
• Visual Studio 2005 Team Edition for Software Architects - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTA\ProductDir
• Visual Studio 2005 Team Edition for Software Testers - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTT\ProductDir
• Visual Studio 2005 Team Edition for Software Developers - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTD\ProductDir
• Visual Studio 2005 Team Suite - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTS\ProductDir
• Visual Studio 2005 Premier Partner Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\IDE\ProductDir
• Visual SourceSafe 2005 - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSS\ProductDir
• Visual Studio 2005 Tools for the Microsoft Office System - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTO\ProductDir

I heard from a customer who was running into a package load failure error with the Visual WebDev 2005 Express Edition on a system that had never had any beta versions installed.  The customer was able to narrow down the cause of this error and I wanted to pass on the findings in case anyone else runs into this issue.

There is an add-in available on the Visual WebDev Express downloads page that provides a set of ReportViewer controls for the Visual WebDev Express Edition.  This add-in has a setup bug that causes a couple of files to be installed to an incorrect location if you have installed the Visual WebDev Express Edition to a non-default location instead of to the default %ProgramFiles%\Microsoft Visual Studio 8 folder.  Those files end up causing a package load failure error in the Visual WebDev IDE.

I have looked at the MSI for the Reporting Add-in and confirmed that it will not behave as desired for a non-default install of Visual WebDev.  I found a bug report on the MSDN product feedback site that is tracking this issue, and then I looked the bug up in our internal bug database.  The setup package for this Reporting Add-in has been updated to correct the non-default install path issue, and it will be released to the web in the near future.  In the meantime, you can use the following workaround if you are getting package load failures due to this issue:

1. Uninstall the Reporting Add-in
2. Uninstall Visual WebDev Express Edition
3. Install Visual WebDev Express Edition to the default location
4. Install the Reporting Add-in again

Fortunately, I recently found a link to a newer version of the Reporting Add-in that contains a setup fix so that it will not cause package load failures when installed to a non-default path.

<update date="1/11/2006"> I found the team that built the Reporting Add-in, so I added information about the availability of a fix for this issue </update>

<update date="10/1/2006"> Adding a link to the Reporting Add-in installer that contains a fix for this issue </update>

I have heard from a couple of customers who have seen package load failure errors in Visual Studio 2005 and for whom the workarounds I normally recommend did not work.  We finally managed to figure out that the package load failures were caused by having Dotfuscator Professional Edition 3.0 installed and opening a solution that contained a Dotfuscator 3.0 project and other Visual Studio packages.  This bug report describes some of the symptoms.

Preemptive has released an updated version of Dotfuscator 3.0 on 1/9/2006 that should resolve this issue.  You can view the release notes for this updated version on this site.  If you are running into package load failures in Visual Studio 2005 and you have Dotfuscator 3.0 installed, I encourage you to uninstall your current version of Dotfuscator and install the updated version provided by Preemptive to try to resolve this issue.

As I am sure those of you on the Windows Vista Community Technology Preview (CTP) and beta program have already noticed, the Media Center bits in the most recent Vista CTP (December 2005) contain a timebomb.  That means that if you try to launch Media Center and your system time is set to January 1, 2006 or later, you will get a dialog box stating that the trial period has expired and you cannot launch Media Center.

Fortunately, we have been able to release a patch to the CTP download site that you can install and fix this issue.  Unfortunately, we have not been able to post this patch to any kind of more visible location such as Windows Update because they are not ready for wide usage of Windows Update for Vista-specific patches yet.

If you do not have the patch, you can also workaround this issue by disabling the Windows Time service, setting your system clock back prior to January 1, 2006, and then launching Media Center.  If you use this workaround, any features in Media Center that rely on having the system clock set correctly will not work.  Most notably, you will not be able to download television guide data.  Because of this, I would suggest downloading and installing the patch from the CTP download site if possible in your scenario.

Dave Fleischman posted a very good in-depth description of why this problem happened and how it was missed on the Media Center feature teams prior to shipping the December 2005 CTP.  One thing I would like to add to his explanation is a bit more detail about how the source code integration from Media Center 2005 Update Rollup 2 into Media Center for Windows Vista caused the timebomb to be carried forward.  He is correct in explaining that there was an integration of the final Update Rollup 2 code base into the Vista source tree, and that the timebomb was disabled in Update Rollup 2 prior to this final integration.  The code for the underlying implementation for the timebomb was wrapped in an IFDEF block that was enabled or disabled at compilation time by defining a variable in the build scripts.  When the code integration into the Vista source tree happened after Update Rollup 2 was complete, the code that contained the timebomb was carried forward, but since Vista is built with an entirely new set of build scripts, the build script that defined the variable that would disable the timebomb at compile time was not carried forward.  The net result was that the Update Rollup 2 timebomb was enabled in the Vista version of Media Center.

Needless to say, we have augmented our processes going forward so that this will not happen again.  I apologize for the inconvenience any of you have encountered due to this issue.

I've found a couple of links that contain lists of available add-ins for Media Center 2005 that I wanted to post here for folks to take a look at.  I have been trying to get more familiar with the types of applications that folks are writing to extend Media Center functionality, but I haven't gotten to evaluate/experiment as much as I'd like to yet.  I decided to get started by collecting links to different add-in repository sites and then expand from there.  If you get a chance, please check out the permalink to my add-in repository article.

If you come across any links that you think I should add, please post a comment or contact me directly and I will evaluate them and add them if they look interesting.

We have run into a few cases where customers have been trying to install the .NET Framework 2.0 and have seen setup hang or fail while trying to register System.EnterpriseServices.dll.  I have heard from a couple of customers who ran into this particular issue and found a workaround that allowed them to successfully install, so I wanted to post the workaround here to make it easier for others to find.  The customers I have heard from found this workaround useful for the .NET Framework 2.0, but the same workaround may also be useful for installation failures in the .NET Framework 1.0 and 1.1.

The command that registers System.EnterpriseServices.dll is implemented as a custom action that runs the command regsvcs.exe /bootstrapi.  This command can fail or hang indefinitely if the Microsoft Distributed Transaction Coordinator (MSDTC) service is in a broken state on the system.  If you see .NET Framework setup (1.0, 1.1 or 2.0) fail or hang during registration of System.EnterpriseServices.dll, the following steps may be useful to resolve this issue:

1. Click on the Start menu, choose Run and type services.msc
2. Locate the Distributed Transaction Coordinator service, right-click on it and choose Properties
3. In the Startup type drop-down, select Disabled
4. If the service status is currently listed as running, click the button to stop the service
5. Close the Services control panel and try to install the .NET Framework again

Note that I have written about other possible causes of this type of installation failure in the following blog posts, and if the above workaround does not succeed, these additional articles may be helpful:

• Error installing .NET Framework 1.0 and 1.1 on Windows XP SP2 caused by Data Execution Prevention (DEP)
• Error installing .NET Framework 1.0 and 1.1 on Windows XP SP2 caused by language settings
• Possible causes of .NET Framework 1.0 and 1.1 setup failures on Windows NT 4.0

CES 2006 is the coming out party of sorts for a lot of interesting details about what Media Center will look like in Windows Vista.  One of the areas I'm most excited about is the improved developer platform lwe are going to have for Media Center in Windows Vista.  In addition to the previous development models that have been supported (add-ins and hosted HTML), we are adding support for Avalon web applications (known as WinFX XAML Browser Applications or XBAP).  Also, we are introducing the Media Center Presentation Layer and a markup language to support it.  Add-ins written using Media Center Markup Language (MCML) will be using the same underlying technologies that we use on the Media Center team to create the UI for Media Center itself.  For those of  you familiar with add-in development for Media Center 2005, you will recognize that MCML represents a significant step forward in terms of the types of applications that can be created with Media Center APIs and the quality and seamless integration possible with these applications.

I encourage you to check out this article on the Media Center Sandbox for additional introductory information about the next generation of Media Center development.  Also, stay tuned for more details in the near future....