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.
NOTE - this blog post was originally written for the .NET Framework 2.0 and 3.0 on Windows Vista. Since then, Windows 7 has shipped, and it includes the .NET Framework 2.0, 3.0 and 3.5 as OS components. The steps in this blog post apply equally to Windows 7 as well.
Since the Windows Vista public launch in January 2007, I have been receiving questions about how to repair the .NET Framework 2.0 and 3.0 to try to resolve various bugs. As I previously described here, the 2.0 and 3.0 versions are installed as OS components on Windows Vista and do not appear in the Programs and Features (formerly known as Add/Remove Programs) control panel.
Many of the customers I have heard from have tried to use the .NET Framework cleanup tool, but it does not list the .NET Framework 2.0 as a valid removal option when it is run on Windows Vista. This is by design - the cleanup tool does not offer the option to remove any version of the .NET Framework that is an OS component on the OS it is being run on.
Windows Vista OS files and registry information (including those that are a part of the .NET Framework 2.0 and 3.0) are protected by Windows Resource Protection (WRP) in Windows Vista. This means that only the OS installer service (named TrustedInstaller) has permission to modify/remove these files or registry keys unless you specifically take ownership of the files/keys and add additional user accounts to the access permission list (which you should not need to do except in extraordinary circumstances).
If you run into problems using .NET Framework applications on Windows Vista, and you suspect that files or registry entries that are a part of the .NET Framework 2.0 or 3.0 are corrupt, you can use the instructions listed below to attempt to repair them.
Repairing .NET Framework 2.0/3.0 files on Windows Vista
You can use the following steps to repair the files that are a part of the .NET Framework 2.0 and 3.0 on Windows Vista and Windows Server 2008:
Repairing .NET Framework 2.0/3.0 registry entries on Windows Vista
Unfortunately, there is not an easy way of repairing the registry keys/values that are installed by Windows Vista like there is for files. If you want to try to repair the registry keys/values that are a part of the .NET Framework 2.0 and 3.0, you will need to run Windows Vista OS setup again and repair the OS.
<update date="9/8/2008"> Added a link to a knowledge base article with instructions that can be used to fix errors reported by sfc.exe on Windows Vista and Windows Server 2008. </update>
<update date="10/7/2008"> Clarified what SFC does behind the scenes in more detail. </update>
<update date="8/9/2009"> Fixed broken link to knowledge base article in step 7. </update>
<update date="3/10/2010"> Added a note about Windows 7. </update>
Note - this post was originally written for Windows Vista, but it also applies to Windows 7.
Since the Windows Vista public launch in January 2007, I have been receiving questions more frequently about how to repair Windows Media Center to try to resolve various bugs. Many of the customers I have heard from have tried some of the repair steps I have previously posted for Windows XP Media Center Edition (such as this, this or this), but ran into problems getting them to work.
I want to emphasize that OS repair techniques that I have previously documented for Windows XP Media Center Edition will not work on Windows Vista or Windows 7 and should not be used on these versions of Windows. The underlying installation technology for OS components is completely new in Windows Vista, so install/repair techniques for Windows XP OS components will not continue to work on Windows Vista and higher. Also, some of the registration utilities that shipped with previous versions of Media Center are not included in Windows Vista or higher because they are no longer needed.
Windows Vista and Windows 7 Media Center files and registry information are protected by Windows Resource Protection (WRP) in Windows Vista. This means that only the OS installer service (named TrustedInstaller) has permission to modify/remove these files or registry keys unless you specifically take ownership of the files/keys and add additional user accounts to the access permission list (which you should not need to do except in extraordinary circumstances).
If you run into problems while using Windows Vista or Windows 7 Media Center and you suspect that files or registry entries that are a part of the Media Center feature are corrupt, you can use the instructions listed below to attempt to repair them.
Repairing Windows Vista and Windows 7 Media Center files
You can use the following steps to repair the files that are a part of Windows Vista Media Center:
Disabling and re-enabling Windows 7 Media Center
You can use the following steps to disable and re-enable Windows Media Center on Windows 7. These steps do not apply to Windows Vista.
Repairing Windows Vista and Windows 7 Media Center registry entries
Unfortunately, there is not an easy way of repairing the registry keys/values that are installed by Windows Vista and higher like there is for files. If you want to try to repair the registry keys/values that are a part of Windows Vista and Windows 7 Media Center, you will need to run Windows setup again and repair the OS.
<update date="10/7/2008"> Added a link to a knowledge base article about SFC and how to find errors that it reports during its repair process. </update>
<update date="8/17/2009"> Fixed broken link to knowledge base article. </update>
<update date="2/24/2011"> Added a note about how to disable and re-enable Windows Media Center on Windows 7. </update>
<update date="2/25/2011"> Updated the note I added yesterday to also include Windows Media Player. </update>
I recently installed Windows Vista. When I looked in the Programs and Features (formerly known as Add/Remove Programs) control panel, I didn't see the .NET Framework 2.0 listed. Therefore I decided to install the .NET Framework 2.0 by downloading it from this location. However, running that setup displays an error message stating that it cannot be installed because it is already a part of the OS. Why does this happen?
Over the past few months, I've received several variations on this question for other operating systems and all of the released versions of the .NET Framework. When the .NET Framework is installed as a part of the OS, it does not appear in the Programs and Features (or Add/Remove Programs) control panel. The following is a complete list of which version of the .NET Framework is included in which version of the OS:
Note - for the .NET Framework 2.0, 3.0 and 3.5, you can see a graphical view of the above information in this blog post.
In addition, the .NET Framework shipped with the following versions of Windows but not as truly integrated OS components:
You can see a table of what version numbers are associated with each version of the .NET Framework in this blog post.
<update date="3/27/2008"> Added a note that the .NET Framework 1.1 is not included in 64-bit versions of Windows Server 2003. Added information about Windows Server 2008. </update>
<update date="7/29/2008"> Added a note about Windows XP SP3. </update>
<update date="8/14/2008"> Added a note about Vista SP1 and the .NET Framework 2.0 SP1 and 3.0 SP1 </update>
<update date="1/12/2009"> Added a note about the .NET Framework 1.0 SP3 for Windows XP Media Center and Tablet PC editions. </update>
<update date="4/1/2009"> Added a note about the .NET Framework versions available on Windows 7 </update>
<update date="8/26/2009"> Added a note about Windows Server 2008 SP2. </update>
<update date="8/29/2009"> Added a note about Windows Server 2008 R2. </update>
<update date="2/5/2010"> Added a link to a blog post with a graphical view of the versions of Windows that include the .NET Framework 2.0, 3.0 and 3.5. </update>
<update date="4/27/2010"> Added a link to a blog post with a list of the exact version numbers for each .NET Framework version and service pack level. </update>
<update date="9/8/2012"> Added a note about Windows 8. </update>
<update date="11/18/2013"> Added a note about Windows 8.1. </update>
<update date="3/5/2014"> Added a note about Windows Server 2012. </update>
I have a system with Windows Vista and have been using Media Center to watch DRM-protected content for a while. Recently, I upgraded some hardware on my system, and now I can no longer view any DRM-protected content in Media Center. After some web searches, I found one of your old blog posts that describes a similar type of error message in Update Rollup 2 for Windows XP Media Center Edition 2005. However, that post and the knowledge base article it refers to appear to be specific to older versions of Windows.
I have read that some types of hardware upgrades can cause DRM to stop working in Windows, and I suspect that is what is happening to me. How can I reset DRM on my system so that I can view protected content inside of Windows Vista Media Center again?
The knowledge base article linked in that old blog post (located at http://support.microsoft.com/?kbid=891664) contains information that is applicable to Windows Vista as well as older versions of Windows, but it does not specifically state that it applies to Windows Vista.
According to this knowledge base article, you can reset DRM by deleting the files in the DRM folder on your system (but make sure to not delete the DRM folder itself because that can cause other problems on your system).
The default location of the DRM folder in Windows Vista is c:\ProgramData\Microsoft\Windows\DRM, but it might not be in the same location on every system. To reliably determine the location of the DRM folder on your system, you can look up the data in one of the following registry values:
For 32-bit versions of Windows Vista:
For 64-bit versions of Windows Vista:
Note - the DataPath value is in binary format, so you will have to double-click on the DataPath value in regedit.exe and look at the right-hand column of the Edit Binary Value dialog box that appears to see the plain text version of the path.
As described in this blog post, a set of custom actions was added to the WiX toolset last year to make it easy to create native images for managed assemblies in an MSI-based setup using the .NET Framework 2.0 version of NGEN.exe. Native images are created to improve the performance of managed applications, and some of the details about the benefits they provide can be found in this MSDN Magazine article.
Prior to these WiX custom actions, it was relatively difficult and error prone to add NGEN to an MSI-based setup, but it is simple and straightforward now. I wanted to demonstrate just how easy it is to use the WiX NGEN custom actions to encourage setup developers to use WiX and the NGEN custom actions for managed assemblies.
For this demonstratation, I'm going to modify the sample WiX files for the Q sample application that is shipped in the Windows Media Center SDK for Windows Vista. I'm going to use the WiX v3.0 files that I introduced in this blog post as the basis for adding NGEN functionality. Please note that the NGEN custom actions exist in both WiX v2.0 and WiX v3.0 so you are not limited to using WiX v3.0 in this scenario even though that is what I chose to demonstrate.
How to add NGEN custom actions to a WiX-based setup project
At a high level, you must make the following changes to your WiX project in order to add NGEN custom actions to an MSI built with WiX:
WiX NativeImage configuration options
I created an updated set of WiX source files that include custom actions to run NGEN for Q.dll and Interop.Microsoft.Feeds.Interop.dll, and you can download them from this location - http://play.mediacentersandbox.com/tools/qsetup_wixv3_with_ngen.zip.
This example includes only 32-bit NGEN, so you will need to update the Platform attribute if you want to create a 64-bit installer. Also, this example performs synchronous NGEN by setting the Priority attribute to 1. This will cause setup to wait for each native image to be generated before continuing with installation. It is possible to change the Priority value to 3 to schedule an NGEN action to occur in the background using the NGEN service after setup completes. This will speed up installation performance, but the native images will be compiled at some later point by the NGEN service on the system, which means that the native images may not be present the first time a user launches your application after installing it.
You can find full documentation about the attributes that can be set for NativeImage elements in the WiX documentation (wix.chm that is installed as part of the WiX toolset) or by using IntelliSense within the Visual Studio IDE after installing the WiX toolset.
The steps below will allow you to create an MSI for the Q sample application that includes NGEN functionality for the managed assemblies that are installed as a part of Q setup.
Building an MSI for Q that contains NGEN functionality by calling WiX tools directly
The above steps will produce an MSI named Q_Podcast_Client.msi that includes NGEN custom actions in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q\bin\release (or \bin\debug\ for the Debug version of the Q application).
Building an MSI for Q that contains NGEN functionality using Votive
The following steps can be used to build an MSI for the Q sample application directly from Visual Studio 2005 using the Votive WiX add-in:
The above steps will produce an MSI named Q_Podcast_Client.msi that includes NGEN custom actions in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q\QWiXv3\bin\release (or \bin\debug\ for the Debug version of the Q application).
Back in January, I wrote a blog post with links to information about the multi-lingual user interface features available in Windows Vista. Since then, some additional information has been published about developing world-wide applications for Windows Vista, and I wanted to post those links as well:
I encourage you to take a look at the information in the above links if you are developing applications for Windows Vista. Even if you are not specifically targeting Windows Vista, I encourage you to keep global development in mind while designing and building Windows applications.
Recently, I've come across a few blog posts announcing new Windows Vista Media Center applications. All of the applications below are written in Media Center Markup Language (MCML), and it is exciting to see the new Media Center platform features in Windows Vista start to gain some momentum. I wanted to post links here so you can take a look if you're interested in learning more. Also, if you're interested in getting started creating your own Media Center application, I encourage you to check out the Windows Media Center SDK for Windows Vista.
I found a post on Ian Dixon's blog with links and screenshots for MCEMailbox. This application is written in MCML for Windows Vista Media Center that allows users to check POP3 and secure POP3 email boxes, and be notified inside of Media Center when new mail arrives. Here are some links to more information about MCEMailbox:
Anthony Park, the developer of MCEMailbox (and also the developer of MCEBrowser) is scheduled to appear on an upcoming episode of the Media Center Show, so make sure to keep an eye out for that.
Steven Harding posted the following blog post about a week ago: http://thedigitallifestyle.com/cs/blogs/developer/archive/2007/03/06/just-to-prove-i-m-not-completely-full-of-it.aspx. In it, he introduces an alpha version of a Multi Arcade Machine Emulator (MAME) application for Windows Vista Media Center that he has been working on.
The application, named MAMECenter, is written in Media Center Markup Langauge (MCML), and a downloadable MSI and some screenshots are available via the blog post. I tried it out on my system and the UI launched but a list of games never appeared. However, this appears to be because I don't have any ROMs downloaded to the folder that the MAME application is looking for them at. I've also heard from a couple of other people who tried it out and were able to successfully use it within Media Center.
Domia has been working on a new Media Center interface in MCML for their Harmony home automation software. They have posted a video of a beta version of Harmony 2007 in the blog post at http://www.domia.eu/blog/PermaLink,guid,2752d05b-0f02-4b8b-a75b-a0cfeec5f176.aspx. The beta program for this application is already closed because of the large number of subscribers, but the video is really impressive so hopefully there will be a future version that is available for more folks to try out.
<update date="3/18/2007"> Updated the information about MAMECenter. After talking to Steven Harding, I realized I didn't know enough about how the MAME application actually worked behind the scenes. The reason I wasn't seeing any ROMs in MAMECenter inside of Media Center is that I needed to manually download some ROMs and copy them to the MAME folder on my system. </update>
I noticed this afternoon that the final release of the Visual Studio 2005 SP1 update for Windows Vista has been released on the Microsoft Download Center. You can find more information at these locations:
If you had the beta version of the SP1 update for Windows Vista, you will need to remove it first. You will also need to make sure that you have install VS 2005 SP1 on your Windows Vista before installing this SP1 update package.
One other note - installing this SP1 update will finally cause all of the compatibility dialogs that I previously blogged about (here and here) to go away on Windows Vista.
A little while back, I wrote a blog post describing an interaction issue between Visual Studio setup and the Tenebril SpyCatcher application. Since then, I have heard from multiple customers who have experienced problems installing the .NET Framework that they have traced back to this same application. As a result, I wanted to post a separate item that is specific to .NET Framework setup in the hopes that it will start appearing in web searches.
If you run into an issue where the .NET Framework setup (1.0, 1.1 or 2.0) hangs while registering System.EnterpriseServices.dll, you could be running into an interaction caused by an over-aggressive anti-spyware application named Tenebril SpyCatcher. If this happens to you and you have this application installed, I suggest trying the following steps:
It is important to note that in the cases I've seen so far, closing or disabling Tenebril SpyCatcher is not enough to resolve this issue. The customers I have talked to have had to fully uninstall Tenebril SpyCatcher in order to get the .NET Framework to install successfully.
Please note also that there are several root causes of .NET Framework setup failures that occur while registering System.EnterpriseServices.dll. If you do not have Tenebril SpyCatcher on your system, then this workaround will not help. One of these other workarounds might help though, so I encourage you to look at them as well:
Yesterday, Ian Dixon posted his 100th episode of the Media Center Show. You can view a summary transcript and download the episode from this blog post - http://iandixon.spaces.live.com/blog/cns!36983156CAA83EA9!1909.entry. Ian's guest on this episode is Charlie Owen, and they spend some time talking about Media Center applications and developer tools.
I also wanted to congratulate Ian on this milestone. As he outlines in this blog post, a lot has happened since he started using and blogging about Media Center. I've had the honor of being on his show twice now, and had a great time talking to him about various aspects of using and developing applications for Media Center.
Here's to 100 more....
I am trying to create a script that will install Visual Studio 2005 SP1 in silent mode. I haven't been able to find any official documentation about supported command line switches, so I downloaded the SP1 setup package and ran it with the /? switch to view the usage information. Doing that displayed a dialog with the following information:
The following options are provided in addition to the existing Windows(R) Installer command line options. For Windows Installer command line options, run "msiexec /help" to learn details. <update executable file name> [/Option] [Optional Parameter]Options </help | /h | /?> Display this usage dialog box. </extract> [<directory>][/q | /quiet] Extract the .msp package to the specified directory. </uninstall> Uninstall the patch from all applicable products. Consult Windows Installer SDK for additional documentation on the command line syntax: http://msdn.microsoft.com/library/
The following options are provided in addition to the existing Windows(R) Installer command line options. For Windows Installer command line options, run "msiexec /help" to learn details.
<update executable file name> [/Option] [Optional Parameter]Options </help | /h | /?> Display this usage dialog box. </extract> [<directory>][/q | /quiet] Extract the .msp package to the specified directory. </uninstall> Uninstall the patch from all applicable products.
Consult Windows Installer SDK for additional documentation on the command line syntax: http://msdn.microsoft.com/library/
I see a quiet switch listed here, but it appears to be an optional parameter associated with the extract switch. How can I perform a silent install of Visual Studio 2005 SP1?
The information in this usage dialog is a little bit misleading. Visual Studio 2005 SP1 (and all Visual Studio and .NET Framework update packages) support installing in silent mode by passing in the /q or /quiet flag. That flag is not only applicable for extraction. It can be used for installation, extraction or uninstallation, depending on what combination of other switches is passed in along with /q or /quiet.
Note: there is also a documented list of command line switches for Windows update packages at http://support.microsoft.com/kb/262841. Visual Studio update packages do not use the same installation wrapper, but it does support some of the same switches in an effort to offer a consistent update deployment experience.
I've received a few questions recently about how to programmatically detect whether or not the .NET Framework 3.0 is installed on a system. As a result, I decided to update the sample code I previously published (here and here) to include logic to detect the .NET Framework 3.0 in addition to the previous logic for .NET 1.0, 1.1 and 2.0.
Where to download the sample code
You can find the updated sample code at the following locations:
Detection logic used in the sample code
The new code that I added to the above samples to check for the presence of the .NET Framework 3.0 searches for the following registry value (as described in the .NET Framework 3.0 deployment guide):
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]InstallSuccess=1
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]InstallSuccess=1
Detecting pre-release builds of the .NET Framework 3.0
However, we have seen some false positives if an application only searches for this registry value because this value is set in pre-release builds of the .NET Framework 3.0 in addition to the final release version. In order to narrow down the detection even further and exclude pre-release builds, I added logic to the sample code that also looks at the following registry value:
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]Version
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]Version
This Version value contains REG_SZ data that represents a 4-part version string of the form #.#.#####.##. The final release version of the .NET Framework 3.0 contains the following version value:
The updated sample code contains a function named CheckNetfx30BuildNumber that contains the following logic:
This additional version validation is not "officially" documented anywhere, but is useful to provide a safeguard if you would like to prevent your application from installing on a system that has a pre-release build of the .NET Framework 3.0 installed.
As always, please let me know if you have any trouble building or running these samples or incorporating them into your product setup logic.
The March 2007 edition of MSDN Magazine contains an in-depth article describing how to use WiX v2.0 and MSBuild to integrate setup into the overall software development lifecycle. You can find the article at this location:
This MSDN Magazine article is a nice complement to an older MSDN article that Rob Mensching wrote about how to use WiX to integrate setup into your development process. The main differences are that Rob's article describes how to use NMAKE instead of MSBuild to automate the WiX build process, and Rob spends more time describing the importance of treating setup the same as other source code for a software project.
If you are a setup developer or a developer on a team that produces MSI-based setup packages to deploy your code, I encourage you to take a look at both of these articles.
One additional note that I wanted to mention here - WiX 3.0 has much more seamless MSBuild integration than what is described in this MSDN Magazine article courtesy of the Votive Visual Studio add-in. I previously posted an article describing how to use Votive and WiX v3.0 and Votive to create MSI-based installers for Windows Media Center applicaitons, and the concepts described there can be adapted to all types of MSI-based installers with minimal effort.
As Niall and Ian noted in their blogs earlier this week, there is a new Windows Vista Media Center application available in the Explore tile of the Online Media strip (the area known as Online Spotlight in previous versions of Media Center).
This application is built using Media Center Markup Language (MCML) and is a locally installed application (as opposed to a Media Center Presentation Layer web application). This means that you have to download an installer and run it on your system before you can start using this application. Also, the application is only available on systems in the United States.
Here are a couple of links to more detailed information about this application if you are interested in learning more about it:
Heath Stewart recently wrote a blog post at http://blogs.msdn.com/heaths/archive/2007/03/14/introducing-windows-installer-powershell-extensions.aspx that introduces a new project that he published on CodePlex - the Windows Installer PowerShell Extensions (also known as PSMSI) project.
The initial version of this project, located at http://www.codeplex.com/psmsi, contains cmdlets that can be used within PowerShell to query product and patch information for installed MSI-based products. I've talked to Heath about this project, and his longer term vision includes many additional cmdlets so that these extensions can be used for a variety of Windows Installer troubleshooting tasks.
If you use PowerShell at all and/or are involved in setup development or troubleshooting, I encourage you to take a look at this project to see if you can use these extensions (and possibly contribute to enhancing them as well).
The online MSDN documentation library has introduced a feature called MSDN Community Content. This feature provides the ability for anyone in the community to contribute to the content by providing supplemental information, correcting inaccurate or confusing steps, etc. It is intended to be used in a way similar to traditional Wiki pages.
The English version of MSDN has supported Community Content for a little while. In the past week or so, the Chinese (Traditional), French, Italian, Japanese and Korean versions of MSDN Community Content have also gone public.
Here are the links to all versions of MSDN that have Community Content enabled so far:
If you are reading MSDN documentation in the future and have additional information to add, I encourage you to do so by using the Community Content section that appears at the bottom of many of the topics.
Charlie Owen has posted an in-depth article over on the Media Center Sandbox site that I wanted to provide a link to here:
This article describes techniques for using the Media Center Markup Language Preview Tool (also known as McmlPad) during the MCML UI development process. He discusses some of the key differences between how the standalone version of McmlPad behaves versus how the Media Center application host behaves (specifically - UI rendering, layout evaluation and page variables).
In addition, he uses the Z sample application to provide a nice example about how to create a UI test harness for an MCML application and configure settings in Visual Studio 2005 projects so they will launch McmlPad when pressing F5 in the Visual Studio IDE.
If you are developing a Windows Vista Media Center application using MCML, I encourage you to take a look at this article and download and try out the sample test harness Visual Studio project.
I am building a Windows Media Center application for Windows Vista using Media Center Markup Language (MCML). My application performs some initialization tasks that are somewhat time intensive, so I would like to display a page with a loading animation so the user will know that something is happening behind the scenes. Once the application initialization is complete, I would like to navigate to the main page for my application.
Is it possible to architect my MCML application so that it has a loading page to give the user a sense of progress, then navigates to a new page when loading is complete? Also, is it possible to prevent Media Center from showing the loading page if the user presses back from the main application page?
The HistoryOrientedPageSession class is derived from the PageSession class. The PageSession class contains a LoadPage method that can be used to display a page that will not be added to the Media Center back stack. The LoadPage method is protected, so you cannot instantiate a HistoryOrientedPageSession object and call LoadPage directly.
However, you can create a sub-class of HistoryOrientedPageSession and then call LoadPage from your sub-class. This will allow your application to navigate to a page that will not appear on the back stack and then transition to another page that will appear on the back stack.
In addition, you can create a property in your application code and fire a property change event when your application initialization is complete. Then you can add a Rule to your MCML page that listens for this property change event and navigates to the main page of your application.
The Q podcast application included as a sample in the Windows Media Center SDK for Windows Vista demonstrates how to implement all of the above logic. It contains a loading page that does not re-appear when the user presses back within Media Center, and it fires a property change event and uses a rule to navigate to the main application page after loading is complete.
If you have the Media Center SDK installed to the default path, you can take a look at the following files to look at the exact implementation details:
It is important to note that the algorithm described above only works for locally installed MCML applications. Windows Media Center web applications do not have any locally installed code, so it is not possible to sub-class HistoryOrientedPageSession and fire property changes as described above.
It is possible to dynamically change the Source property on a Host view item in your markup file (similar to what is demonstrated in the AdvancedMarkup.HostViewItem.mcml sample in McmlSampler in the SDK) to create a loading page in an MCML web application that will navigate to the main page of the application. However, doing this will cause the loading page to be placed on the back stack. This means that the loading page will re-appear when pressing back after your application navigates to the main page.
Niall Ginsbourg posted an item on his blog this weekend describing a new Media Center Markup Language (MCML) application for Windows Vista Media Center that was unveiled recently at the Cebit 2007 conference - Media Center Cutter.
Olcay Buyan, a developer from MCEDev.com, has been working on this application, which allows you to edit DVR-MS files directly within Windows Vista Media Center using a storyboard-style visual editor. In addition, Media Center Cutter includes several features that are above and beyond standard video editing functionality (from the list on Niall's blog post):
You can check out more information about Media Center Cutter, including some example screenshots, in Niall's blog post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!340.entry. Hopefully there will be a downloadable version of this tool available in the near future for folks to try out.
I previously posted a set of instructions for creating an administrative install point for the .NET Framework 2.0 using the install.exe external UI handler. I recently heard from a customer who attempted to use these instructions on Windows Vista and received an error message stating "This product is already installed as part of the operating system."
I looked into this in more detail and found that some of the prerequisite conditions in the external UI handler are being evaluated in administrator mode and incorrectly blocking this scenario on Windows Vista. The .NET Framework 2.0 MSI-based setup does not allow installing on Windows Vista because the .NET Framework 2.0 is a part of the OS on Windows Vista. However, you should be able to create an administrative install point on Windows Vista as long as you plan to only install from that install point on other operating systems.
Here are an updated set of instructions that will allow you to create an administrative install point for the .NET Framework 2.0 on any operating system that has Windows Installer 2.0 or later installed:
Note - the <path> value in the command above should be set to the exact path that you want to stage the administrative install point to.
I recently heard from a customer who was running into a Visual Studio Common IDE Package load failure error in Visual Studio 2005. They tried all of the steps listed in my blog post about how to resolve package load failures caused by previous beta versions of Visual Studio 2005 but did not have any luck. The customer reported that they found a solution to this problem in the following 2 posts on the MSDN Forums:
I took a look back at the setup for a few of the beta versions of Visual Studio 2005 and the data files for the cleanup tool that I posted in my blog post and found that there were a couple of problematic registry values that the cleanup tool did not remove. I wanted to post instructions describing how to manually remove these problematic registry values in case anyone else runs into a similar issue:
Note: if running the above steps on Windows Vista, you will need to use an elevated cmd prompt. You can open an elevated cmd prompt on Windows Vista by clicking on the Start menu, choosing All Programs, then Accessories, then right-clicking on the Command Prompt item and choosing Run as administrator.
I have also updated the version of the Visual Studio 2005 beta cleanup tool on my file server to include steps to remove the above registry values as well.
Please note that the above issue only affects systems that previously had a beta version of VS 2005 installed. The registry values listed above are not created by the final version of VS 2005, so unless a beta version was installed at some point in the past, there is no way for those registry values to be created on your system.
I recently found an article on MSDN written by James Lau, a program manager who works on the core Visual Studio IDE. The article lists some cool tips and tricks that are not as widely known that can help boost developer productivity in the Visual Studio IDE.
You can check out the article on MSDN at http://msdn2.microsoft.com/en-us/library/bb245788(vs.80).aspx. It includes the following topics:
Even if you've used Visual Studio 2005 extensively, I'd suggest taking a look at the article to see if there is anything useful for your scenarios. I found a couple of tips in there when I read the article this past weekend that I've already started using to improve my own productivity.
I have previously posted a few items about deploying the Visual C++ 8.0 runtime redistributable packages as a prerequisite for other setup packages:
Since then, I have started to get more in-depth questions about how the Visual Studio 2005 SP1 version of the VC runtime files affects application building and deployment. Most of these questions have been specific to how the VC runtime files themselves manage forward and backwards compatiblity and I don't have very much knowledge about how this works behind the scenes.
Fortunately, Nikola Dudar, a program manager on the VC team, recently sent me some really helpful links with more information about how Visual Studio 2005 SP1 impacts application development and deplopyment scenarios when the application in question depends on the VC runtime files. If you are a developer building and deploying applications that use the VC 8.0 runtime files, and you are evaluating Visual Studio 2005 SP1 for your development environment, I strongly encourage you to review the content in both of these links in order to better understand the ramifications of putting SP1 on your build machine:
A long time ago (January 2005 to be exact), I wrote a blog post describing a Windows Installer resiliency repair scenario that we used to see in some old daily builds of Visual Studio 2005. In that post, I recommended not using the Class or ProgId tables for COM registration and instead using Registry table authoring. However, I had a hard time defending that recommendation because I didn't have a lot of knowledge about those tables at the time.
Yesterday, I noticed that Rob Mensching posted a really nice explanation on his blog (including example MSIs) to demonstrate interaction issues and resiliency repairs that can be triggered by advertising COM information in an MSI using the Class and ProgId tables.
I personally agree with Rob's recommendation, but I also understand there are certain scenarios where it might make sense for a setup developer to do this. I strongly encourage anyone using or thinking of using COM advertisement in an MSI via the Class and ProgId tables to read Rob's blog post in order to get a better understanding of the ramifications of doing this and then weigh the trade-offs of these setup design options.
I noticed a post on the Big Screen Blog over the past weekend about a beta version of a new Windows Vista Media Center application that is now available for download. The application is an updated version of MCStart, a program that can be used to browse events and attractions that has previously been available as an HTML application for Windows XP Media Center Edition 2005. The Windows Vista version is written in Media Center Markup Language (MCML) and is a web application. You can find more information about this application at the following locations:
I downloaded the installer and took a look, and it is built using WiX v2.0. Also, it appears to be modeled after the sample setup packages for the Q and Z applicatoins that are included in the Windows Media Center SDK for Windows Vista. I'm happy to see that folks are finding these samples useful.
Another interesting thing I noticed about the installer is that because it is a MCML web application, the XML registration file included in the installer contains the URL to the application. This allows you to be able to try out the application without installing it by using McmlPad (if you have the Windows Vista Media Center SDK installed). To do that, simply browse to the URL http://www.mcstart.nl/vista/index.php.
Note that there is some functionality that will not work within McmlPad. Specifically, there is a button that appears to allow you to return to Media Center (but I am not sure because I don't speak Dutch). However, clicking on that button causes McmlPad to crash because McmlPad does not instantiate a page stack for the application like Media Center does when you directly register and launch the application.
Finally, I wanted to mention something about this application that is probably only interesting to setup developers. The setup UI is built using the WiX UI dialog sets, and it is translated entirely into Dutch. WiX v2.0 contains full translations of the setup UI dialog sets in English, German, Spanish, Hungarian and Dutch, which makes it easy to create non-English MSI-based setup packages in these languages. You simply need to pass in the WXL file for the language you would like to use to light.exe using the -loc command line parameter when you link your MSI. You can look at the build scripts named build_q.bat or build_z.bat in the Windows Vista Media Center SDK for example syntax for English and make corresponding changes to create MSIs with setup UI in these non-English languages.