Aaron Stebner's WebLog

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

January, 2007

  • Aaron Stebner's WebLog

    One specific cause of ehExtHost crashes that can occur when launching Media Center

    • 9 Comments

    A while back, I wrote a blog post describing a scenario where launching Windows Media Center causes a crash dialog to appear with the title ehExtHost.  At the time I wrote that post, I had not found any specific add-ins that consistently caused problems.  However, since then, I have heard from many customers seeing this type of crash, and all of the crashes so far have been caused by a specific add-in.

    In the scenarios I have seen, the customers had computers that came pre-installed with a Symantec Norton anti-virus software package.  They had uninstalled this software package, and the crashes started happening afterwards.  This anti-virus software includes a Media Center add-in so you can access the settings from within Media Center, and the uninstall process appears to remove the files but leave behind the Media Center add-in registration information in the registry.  Because the registration is still on the system, Media Center will attempt to launch this Symantec add-in each time it is opened, but since the files have been removed, the add-in will crash.

    If you have a Media Center system, and are seeing ehExtHost crashes when you open Media Center, and if you have previously uninstalled a Norton anti-virus package that came pre-installed on your system, you can use steps like the following to resolve this crash:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run this command:  reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Applications\{4874559d-e801-4f21-a580-6f5f0b87017c}" /f
    3. Run this command:  reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Categories\Background\{51537886-fe58-4b67-9fbc-567013c765f6}" /f
    4. Run this command:  reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points\{51537886-fe58-4b67-9fbc-567013c765f6}" /f

    The above steps remove the registration information for this particular add-in from the 3 locations that it has appeared in the registry on all of the systems that were encoutering ehExtHost crashes that I have diagnosed so far.

    If these steps do not help on your system, please refer to my previous blog post for a list of steps you can use to gather additional information that can be used to narrow down the root cause of this type of crash.

  • Aaron Stebner's WebLog

    New MCML development resources - shared source controls project, pivots tutorial and a new blog

    • 1 Comments

    Some interesting new Media Center Markup Language (MCML) development resources have been posted over the past few days that I wanted to draw more attention to.

    Shared source MCML controls project

    Recently, I heard from Steven Harding (the developer behind the Yougle add-in for Windows XP Media Center Edition that allows you to browse and view YouTube and Google Video content).  He let me know that he has been working with the Windows Media Center SDK for Windows Vista in order to learn more about Media Center Markup Language (MCML) and create some new applications for Windows Vista Media Center. 

    One of the things he expressed some specific frustration about is the lack of a common library of MCML-based controls to allow developers to easily build UI for their applications.  To that end, he has created a new project on Sourceforge called MCMLookalike.  This project is intended to create a reusable set of controls that have a similar look-and-feel to Windows Vista Media Center.

    New Media Center development blog

    In addition, Steven has created a blog to describe his experiences as he learns and uses MCML.  You can find his Media Center Development Blog at http://mediacenterdev.blogspot.com/.  I'll be adding this blog to my blog roll and keeping an eye on the posts as Steven gets more in-depth with his MCML development.

    In-depth tutorial about creating Media Center-like pivots in MCML

    Niall has posted a really in-depth tutorial, complete with sample code, that describes the process he used to create MCML controls for pivot items and buttons that look and behave like the pivots in the built-in Windows Vista Media Center UI.  You can view the blog post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!256.entry.  Also, you can view the sample on your system if you have Windows Vista Ultimate or Home Premium and the Media Center SDK installed by launching McmlPad and browsing to the URI http://mobilewares.net/mcml/PivotSample.xml.

    Based on the tag line on Steven's blog ("Follow the long and painful experience of one man trying to get the most out of the Media Center Markup Language."), I'd say that the Media Center SDK still has a long ways to go to allow developers to be as efficient as possible in developing applications for Windows Media Center.  Hopefully, we'll get there in the future, but in the meantime, having community resources like the ones linked above plus the Media Center Sandbox forum are really great supplements to the information in the SDK and I hope to see these trends of sharing knowledge and helping each other learn and use these new technologies continue!

  • Aaron Stebner's WebLog

    Resolving .NET Framework 2.0 setup error related to the ALLUSERS property

    • 2 Comments

    I have heard from a couple of customers who ran into an interesting error while attempting to install the .NET Framework 2.0 on their systems.  The error message in the verbose MSI log file looks like the following:

    MSI (s) (18!84) [14:41:46:857]: Product: Microsoft .NET Framework 2.0 -- 1: ALLUSERS property is not 1 - this MSM cannot be used for a per-user or fallback-to-per-user install 2:

    How to workaround this error

    After some digging through verbose MSI log files, we were able to figure out that this was caused by a previous Group Policy advertised installation of the .NET Framework 2.0 that was done on a per-user basis.

    The customers I worked with were able to resolve this issue by going to Add/Remove Programs, uninstalling the Microsoft .NET Framework 2.0 item listed there, and then downloading and installing the full packaged version of the .NET Framework 2.0 on their own from this location (rather than relying on Group Policy to automatically install it for them).

    More details about the root cause

    The .NET Framework 2.0 inherits some behavior from the VC runtime redistributable MSMs that it consumes and does not support per-user installation.  The underlying issue in the VC runtime files was reported via this bug - https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=98736&siteid=210, and it has been fixed in the Visual Studio 2005 SP1 version of these MSMs.  Unfortunately, because these MSMs are a part of .NET Framework 2.0 setup, there is not a way to avoid this error without repackaging the setup with newer versions of the MSMs.

    How to find the root cause from a verbose MSI log file

    For those of you interested in how to diagnose this type of error on your own, here is how Carolyn (the Windows Installer development lead) taught me to determine the exact root cause of this issue.  We started by looking at various sections of the verbose MSI log file.  The following are the relevant snippets:

    MSI (c) (2C:40) [14:41:13:580]: Package name retrieved from configuration data: 'netfx.msi'
    MSI (c) (2C:40) [14:41:13:580]: Determined that existing product (either this product or the product being upgraded with a patch) is installed per-user.
    MSI (c) (2C:40) [14:41:13:580]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2729
    MSI (c) (2C:40) [14:41:13:661]: Note: 1: 2262 2: AdminProperties 3: -2147287038
    MSI (c) (2C:40) [14:41:13:661]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.

    The information marked in bold above indicates that the .NET Framework 2.0 was already installed on the system, but it was installed per-user instead of per-machine.  In addition, some later information in the verbose MSI log file shows that it is assigned (most likely by Group Policy):

    MSI (c) (2C:40) [14:41:13:661]: Product {7131646D-CD3C-40F4-97B9-CD9E4E6262EF} is admin assigned: LocalSystem owns the publish key.
    MSI (c) (2C:40) [14:41:13:661]: Product {7131646D-CD3C-40F4-97B9-CD9E4E6262EF} is managed.
    MSI (c) (2C:40) [14:41:13:661]: Running product '{7131646D-CD3C-40F4-97B9-CD9E4E6262EF}' with elevated privileges: Product is assigned.

    ...
    MSI (c) (2C:40) [14:41:13:671]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'.

    Finally, another way to narrow down this behavior is to check the value of the ProductState property in the verbose MSI log file.  In the cases I have seen so far where this ALLUSERS error appears, the ProductState property is set to 1 like in the following log snippet:

    MSI (s) (18:50) [14:41:34:199]: PROPERTY CHANGE: Adding ProductState property. Its value is '1'.

    The value of 1 means the product is advertised but not installed. That is the standard method for Group Policy installation where advertisement occurs first (to grant elevated privileges) and then the install occurs afterwards.

  • Aaron Stebner's WebLog

    mcesoft Vista HTML SDK and Media Center support for Hosted HTML applications in Windows Vista

    • 0 Comments

    I just noticed this post on Niall's Big Screen Blog with information about some new applications created by mcesoft for Windows Media Center for Windows Vista.  One of these items in particular caught my attention - the mcesoft Vista HTML SDK.  This SDK is designed to supplement the information in the Windows Media Center SDK for Windows Vista and help developers get started writing Hosted HTML applications that have a similar visual style as Windows Media Center in Windows Vista.

    The download page for this HTML SDK also notes that the Windows Media Center SDK for Windows Vista includes some Hosted HTML application sample pages, but that they are essentially the same as the ones included in previous versions of the Media Center SDK.  I wanted to comment on this statement so that people understand why we decided to re-ship previous documentation for Hosted HTML application support in Media Center.

    During the Windows Vista project, we introduced 2 significant new development paradigms for Windows Media Center:

    • The Windows Media Center Presentation Layer (WMCPL) which uses Media Center Markup Language (MCML)
    • Hosted .NET Framework 3.0 XBAPs

    We decided to continue to support Hosted HTML applications from a backwards compatiblity perspective, but not to continue to invest in enhanced HTML documentation or samples in the SDK.  Instead we invested in creating documentation, samples and community resources (such as the Media Center Sandbox discussion forum) to try to help get people interested, motivated and trained to be able to create rich applications using the new technologies in Windows Vista.  Ideally, new developers creating applications for Windows Vista Media Center will use MCML or XBAPs and forego HTML application development entirely in order to provide the same level of UI richness offered by Media Center itself.

    To echo one of the comments that Niall mentioned in his blog post - I would really like to see some kind of community effort around creating a set of common UI controls for MCML-based applications for Windows Media Center (similar to the HTML controls in the mcesoft HTML SDK).  Re-use of common elements and controls like this makes it possible to create applications much more quickly.

    The Media Center team attempted to take a first step in this direction with the Z sample application.  The buttons, galleries and even the on-screen keyboard are designed to be re-usable and skinnable for various types of applications.  If you haven't yet, I encourage you to install the Windows Media Center SDK for Windows Vista and check out the source code and markup for Z (located in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Applications\Z if you install the SDK to the default location.

  • Aaron Stebner's WebLog

    Final version of the Windows Vista Upgrade Advisor available for download

    • 0 Comments

    With the Windows Vista public launch right around the corner (including the ability to purchase and download Windows Vista via Windows Marketplace on January 30, 2007), I wanted to make people aware of a tool that can be used to evaluate how well you can expect your current PC to work if you decide to upgrade it to Windows Vista.

    This tool is known as the Windows Vista Upgrade Advisor, and you can find more information about it from these links:

    The Upgrade Advisor requires the .NET Framework 2.0 and MSXML 6.0, and it consists of a small MSI-based setup that you can install and run on your PC.  After installing it, you can run the Upgrade Advisor and have it scan hardware and software on your system and create a detailed report that includes recommendations about what edition of Windows Vista will best meet your needs, what known compatibility issues exist for your hardware and software, and what can be used to resolve any known issues.

  • Aaron Stebner's WebLog

    Mailbag: Can I set registry values directly instead of using RegisterMceApp.exe?

    • 0 Comments

    Question:

    I have written a Windows Media Center application, and now I want to create an MSI-based installer for it.  I have looked at the WiX-based setup for the Q sample application in this blog post and in the Windows Media Center SDK for Windows Vista.  If possible, I would like to avoid creating a custom action in the MSI to run RegisterMceApp.exe to register the application with Media Center.  Is it possible to register my application with Media Center without creating a custom action?

    Answer:

    Yes, it is technically possible to register a Windows Media Center application without running RegisterMceApp.exe or the RegisterApplication API.  RegisterMceApp.exe performs the following activities to register an application with Media Center:

    1.  Creates registry values under 3 specific sub-keys:

    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Applications
    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Categories
    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points

    Note - these values will be created under HKEY_LOCAL_MACHINE if the application is registered for all users by passing the /allusers switch to RegisterMceApp.exe.

    2.  Calls an API to refresh the Windows Media Center UI if it is running at the time that the application is registered

    It is possible to create an MSI that uses entries in the Registry table to create the same values that would be created by RegisterMceApp.exe in item 1 above.  You can use the following steps to accomplish this:

    1. Create an XML registration file for your application (see the link at the bottom of this post for more details about how to do this)
    2. Manually register the application by running RegisterMceApp.exe <path to XML file created in step 1 above> or RegisterMceApp.exe /allusers <path to XML file>
    3. Locate the registry values that are created by running RegisterMceApp.exe by looking in the sub-keys listed above
    4. Manually unregister the application by running RegisterMceApp.exe /u <path to XML file>
    5. Add the registry values that you located in step 3 above to the Registry table of your MSI

    Please note that if you create these registry values directly in the Registry table of your MSI to register your Media Center application, you will lose the ability to automatically refresh the Media Center UI if it is running at the time that the MSI is installed.  However, you can avoid creating a custom action in your MSI to register your application with Media Center if you are willing to make this trade-off.

    For reference, the following topics in the Windows Media Center SDK contain useful information about installing and registering Media Center applications:

    I also want to emphasize one other point that is not covered above - in order for your Media Center application to appear correctly on Media Center extenders, you should register it for all users by creating registry values for it under HKEY_LOCAL_MACHINE or by running RegisterMceApp.exe with the /allusers switch.

  • Aaron Stebner's WebLog

    Functional overview and screenshots for Media Center sports feature

    • 0 Comments

    I found a link today to a post reviewing the new Sports feature in Windows Media Center for Windows Vista that was unveiled at CES 2007 a couple of weeks ago.

    This post includes a breakdown of the features included in the Sports strip on the Windows Media Center start menu, and includes screenshots of many of them to demonstrate how they appear within Media Center.

    I encourage you to check out the post at http://www.missingremote.com/index.php?option=com_content&task=view&id=1000&Itemid=152 and if possible, check out the Sports feature within Windows Media Center for Windows Vista as well.

     

  • Aaron Stebner's WebLog

    .NET Framework 3.0 deployment readme

    • 0 Comments

    I recently found an online version of the deployment readme for the .NET Framework 3.0 and I wanted to post a link here to try to make it easier to find in web searches.

    You can find the Microsoft .NET Framework 3.0 Deployment Readme at http://msdn2.microsoft.com/en-us/library/aa480217.aspx.  It includes the following topics:

    • Steps to run administrator mode setup
    • Prerequisites for deploying .NET Framework 3.0
    • Steps to deploy .NET Framework 3.0 child components using Active Directory
    • How to redeploy and remove packages using Active Directory
    • Specifying Watson error reporting settings for .NET Framework 3.0 setup
    • .NET Framework 3.0 log file locations (I also posted more details about .NET Framework 3.0 log files in this blog post)

    One of the most useful sections of this document (in my opinion) is the table in section 3.2 that lists the command line parameters that can be used to perform silent installations of each of the child packages that make up the .NET Framework 3.0.

  • Aaron Stebner's WebLog

    Updated VC 8.0 runtime redistributable packages are included in Visual Studio 2005 SP1

    • 10 Comments

    I posted an item last week that described how to detect the presence of the Visual C++ 8.0 runtime files redistributable packages.  Over the weekend, a customer pointed out to me that Visual Studio 2005 SP1 includes modified versions of the VC redist packages.

    The SP1 versions of the VC redist packages include the following changes:

    • The Windows Installer 3.1 requirement has been eliminated by rewriting a custom action included in the original MSIs so it does not use APIs that only exist in Windows Installer 3.x
    • The product codes were changed for each of the MSIs
    • The MSIs now implement the Windows Installer major upgrade feature to automatically upgrade systems that have the original VS 2005 version to the SP1 version

    Because the product codes were changed, the detection mechanism that I described in my previous blog postwill not work for the SP1 versions of the VC redist MSIs.  The following steps can be used to check for the existence of the modified VC redist packages that are included in VS 2005 SP1:

    1. Call the MsiQueryProductStateAPI
    2. Pass in the product code for the package that you want to detect based on the list below
    3. Check the return value of this API.  If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed

    Visual C++ 2005 runtime files

    Visual C++ 2005 SP1 runtime files

    Visual C++ 2005 SP1 ATL Security Update runtime files

    Visual C++ 2005 SP1 MFC Security Update runtime files

    One additional note - the data files included with the Visual Studio deployment bootstrapper tool were not updated with the new SP1 detection mechanism.  This means that if you build a setup project in VS 2005 SP1 and include the VC redist package as a prerequisite, your setup will end up downloading and installing the VC redist package on systems that already have the original VS 2005 version of this redist package installed.  Because of the major upgrade functionality, this will not harm users' systems at all, but it will result in a slight time delay due to an unnecessary download and install.

    <update date="11/19/2009"> Added information about VC++ 2005 and VC++ 2005 SP1 ATL Security Update packages. </update>

    <update date="1/17/2012"> Added information about VC++ 2005 SP1 MFC Security Update packages. </update>

     

  • Aaron Stebner's WebLog

    Converting the Z sample application to use WiX v3.0 and Votive

    • 3 Comments

    A little while back, I posted a set of instructions for converting the setup project for the Q  podcast sample application that is a part of the Windows Media Center SDK for Windows Vista to use WiX v3.0 and the Votive add-in for Visual Studio 2005.

    I decided to use those instructions to create updated setup files for the Z sample application as well.  The following sets of steps will allow you to use WiX v3.0 and Votive to build an installer for the Z sample application that is included in the Windows Media Center SDK for Windows Vista.

    Building an MSI for Z by calling WiX tools directly

    The following steps can be used to build an MSI for the Z sample application from Visual C# 2005 Express Edition or Visual Studio 2005 by adding a post-build step that executes a batch file that will call the WiX compiler (candle.exe) and linker (light.exe):

    1. Install Windows Vista Home Premium or Ultimate Edition
    2. Install Visual C# 2005 Express Edition or Visual Studio 2005 standard or higher
    3. Install the Windows Media Center SDK for Windows Vista
    4. Install the latest version of WiX 3.0 from http://sourceforge.net/project/showfiles.php?group_id=105970&package_id=168888. You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI
    5. Download this zip file with updated Z setup files and extract the contents to the Z project directory. The Z project will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z if you installed the Windows Media Center SDK to the default location
    6. Right-click on the shortcut for Visual Studio 2005 or Visual C# 2005 Express Edition, choose Run as administrator and click Continue to launch Visual Studio with elevated privileges
    7. Open Z.sln - it will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z if you installed the Windows Media Center SDK to the default location
    8. Right-click on the Z project in the Solution Explorer and choose Properties
    9. Select the Build Events tab
    10. Add a new entry to the Post-build event command line text box that says "$(ProjectDir)\SetupWiXv3\build_z.bat" $(ConfigurationName)
    11. Click on the File menu and choose Save All
    12. Click on the Build menu and choose Rebuild Solution to build the Z binaries and then run build_z.bat

    The above steps will produce an MSI named Z_Sample_Application.msi in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z\bin\release (or \bin\debug\ for the Debug version of the Z application).

    Building an MSI for Z using Votive

    The following steps can be used to build an MSI for the Z sample application directly from Visual Studio 2005 using the Votive WiX add-in.  Visual Studio 2005 Express Editions do not support installing add-ins, so Votive (like all Visual Studio add-ins) requires Visual Studio 2005 Standard Edition or higher.

    1. Install Windows Vista Home Premium or Ultimate Edition
    2. Install Visual Studio 2005 standard or higher
    3. Install the Windows Media Center SDK for Windows Vista
    4. Install the latest version of WiX 3.0 from http://sourceforge.net/project/showfiles.php?group_id=105970&package_id=168888. You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI
    5. Download this zip file with updated Z setup files and extract the contents to the Z project directory. The Z project will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z if you installed the Windows Media Center SDK to the default location
    6. Right-click on the shortcut for Visual Studio 2005, choose Run as administrator and click Continue to launch Visual Studio with elevated privileges
    7. Open ZWiXv3.sln - it will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z if you installed the Windows Media Center SDK to the default location
    8. In the Visual Studio Build menu, choose Batch Build...
    9. Select the configurations you want to build and click the Rebuild button to build them

    The above steps will produce an MSI named Z_Sample_Application.msi in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z\ZWiXv3\bin\release (or \bin\debug\ for the Debug version of the Z application).

    Hopefully, the sample WiX v3.0 files for both Q and Z will be included in a future version of the Windows Media Center SDK.

  • Aaron Stebner's WebLog

    Updated steps for setting the NoImpersonate flag for a custom action in Visual Studio 2005

    • 8 Comments

    A while back, I posted some instructions that can be used to run a post-build script to modify the custom action attributes of an MSI created by the Visual Studio 2005 setup/deployment project wizard.  This script is particularly useful to set the necessary attributes to make a custom action work correctly with User Account Control (UAC) on Windows Vista (as described in more detail in this blog post).

    Since I posted those instructions, a couple of folks have contacted me to let me know that the jscript file provided in that post works correctly when it is run manually, but the steps to run it from within Visual Studio 2005 as a post-build step were failing.

    I finally found some time to investigate this issue, and I discovered that I made a typo in the exact name of one of the variables being used in the post-build step.  This was a little tricky to narrow down because my typo was to spell the variable in what should be the correct way - $(BuiltOutputPath).  However, the actual variable name expected by MSBuild and Visual Studio 2005 is $(BuiltOuputPath) with the word spelled "ouput" instead of "output."

    At any rate, I have modified the original post I wrote about this topic, and here are updated instructions that can be used to set the NoImpersonate bit in a Visual Studio 2005 setup project as well:

    1. Download the sample script and extract the contents to the directory that contains the Visual Studio project you are working on
    2. Open the project in Visual Studio 2005
    3. Press F4 to display the Properties window
    4. Click on the name of your setup/deployment project in the Solution Explorer
    5. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
    6. Click on the "..." button to display the Post-build Event Command Line dialog
    7. Add the following command line in the Post-build event command line text box:
      cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOuputPath)"
    8. Build your project in Visual Studio 2005

    <update date="1/17/2011"> Fixed broken download link to the sample script. </update>

     

  • Aaron Stebner's WebLog

    Mailbag: How to programatically enumerate installed Media Center applications

    • 2 Comments

    Question:

    I would like to write an application that provides shortcuts to all registered Windows Media Center applications and entry points on the system to allow users to launch them more easily.  How can I reliably obtain a list of registered Media Center applications on a system and then launch the applications when a user chooses the shortcuts?

    Answer:

    You can use the following algorithm to enumerate all registered Windows Media Center applications and entry points and then launch an entry point within Media Center:

    1. Call the IExtensibilityApplications::GetFilteredEntryPoints API described at http://msdn2.microsoft.com/en-us/library/aa468392.aspx to get a list of all registered entry points.  There is a note in this documentation stating that you have to pass in a category name to filter against, but that note is not accurate. If you pass null for strCategory (but not an empty string), it will match all entry points in all categories
    2. Use the returned list from the GetFilteredEntryPoints API to create a list of shortcuts in your application UI
    3. When the user clicks on an entry point link in your application UI, use the MediaCenterEnvironment.LaunchEntryPoint method described at http://msdn2.microsoft.com/en-us/library/bb189321.aspx to launch the entry point.  Make sure to not use the IExtensibilityApplications::LaunchEntryPoint method because that will cause Media Center to launch the entry point in an alternative shell application instead of in Media Center itself.

    One additional note here - in the documentation for IExtensibilityApplications::GetFilteredEntryPoints at http://msdn2.microsoft.com/en-us/library/aa468392.aspx, there is a Remarks section that states the following:

    "If a category is not specified in strCategory, results will not be returned in pRetVal."

    This remark is not accurate.  This API supports both of the following:

    • Passing null as the value for strCategory - doing this will cause this method to return a list of entry points registered in all categories instead of in a specific category
    • Passing a category substring - doing this will cause the method to return a list of entry points registered in categories that contain the substring.  The substring must be delimited by a backslash that represents a registry sub-key.  For example, you cannot pass in "back" to match applications registered in the Background category, but you can pass in "Services" to match all applications registered in any of the Services categories.
  • Aaron Stebner's WebLog

    Online Spotlight has been updated in Windows Media Center for Windows Vista

    • 1 Comments

    As several folks have already noted (including Ian Dixon in this blog post and Niall Ginsbourg in this blog post), systems running Windows Vista Home Premium and Ultimate now have a refreshed version of Online Spotlight available within Windows Media Center.  This new Online Spotlight includes an Explore tile in the Online Media strip on the Windows Media Center start menu, and tiles named More Pictures, More Music, More TV and More Sports on their respective strips on the start menu.

    The updated look and feel for Online Spotlight is only a first step.  We hope to see new waves of partner applications that use the exciting new Windows Media Center development technologies in Windows Vista (MCML and WPF XBAPs).  Some examples of new applications implemented in MCML were introduced at CES 2007 in Bill Gates' keynote address, including applications from partners such as Showtime, Nickelodeon and Starz (the Vongo video download service shown in this photo by Ian Dixon).

    I also wanted to comment about a scenario that Niall specifically mentioned in his blog post.  He reported that he only saw a few applications available in Online Spotlight on his system.  This is likely happening because the system he is using is x64, and possibly also because he is located in Australia.  As I mentioned in this previous blog post, there are several Online Spotlight applications that depend on 32-bit-only ActiveX controls such as the Flash player.  As a result, the new version of Online Spotlight contains filtering logic to not display applications that will not work correctly on an x64 version of Windows Vista.  There is additional filtering logic based on the locale of the system so that English-only or United States-only applications will not appear in other locales.

    I encourage you to check out the new interface for Online Spotlight if you have access to Windows Vista Home Premium or Ultimate.  Also, keep an eye out for updated partner content within Online Spotlight on a regular basis in the future.

  • Aaron Stebner's WebLog

    Mailbag: How to detect the presence of the VC 8.0 runtime redistributable package

    • 10 Comments

    Question:

    I am building an installer that will include the Visual C++ (VC) 8.0 runtime files redistributable package (vcredist_x86.exevcredist_x64.exe and/or vcredist_ia64.exe) as a prerequisite.  How can I detect whether or not this package is already installed on the user's system so that my installer can skip installing it when appropriate?

    Answer:

    There was not a specific detection mechanism designed and built into VC 8.0 runtime files redistributable setup packages.  The setup bootstrapper that ships with Visual Studio 2005 uses the following algorithm to check for the existence of these packages:

    1. Call the MsiQueryProductState API
    2. Pass in the product code for the package that you want to detect based on the list below  
    3. Check the return value of this API.  If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed

    Visual C++ 2005 runtime files

    Visual C++ 2005 SP1 runtime files

    Visual C++ 2005 SP1 ATL Security Update runtime files

    However, this algorithm is somewhat incomplete.  It does not cover cases where a user has installed some other application on the system that includes the VC 8.0 runtime redistributable merge modules (MSMs) as part of its MSI package.  It also does not cover the case of Windows Vista, where the VC 8.0 runtime files are installed as part of the OS.

    The safest way for a setup to manage detection for the VC 8.0 runtime redistributable package is to use an algorithm similar to the one listed above to check for the MSI product code and then install if it is not yet installed.  This may lead to a few cases where the setup will install it when it doesn't technically need to, but that is better than any scenarios where it could might end up not installing it when the VC runtime files are not yet present.  In addition, using this approach will add a reference count to the VC runtime files to prevent scenarios where uninstalling some other application that includes the VC runtime MSMs causes the VC runtime files to be removed from the system.

    One important note - the VC runtime redistributable packages require that the system has at least Windows Installer 3.0 (and ideally Windows Installer 3.1 because any future hotfixes produced for this package will require Windows Installer 3.1).  If your setup is going to install the VC runtime redist package, it should also check for the presence of Windows Installer 3.x and install it as well if it is not yet installed on the system.

    Other options for installing the VC 8.0 runtime files

    I also want to point out that there are other options for applications that depend on the VC 8.0 runtime files besides redistributing the vcredist_x86 or vcredist_x64 MSI packages. 

    • Include the VC runtime MSMs in your MSI package directly - this can cause issues like the ones I described in this previous blog post, but in some cases this is the easiest solution
    • Statically link to the VC runtimes when building your application - this increases the size of your binaries but eliminates the need to validate that these runtime files are present on users' systems at setup time for your application
    • Install the VC runtimes to a local folder for use only with your application - this complicates the installation logic in your MSI and causes hotfixes to not apply for your the version of these runtime files included with your application on Windows 2000

    These options have various pros and cons, and the choice you make depends on your applications and the scenarios you want to support.  There is additional discussions of some of the trade-offs on the MSDN Forums (for example, this post and this post).  I encourage you to read some of these posts and others that are included as links within them before making your setup packaging decision for the VC 8.0 runtime files.

    <update date="1/24/2006"> Added information about the IA64 version of the VC redist package. </update>

    <update date="11/19/2009"> Added information about VC++ 2005 SP1 and VC++ 2005 SP1 ATL Security Update packages. </update>

     

  • Aaron Stebner's WebLog

    Updated versions of Big Screen Headlines and mceBackup now available for download

    • 0 Comments

    I previously posted introductions to 2 Windows Media Center applications for Windows Vista - Niall Ginsbourg's Big Screen Headlines and Ian Dixon's mceBackup v2.0.  Over the weekend, both Niall and Ian have released updated versions of these applications, and I wanted to bring them to your attention in cased you missed either of them.

    Big Screen Headlines v0.8.4

    mceBackup 2.0 update

    If you already have installed earlier versions of these tools, I encourage you to uninstall them and install the new versions.  If you haven't yet tried these applications, I highly encourage you to download them and give them a try!

  • Aaron Stebner's WebLog

    Information about Windows Vista Multilingual User Interface (MUI)

    • 1 Comments

    I recently found some really useful information about multilingual user interface (MUI) features in Windows Vista, and so I wanted to provide a link here for anyone who does multilingual development or manages multilingual systems deployment.

    You can find the Guide to Windows Vista Multilingual User Interface at http://technet2.microsoft.com/WindowsVista/en/library/85e289ca-9fd8-4963-b06a-5ecc457006c71033.mspx?mfr=true

    This guide includes discussion of the following topics:

    • What is Multilingual User Interface (MUI) - describes Windows Vista MUI implementation
    • Benefits of MUI - why you would want to configure an MUI system, and some limitations of the Windows Vista MUI model
    • Planning for MUI - determining the requirements of your users and the capabilities of your hardware; deploying a global OS image or regional images
    • Using MUI - configuration options in the Windows Vista OS UI; installing additional MUI language packs in silent mode
    • Prerequisites for using MUI - technical and licensing requirements for deploying MUI language packs for Windows Vista

    A key point listed in the prerequisites section of this document is a licensing requirement that states that a Windows Vista OS can only include a single language, with the exception of the Ultimate and Enterprise editions.

    Some additional links that are useful when preparing to deploy Windows Vista OS images include the following:

  • Aaron Stebner's WebLog

    Problems with custom actions that depend on the Visual C++ 8.0 runtime files on Windows Vista or Windows Server 2008

    • 10 Comments

    I recently heard about a couple of scenarios that were causing problems for folks creating MSI-based setup packages.  In one case, the developer was installing a service and attempting to start it using the ServiceControl table, but it failed when running setup on Windows Vista or Windows Server 2008.  In another case, the developer was attempting to self-register a DLL and it failed when running setup on Windows Vista or Windows Server 2008 (such as in the scenario described here).

    In both of these scenarios, the error message "Activation context generation failed for <assembly name>" was logged in the event log.  The error code seen in these scenarios was -2147010895, which is 0x800736B1 in hexadecimal and translates to ERROR_SXS_CANT_GEN_ACTCTX.

    In both cases, the binaries in question had a dependency on the Visual C++ 8.0 runtime files, and the MSI included the MSMs to install the VC 8.0 runtime files as part of the same setup.

    Root cause of this side-by-side activation error

    There is a tricky issue with the VC 8.0 runtime files that only affects Windows Vista and later versions of Windows and is does not appear to be well documented yet.  Specifically, on Windows Vista and later, the VC 8.0 runtime files are installed to the WinSxS cache as global assemblies, whereas on downlevel platforms such as Windows XP or Windows Server 2003, the VC 8.0 runtime files are installed using standard Windows Installer file table entries.

    In Windows Installer, you cannot use global assemblies until the installation transaction has been commited.  This means that only commit custom actions or custom actions sequenced to run after InstallFinalize will be able to use global assemblies that are being installed as part of the same MSI.

    In the 2 scenarios I described above, the MSI was attempting to use binaries that depended on the VC 8.0 runtime files before they were fully installed to the global assembly cache, and the binaries failed to run and logged a missing dependency error.

    Possible workarounds to fix an MSI that fails with a side-by-side activation error

    There are a few possible workarounds for this type of scenario:

    • Install the VC 8.0 runtimes using the redistributable package via a setup chainer instead of merging in the MSMs.  The redistributable packages can be downloaded from the following locations:  x86; x64; ia64
    • Install private copies of the VC 8.0 runtime files.  This option is described in the section titled Deploying Visual C++ library DLLs as private assemblies in this MSDN post.
    • Statically link to the VC 8.0 runtimes when building your binaries so that they will not depend on the global assemblies

    If none of the above are possible, you can also use one of these workarounds depending on the exact scenario you need to support:

    • In the case of service installation, use a commit custom action or a custom action scheduled after InstallFinalize.  You cannot use the ServiceInstall or ServiceControl table if the service depends on any global assemblies (such as the VC 8.0 runtime files or a managed .NET Framework assembly).  This scenario is specifically described in the ServiceControl table documentation on MSDN.
    • In the case of self-registration, convert the self-registration information to standard MSI authoring (registry keys in most cases) and stop using self-registration.  If that is not possible for some reason, you must use a commit custom action or a custom action scheduled after InstallFinalize to run self-registration instead of the SelfReg table.

    A note about eliminating self-registration

    Sometimes, it can be difficult to convert self-registration to standard MSI authoring, especially in cases like the ATL project template in Visual Studio.   The ATL project only has the following code for the DllRegisterServer function:

    STDAPI DllRegisterServer(void)
    {
    // registers object, typelib and all interfaces in typelib
    return _Module.RegisterServer(TRUE);
    }

    The ATL project contains a .rgs file that is embedded as a resource when the binary is built, and some specific code within ATL parses that .rgs file to replace some tokens to determine what registry entries to write when running DllRegisterServer.

    In cases like this where you do not have direct ownership of the self-registration code in your binary, it is most effective to use a self-registration capturing tool such as the Tallow tool that is part of the WiX v2.0 toolset or the Heat tool that is a part of the WiX v3.0 toolset.

    <update date="3/21/2008"> Added notes to indicate that this issue will affect not only Windows Vista but also other versions of Windows that shipped after Vista such as Windows Server 2008. </update>

    <update date="2/20/2009"> Added a link to an MSDN topic that describes how to deploy Visual C++ DLLs as private assemblies. </update>

     

  • Aaron Stebner's WebLog

    Mailbag: How to launch an EXE from within Windows Media Center

    • 2 Comments

    Question:

    I have written an executable that I want to be able to run as a Windows Media Center application and as a standalone program outside of Media Center.  I am able to register the executable with Media Center using RegisterMceApp or RegisterApplication and it can be launched from within Media Center.  When I launch my executable from within Media Center, I see that Media Center automatically minimizes to get out of the way of the program when launching it.  However, when I close my program, Media Center does not restore, and the user has to navigate back to Media Center on their own (which is difficult with only a remote control and/or via a Media Center extender session).

    How can I cause Media Center to restore to its previous full-screen state when a user exits my executable after it was launched within Media Center?

    Answer:

    To start with, you will need to register the EXE as a Windows Media Center application using the RegisterApplication API or the RegisterMceApp utility.  When registering an EXE, you will need to create an entry point that specifies a Run attribute that points to the path of the EXE on the local file system.

    If your EXE is designed to run both from within Media Center and as a standalone application, you will need some mechanism of differentiating how the user launched the EXE so that you can have the application navigate back to Media Center when the user exits only in the case when it was launched from within Media Center.  One way to differentiate launch states is to have Windows Media Center pass a command line parameter when launching the application.

    Windows Media Center does not support specifying any command line parameters in the Run attribute, so you will need to work around that limitation somehow.  Possible options include the following:

    1. Create a Windows link (.lnk) file and register this link file so it will be launched by the Run attribute.  Then, you can pass a command line parameter via the properties for the link file to signal to the application that it has been launched by Media Center
    2. Create a wrapper EXE that is used to launch the main application within Media Center.  The wrapper EXE can launch the main application with a Media Center-specific command line switch to signal to the application that it has been launched by Media Center and it will need to navigate back to Media Center when it exits

    In addition to registering the application, you will need to add logic in the application itself to handle navigating back to Media Center when the application exits.  The following is an example algorithm that can be used to accomplish this:

    • Set a flag when the Media Center-specific command line switch is passed in when the application is launched
    • If the flag is set to true, perform any Media Center-specific initialization for the application (such as updating the UI so it will display better on a TV or behave better via a remote control)
    • When the application exits, check for the existence of this flag
    • If the flag is set to true, call the Win32 FindWindow API and pass in eHome Render Window for the class name and NULL for the window name
    • If FindWindow returns a valid HWND value, call the Win32 ShowWindow API and pass in the HWND and SW_RESTORE for the command

    Example of an EXE that is registered as a Windows Media Center application:

    The Windows Vista games (such as Chess, FreeCell, etc) are examples of EXEs that are designed to launch as Media Center applications and as standalone applications.  They use the 1st strategy listed above for their Media Center application registration.

    As an example, you can open regedit on a Windows Vista Home Premium or Ultimate system and look at the Media Center entry point registration for one of the Windows games.  For the chess game, the Run attribute is located in the following location in the registry and contains the following setting:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points\{115EADF1-41C4-471b-8FE5-7A52B91BFE75}]
    Run=%ProgramFiles%\Microsoft Games\Chess\ChessMCE.lnk

    Next, you can go to the %ProgramFiles%\Microsoft Games\Chess folder specified by the Run entry, right-click on the ChessMCE.lnk file and choose Properties.  In the properties page for the .lnk file, you can see that a command line parameter is being passed to the game executable by looking at the value in the Target text box.  For the Chess game, it looks like the following:

    "%ProgramFiles%\Microsoft Games\chess\chess.exe" -mce

    The Windows games use this -mce command line switch to determine whether or not they were launched within Media Center.  When the games are launched with the -mce switch, they will display in full-screen UI mode, hide the standard Windows title bar and menu, and display text with larger fonts that are easier to read on a TV from 10 feet away.  They also navigate the user back to Media Center when the user exits the application.

    Interestingly, you can also launch the games with this -mce command line switch on your own outside of Media Center, and they will launch Media Center when you exit, even if it was not previously running on the system.

  • Aaron Stebner's WebLog

    Why .NET Framework 3.0 language packs will not install correctly on Windows Vista

    • 0 Comments

    I previously wrote a blog post describing why the MSI-based .NET Framework 2.0 language packs do not allow installation on Windows Vista, and I also provided an unsupported workaround that allows you to get around the installation block and install them anyways if it is truly necessary.

    Similar behavior exists in the setup package for the MSI-based .NET Framework 3.0 language packs, so I wanted to describe that scenario as well.

    .NET Framework 3.0 language pack setup behavior on Windows Vista

    If you try to run one of the installers for a .NET Framework 3.0 language pack on Windows Vista, you will see an error dialog with text that looks like the following:

    You must use "Turn Windows features on or off" in the Control Panel to install or configure Microsoft .NET Framework 3.0 x64 Language Pack - FRA.

    The .NET Framework 3.0 language packs are included in the Windows Vista MUI language packs just like the .NET Framework 2.0 language packs, so my previous explanation about why installation is blocked holds true here as well.

    One key difference to note is that if you try to run an MSI-based .NET Framework 3.0 language pack setup on Windows Vista, the return code is not artificially mapped to 0 to indicate success like it is in the .NET Framework 2.0 language packs.  Instead it will return code 5100, which according to this list that I previously published is a generic setup block return code.

    Therefore, if you are creating an installer that will include any of the .NET Framework 3.0 language pack setup packages, you will need to make sure that you check what OS you are installing on and not attempt to install the language pack on Windows Vista or any future OS's.  If you do not include this OS version check, the language pack setup will fail with error code 5100 and your setup may also fail as a result.

    How to install MSI-based language packs on Windows Vista

    If you have a scenario where you need to install more than one .NET Framework 3.0 language pack on Windows Vista and you do not have access to the Ultimate or Enterprise editions in order to install the Windows Vista MUI language pack, you can use the following steps to unblock installation.  Before doing this, please take note of the following important caveats:

    • This installation method is not officially supported by Microsoft, so if you undertake these steps, it is at your own risk
    • Hotfixes that specifically target the .NET Framework 3.0 language packs are not very likely, but in the case that Microsoft releases a hotfix for any of the language packs, they will most likely not install correctly on Windows Vista for language packs installed in this way.  This means you will likely have to manually install hotfix files onto systems that use this installation method.
    • If you install the language packs in this way on Windows Vista Ultimate or Enterprise edition and then decide to install the OS language pack, there is a chance that the MSI-based language pack will have interaction issues with the OS language pack.  I strongly advise uninstalling the MSI-based language pack before installing any OS language packs to avoid any interaction issues like this.

    You can use the following steps to install MSI-based .NET Framework 3.0 language packs on Windows Vista:

    1. Download the .NET Framework 3.0 language pack that you want to install by going to http://www.microsoft.com/downloads/details.aspx?familyid=41c61d2a-d411-4dde-9013-bb08eb688bb6&displaylang=fr, selecting the desired language in the dropdown list box and clicking Download
    2. Extract the contents of the dotnetfx3langpack<lang>.exe downloaded in step 1 by running dotnetfx3langpack<lang>.exe /x:%temp%\dotnetfx3langpack
    3. Open the file %temp%\dotnetfx3langpack\setup.sdb in a text editor such as notepad
    4. In the [VS Custom] section, change the values BlockFutureClientOS and BlockFutureServerOS to both equal 0
    5. Save and close the file setup.sdb
    6. Run the file %temp%\dotnetfx3langpack\setup.exe to install the language pack
  • Aaron Stebner's WebLog

    MceBackup version 2.0 beta version available for download

    • 1 Comments

    Ian Dixon has created a new 2.0 version of his MceBackup tool that supports Windows Media Center in Windows Vista as well as Windows XP Media Center Edition.  The new version of the tool requires the .NET Framework 2.0 (which is a part of the OS on Windows Vista but may need to be installed if you are running on any other OS).

    MceBackup 2.0 includes the following features:

    • Can be used to transfer settings from one Windows Media Center PC to another
    • Includes command line and 2 foot GUI versions (a 10 foot GUI version that integrates into Windows Media Center is coming soon)
    • Backs up TV channel assignment
    • Backs up scheduled recordings and series recordings
    • Backs up recorded TV shows to local drives or UNC paths
    • Backs up one additional folder of the user's choosing
    • Has a scheduling engine to allow automating backups
    • Displays the status of critical Windows Media Center services

    Ian has posted information about the MceBackup tool on the new Media Center Show Community site (which I also encourage you to check out when you get a chance).  Here are the direct links:

  • Aaron Stebner's WebLog

    Links to detailed information about Visual Studio 2005 SP1 setup

    • 1 Comments

    Heath Stewart has written several very useful blog posts about Visual Studio 2005 SP1 that I wanted to draw everyone's attention to.  Some are useful for end users who want to install Visual Studio 2005 SP1, and others are useful for setup developers and system administrators who want to deploy Visual Studio 2005 SP1.  The following is a list of the links to items Heath has posted so far:

    Links to general information:

    Links for setup developers and system administrators:

  • Aaron Stebner's WebLog

    Why .NET Framework 2.0 language packs will not install correctly on Windows Vista

    • 5 Comments

    Michael Kaplan wrote a blog post a while back that described an algorithm for enumerating installed .NET Framework culture information on a computer.  While I was away on vacation for the holidays, he posted a follow-up that explains why this algorithm won't work reliably on Windows Vista.  The underlying issue is that the MSI-based .NET Framework 2.0 language packs will not install on Windows Vista.

    Michael explained some of the reasoning for this in his blog post, but I wanted to explain in a bit more detail the setup logic that prevents the .NET Framework 2.0 language packs from installing as-is on Windows Vista and also provide some options for working around this if necessary on your systems.

    How .NET Framework 2.0 language pack setup works behind the scenes

    I previously explained a scenario where Visual Studio 2005 would fail to install on beta versions of the Windows Vista x64 edition.  Partially to solve this scenario, and partially to  prevent users from being able to install both the MSI-based redistributable and the Windows OS component for the .NET Framework 2.0, some registry values were added to the final release of Windows Vista.

    These registry values are located at HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\<LCID>, where <LCID> is one of the following 4-digit language codes for .NET Framework 2.0 language packs on a Windows Vista system:

    1028, 1029, 1030, 1031, 1032, 1035, 1036, 1038, 1040, 1041, 1042, 1043, 1044, 1045, 1046, 1049, 1053, 1055, 2052, 2070, 3076 and 3082

    Each of these registry sub-keys has 3 values named Install, MSI and OCM.  All 3 of these values are set to 1 for each LCID in the above list.

    The MSI-based .NET Framework 2.0 language pack installer packages contain logic in the setup bootstrapper that prevent the user from installing them if it detects that the language pack is already installed as an OS component.  The algorithm it uses to determine whether or not the language pack is installed as an OS component is the following:

    • Look in the [Setup] section of the file install.ini that is a part of the langpack.exe self-extracting setup package
    • Retrieve the value of the ProductRegKey item to determine what registry key to look at
    • Retrieve the value of the ProductRegValue item to determine what registry value to look at
    • Check to see if that key/value exists and is equal to 1, and if so, block installation and tell the user that the product is already installed as part of the OS

    .NET Framework 2.0 language pack setup behavior on Windows Vista

    As a result of all of the above, users cannot install the .NET Framework 2.0 language packs on Windows Vista.  The officially supported way to install .NET Framework 2.0 language packs is to install the corresponding Windows Vista MUI language pack (which also includes .NET Framework 2.0 language resources since the .NET Framework 2.0 is an OS component on Windows Vista).  However, Windows Vista licensing terms only support installing multiple language packs on the same system for a couple of editions - Ultimate and Enterprise.   The Guide to Windows Vista Multilingual User Interface has more information about language packs on Windows Vista if you are interested in reading more details about this scenario.

    Because it is possible to install the .NET Framework 2.0 language packs as an OS component on Windows Vista, it was deemed necessary to prevent the MSI-based language packs from also installing in order to avoid interaction issues.  The OS installation technology is (unfortunately) different than the Windows Installer (MSI) application installation technology, and therefore so is the system of servicing the files installed by each technology.  Without being able to reliably determine which technology installed the file, it would be very difficult do deliver updates and hotfixes for these files and difficult to support repair and uninstall scenarios.  This led to the decision to not allow the MSI-based language packs to install. 

    However, in order to be compatible with multi-lingual applications that include the MSI-based language packs as a part of their setup, the return codes for the MSI-based language packs will indicate success if the user tries to install them on Windows Vista.  This should allow 3rd party installers to complete successfully in most cases.

    In these cases, the language pack setups will return success, but the files will not actually exist on Windows Vista.  As a result, some .NET Framework error messages and other strings will not display in the language of the language packs because the files themselves will not end up getting installed on the user's system.  Also, the algorithm that Michael Kaplan previously described will report (correctly) that the language pack satellite assemblies are not installed, which is inconsistent with the successful return code that language pack setups return.

    A customer reported a bug describing this issue on the Product Feedback web site at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=248617.

    How to install MSI-based language packs on Windows Vista

    In some cases, it is not necessary to install .NET Framework 2.0 language packs even if you are deploying a multi-lingual .NET Framework 2.0 application.  This is because the strings included as part of the language pack are only used to display errors that are not handled within the language resources of the application itself.  Therefore, errors that developers want to display correctly can be handled in the application code and included in the application's language resources.

    However, if you have a scenario where you need to install more than one .NET Framework 2.0 language pack on Windows Vista and you do not have access to the Ultimate or Enterprise editions, you can use the following steps to unblock installation.  Before doing this, please take note of the following important caveats:

    • This installation method is not officially supported by Microsoft, so if you undertake these steps, it is at your own risk
    • Hotfixes that specifically target the .NET Framework 2.0 language packs are not very likely, but in the case that Microsoft releases a hotfix for any of the language packs, they will most likely not install correctly on Windows Vista for language packs installed in this way.  This means you will likely have to manually install hotfix files onto systems that use this installation method.
    • If you install the language packs in this way on Windows Vista Ultimate or Enterprise edition and then decide to install the OS language pack, there is a chance that the MSI-based language pack will have interaction issues with the OS language pack.  I strongly advise uninstalling the MSI-based language pack before installing any OS language packs to avoid any interaction issues like this.

    You can use the following steps to install MSI-based .NET Framework 2.0 language packs on Windows Vista:

    1. Download the .NET Framework 2.0 language pack that you want to install by going to  http://www.microsoft.com/downloads/details.aspx?familyid=39C8B63B-F64B-4B68-A774-B64ED0C32AE7&displaylang=en, selecting the desired language in the dropdown list box and clicking Download
    2. Extract the contents of the langpack.exe file downloaded in step 1 by running langpack.exe /t:%temp% /c
    3. Open the file %temp%\install.ini in a text editor such as notepad
    4. In the [Setup] section, look at the ProductRegKey and ProductRegValue items
    5. Using regedit, rename the registry value referred to by the ProductRegKey and ProductRegValue items in install.ini.  In most (but not all) cases, this value will be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727\<LCID>\OCM.
    6. Run the file %temp%\install.exe to install the language pack
    7. Rename the registry value that was changed in step 5 above back to the initial value

    Note: you can change the %temp% folder to some other location when extracting the contents of langpack.exe above.

    There is a bug in the installation logic for the .NET Framework 2.0 Arabic language pack that was reported at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=248621.  However, if you use the installation instructions described above instead of the ones described in the above bug reports, they will work equally well for all language packs and you will not need to perform any special steps to workaround this Arabic installation issue.

    What to do if the language pack setup logic is problematic for your scenarios

    I wanted to add one final comment here - I think that the packaging model for the .NET Framework 2.0 language packs is less than ideal on Windows Vista.  However, given the variables that the teams had to work with and the need to complete work on Windows Vista, the decision was made to not allow the MSI-based language packs to install on Windows Vista and the behavior currently seen when trying to install the language packs is by design.  If you have scenarios where this design does not work well, please report feedback on the .NET Framework Product Feedback site so that the teams will have more data to use when evaluating future changes to this packaging model.  Based on my past experience, the data from this site is taken very seriously by the teams here at Microsoft, so please do not think that this information goes into a black hole or is not ever looked at by product teams.

    <update date="1/2/2007"> Modified the wording where I describe Michael Kaplan's .NET Framework language resource enumeration algorithm.  Previously, I stated that his algorithm would not work on Windows Vista.  The algorithm itself works fine, but it returns a result that is not consistent with the return code from language pack setup.  In this case, the language pack setup return code is the thing that is incorrect - the language resources are not actually installed on the system, but setup "lies" and reports that it installed successfully to try to help avoid application compatibility issues for applications that include the language packs as part of their setup processes.  </update>

     

Page 1 of 1 (22 items)