Aaron Stebner's WebLog

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

August, 2006

  • Aaron Stebner's WebLog

    More new Windows Media Center development topics have been posted on the Media Center Sandbox

    • 0 Comments

    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.

     

  • Aaron Stebner's WebLog

    Adding strips and tiles to the Windows Media Center Start menu in Windows Vista

    • 22 Comments

    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:

    1. Create an XML file that can be used by the RegisterApplication or RegisterMceApp.exe to register an application and one or more entry points
    2. Associate the entry points that you want to appear in the custom strip on the Start menu with a specific category name of your choosing
    3. Register the application and entry points using RegisterApplication or RegisterMceApp.exe
    4. Create a registry sub-key named HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Start Menu\Applications\{APPLICATION GUID} where APPLICATION GUID is the one provided in the XML file in step 1 above
    5. Create the following values under this sub-key:
      Category (REG_SZ) - the name of the category name that you used in step 2 above
      OnStartMenu (REG_SZ) - set this to true
      Title (REG_SZ) - the display name for the custom strip on the Start menu

    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:

    1. Download the ZIP file and extract the contents to a Windows Vista Home Premium or Ultimate system
    2. Click on the Start menu, choose All Programs, then Accessories
    3. Right-click on Command Prompt and choose Run as administrator, then click Allow
    4. Run %windir%\ehome\registermceapp.exe TestApp1.xml to register the first application and 5 entry points
    5. Run %windir%\ehome\registermceapp.exe TestApp2.xml to register the second application and 5 entry points
    6. Run regedit.exe /s TestApp1.reg to add the first application to the Windows Media Center Start menu
    7. Run regedit.exe /s TestApp2.reg to add the second application to the Windows Media Center Start menu

    To remove these applications from the Windows Media Center Start menu, you will need to use these steps:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on Command Prompt and choose Run as administrator, then click Allow
    3. Run %windir%\ehome\registermceapp.exe /u TestApp1.xml
    4. Run %windir%\ehome\registermceapp.exe /u TestApp2.xml
    5. Run regedit.exe and remove the sub-key named HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Start Menu\Applications

    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 each entry point to launch a unique task
    • Change all of the GUIDs listed in the XML and REG files to be specific to your scenarios.  You can use guidgen.exe in Visual Studio or a website such as this to generate new GUIDs

    <update date="1/20/2011"> Fixed broken link to the sample referenced in this blog post. </update>

     

  • Aaron Stebner's WebLog

    Checking for the .NET Framework at application runtime, not just at setup time

    • 4 Comments

    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.

     

  • Aaron Stebner's WebLog

    MSDN Magazine article with details about new globalization features in Windows Vista

    • 0 Comments

    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:

    • Custom locales and custom cultures
    • Windows-only cultures and regions
    • How LCIDS are (or are not) used in Windows Vista
    • .NET encodings and Windows code pages
    • .NET encoding classes and Windows code page functions
    • Windows Vista and managed IDN mapping APIs

    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.

     

  • Aaron Stebner's WebLog

    Updated sample .NET Framework detection code that does more in-depth checking

    • 19 Comments

    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:

    • Added the CheckNetfxVersionUsingMscoree and GetProcessorArchitectureFlag functions
    • Added logic in WinMain to call CheckNetfxVersionUsingMscoree in addition to the original calls to check .NET Framework registry data
    • Updated the code to use strsafe.h functions for string manipulations

    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>

     

  • Aaron Stebner's WebLog

    New location for Sonic CD/DVD burning log file in Windows Vista

    • 0 Comments

    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:

    1. Click on the Start menu, choose Run and type notepad %temp%\soniclog_mce.log
    2. Click Yes to create a new file in this location
    3. Close Notepad and click Yes to save the 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.

     

  • Aaron Stebner's WebLog

    How to fix Visual Studio 2005 setup projects on Windows Vista post-beta 2 builds

    • 10 Comments

    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:

    New setup project error dialog on Windows Vista

    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:

    Open existing setup project error dialog on Windows Vista

    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:

    1. Close all instances of Visual Studio 2005 that are running on your system
    2. Click on the Start menu, choose All Programs, then choose Accessories
    3. Right-click on Command Prompt and choose Run as administrator
    4. Click allow to launch an administrator command prompt
    5. Run reg delete "HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\Deployment\Deployables\Setup\Plugins\VJSharpPlugin" /f
    6. Re-launch Visual Studio 2005 and try to open/create a setup project again

    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:

     

Page 2 of 2 (32 items) 12