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.
I have posted a couple of new items on the Media Center Sandbox site in the past week or so that I want to cross-post here in case you missed them over there.
The first topic, titled How to debug a running Windows Media Center application in Windows Vista using Visual Studio 2005, describes a step-by-step process you can use to attach to the process that is hosting your Windows Media Center application, set breakpoints and debug your add-in assembly code as it runs within Windows Media Center.
The second topic, titled How to register an entry point for a Windows Media Center Presentation Layer Web Application, demonstrates the XML syntax needed to run RegisterMceApp.exe or use the RegisterApplication API to register an MCML web application so that it can be launched directly from within Windows Media Center without needing to use McmlPad.
Hopefully you will find these topics useful as you develop Windows Media Center applications on Windows Vista.
As those of you who have seen Windows Media Center in Windows Vista already know, there has been a redesign of the Start menu. Windows Media Center now has the concept of strips and tiles on the Start menu as well as horizontal and vertical navigation.
A strip is a top-level menu on the Windows Media Center Start menu that can be reached by scrolling vertically. Examples include Music, Pictures + Videos, etc. A tile is an item in a strip. Each tile invokes a single action or entry point within Windows Media Center.
With the redesign of the Start menu, Windows Media Center for Windows Vista also includes a new way of registering applications and entry points to appear on the Start menu. It is possible to add up to 2 new strips to the Start menu using existing extensibility mechanisms in Windows Media Center, and each of those 2 strips can contain up to 5 tiles.
The following steps provide a high-level overview of how to create a custom strip on the Windows Media Center Start menu in Windows Vista:
The above steps are fairly abstract, so I have posted a set of example files on my file server to illustrate how to create custom strips. The files in this ZIP package will allow you to register 2 custom strips with 5 tiles each on the Windows Media Center Start menu in Windows Vista. To accomplish this, use these steps:
To remove these applications from the Windows Media Center Start menu, you will need to use these steps:
Please note that I have only provided these XML and REG files as an example. They are not real applications. Each tile that is added to the 2 custom strips on the Start menu in this scenario launches the same Windows Media Center Presentation Layer Web Application for simplicity's sake. If you want to create your own custom strip and tiles, you will want to make the following modifications to the sample files:
<update date="1/20/2011"> Fixed broken link to the sample referenced in this blog post. </update>
I posted some updated sample code last night that can be used to detect whether or not the various versions of the .NET Framework are installed on a system. To go along with this sample code, I wanted to also mention a consideration that developers should keep in mind when building an application that relies upon the .NET Framework.
It is common to see an application add code to their setup to check for the .NET Framework and install it as a prerequisite at setup time. It is less common (at least in my experience) for an application to perform a runtime check in your application startup code to validate that the necessary version of the .NET Framework is installed.
The .NET Framework can be independently uninstalled out from under your application if a user finds it and removes it in the Add/Remove Programs control panel. I strongly recommend adding logic like I demonstrated in my sample code to your application's startup code paths. Doing so makes your application more bulletproof and allows you to display more user friendly error messages with exact steps that users can follow to resolve issues related to the .NET Framework.
A while back, I posted an item introducing the beta version of the Microsoft Locale Builder for Windows Vista beta 2. I just noticed that there has been a MSDN magazine article published since my previous blog post that provides a ton of in-depth information regarding new globalization features in Windows Vista. The following topics are covered in this article:
In addition, there are some screenshots of custom locales being used in the Language and Regional Options control panel and in Microsoft Outlook, and a screenshot of the Microsoft Locale Builder UI.
I encourage you to check out this article to learn more about Windows Vista globalization support features.
Thanks to Shawn Steele for sending me a link to this article.
Cool side note - the Microsoft Locale Builder ships a version of WiX that it uses to build MSIs that can be used to install the custom locales that it generates.
I previously posted some sample code to detect the version(s) and service pack levels of the .NET Framework that are installed on a computer (here and here). The original version of the sample code that I wrote queries the officially documented registry values that are used to detect the presence of each specific version of the .NET Framework.
Since I posted this sample code, I have heard feedback from some customers who are including the .NET Framework as part of their setup packages. They indicated that sometimes this code reports false positives - in other words, the sample returns true for a specific version of the .NET Framework but it isn't actually installed on the system. I have seen this a couple of times in the past as well, and the root cause was that some of the registry entries used to detect the .NET Framework were orphaned on the system after an uninstall or OS reinstall scenario.
In order to help address this type of issue, I've created a new version of the sample code that adds some new checks to help guard against orphaned registry values. The logic it uses is to query the registry values like the previous sample used to, and then to supplement that with an additional check that loads mscoree.dll and uses some of its APIs to query for the presence of specific versions of the .NET Framework. The underlying algorithm for this mscoree.dll-based check came from Junfeng Zhang and from a sample published on MSDN.
This algorithm should prove more reliable in detecting whether or not a specific version of the .NET Framework is installed on the system because it does not rely solely on the registry. In addition, it provides the side benefit of performing a quick health check for the .NET Framework itself because it attempts to invoke some APIs in the runtime.
The new sample code contains the following specific changes from the previous version that I published:
You will need the following in order to compile this sample:
Please let me know if you have any trouble building or running this sample or incorporating it into your product setup logic.
<update date="5/29/2009"> Fixed broken link to the sample code. </update>
A while back, I posted instructions describing how to cause the Sonic CD/DVD burning engine in Windows XP Media Center Edition to create a log file for debugging purposes. I found out recently that the location for this log file has been changed in Windows Vista.
Here are some revised steps you can use to cause the Sonic CD/DVD burning engine in Windows Media Center for Windows Vista to create a log file:
Just like in Windows XP Media Center Edition, this file has to already exist before the Sonic burning engine will write to it. Once you create a blank log file in the %temp% folder using the above steps, all future CD/DVD burning sessions will write to this log file.
I ran across a mail thread today describing some problems that folks have run into while trying to use the setup and deployment project types in Visual Studio 2005 on post-beta 2 builds of Windows Vista. I want to describe the symptoms and how to workaround this issue in case you run to this in your development scenarios.
What are the issues?
When trying to create a new setup project in Visual Studio 2005 on post-beta 2 builds of Windows Vista, an error dialog appears stating "The Operation could not be completed. The parameter is incorrect." The error dialog looks like this:
When trying to open an existing setup project in Visual Studio 2005 on post-beta 2 builds of Windows Vista, an error dialog appears stating "One or more projects in the solution could not be loaded for the following reason(s): The application for the project is not installed. These projects will be labeled as unavailable in Solution Explorer. Expand the project node to show the reason the project could not be loaded." The error dialog looks like this:
How can I fix these issues?
The underlying issue will be fixed in Visual Studio 2005 service pack 1. Until then, you can workaround this issue by using the following steps:
This workaround will prevent you from including the Visual J# redistributable package in your project using the bootstrapper, but it will allow you to use the rest of the setup/deployment project infrastructure in Visual Studio 2005.
What is the root cause?
I didn't find detailed information about the root cause of this problem, but the information I found stated that the underlying cause is within Visual Studio 2005 and not Windows Vista. Some Windows APIs that Visual Studio 2005 calls were being used in ways that were not officially documented or supported, and this behavior has been changed in Windows Vista. This is one of the dangers of relying on undocumented API behaviors in an application.
One additional note here - if you found this blog post and are using the Visual Studio 2005 setup/deployment projects, I highly encourage you to check out WiX if you haven't already. The following references are very useful for getting started with WiX: