Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
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:
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.
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!
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'.
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.
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:
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.
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.
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:
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:
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.
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.
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:
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.
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:
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:
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>
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):
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.
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.
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:
<update date="1/17/2011"> Fixed broken download link to the sample script. </update>
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?
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:
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:
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.
I am building an installer that will include the Visual C++ (VC) 8.0 runtime files redistributable package (vcredist_x86.exe, vcredist_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?
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:
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.
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>
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!
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:
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:
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:
If none of the above are possible, you can also use one of these workarounds depending on the exact scenario you need to support:
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 typelibreturn _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>
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?
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:
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:
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.
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:
You can use the following steps to install MSI-based .NET Framework 3.0 language packs on Windows Vista:
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:
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:
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:
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:
.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.
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:
You can use the following steps to install MSI-based .NET Framework 2.0 language packs on Windows Vista:
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>