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 heard from a customer this week who indicated they were seeing all of the following errors that I have described in previous blog posts:
I wanted to outline the exact steps I took to investigate this user's computer because they are very often useful in resolving this type of error. Hopefully, if other folks run into this type of error within Media Center, they will be able to find this blog post and be able to more easily fix the error themselves.
The errors listed above are normally caused by a Media Center service not being correctly registered on the system. Service registration happens at the end of Media Center update rollup or hotfix setup, and most cases I have seen of this error can be traced back to something failing during the installation of the most recent Media Center hotfix.
The most useful log file for Media Center hotfixes is named %windir%\medctroc.log. In this type of scenario, I always start my investigation by opening up that log file, scrolling to the bottom and looking for any errors or warnings, especially errors related to service installation.
In general, the sessions in that log file come in pairs - an un-registration mode that is denoted by the log string Will run in unregister mode and a registration mode that is denoted by the log string Will run in registration mode. The service un-registration and re-registration command lines appear under the heading Registering services and COM objects... in the log file.
In most cases one or more of the following warnings or errors will appear:
In cases where I see any of the above error messages in %windir%\medctroc.log, I use the following set of steps in the order listed below to manually un-register and re-register Media Center services:
The command lines above are case-sensitive, so make sure to capitalize the S in unregServer exactly as listed above. Also, it is not sufficient to simply re-register the services because these services have logic in the code that treats the /service switch as a toggle (meaning that if it is un-registered, it will re-register it, but if it is already registered, it will un-register it).
In a few cases, running the above steps will result in the same error messages when launching Media Center and will show the same log messages in %windir%\medctroc.log. I have seen the following steps help resolve these errors in this scenario if the above commands did not help:
<update date="2/19/2006"> Added additional steps to uninstall and reinstall the most recent Media Center update rollup because I have heard from a couple of customers who tried all of the above command lines and none of them helped, but uninstalling and reinstalling did end up solving the issue for them </update>
You previously posted a set of instructions that can be used to run the .NET Framework 2.0 setup by calling the MSI directly. The instructions in that post describe a command line parameter named ADDEPLOY that needs to be passed to msiexec.exe to allow the MSI to install correctly.
I want to deploy the .NET Framework 2.0 in my network using Group Policy. I cannot specify a command line parameter like ADDEPLOY in the Group Policy deployment package creation UI. How can I deploy the .NET Framework 2.0 MSI on my network using Group Policy?
The following example steps can be used to create a Group Policy object to deploy the .NET Framework 2.0 in a network:
It is important to note that the .NET Framework 2.0 only supports deployment by machine assignment, not by user publishing. This is because the user may not be an administrator on the machine in the advertised scenario, and because the .NET Framework is a per-machine and not a per-user application.
Behind the scenes, the .NET Framework 2.0 MSI has a custom action named CA_BlockDirectInstall_GUIH_SKU_URT that is used to prevent users from installing by double-clicking on the MSI directly. This custom action has the following complex condition statement in the InstallExecuteSequence table:
( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) )
( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) )
The ADVERTISED property will be automatically set if you create a Group Policy object to deploy the .NET Framework 2.0 MSI to a network by machine assignment.
You have written blog posts in the past describing the command line parameters that can be used to install the .NET Framework in silent or unattended mode (here, here, here and here for example). What are the command line parameters required to perform a silent or unattended uninstall of the .NET Framework?
The following command lines can be used to perform silent uninstall of the .NET Framework redistributable. This is a fully automated uninstall with no visible UI and no user interaction required.
The following command lines can be used to perform unattended uninstall of the .NET Framework redistributable. This is a fully automated uninstall with visible progress UI but no user interaction required.
The following command line can be used to perform silent uninstall of the .NET Framework SDK (the same command line will work for versions 1.0, 1.1 and 2.0):
setup.exe /q:a /c:"install.exe /u /q"
setup.exe /q:a /c:"install.exe /u /q"
The following command line can be used to perform unattended uninstall of the .NET Framework SDK 1.1 and 2.0 (unattended mode was not supported in 1.0):
setup.exe /q:a /c:"install.exe /u /qb"
setup.exe /q:a /c:"install.exe /u /qb"
I wanted to list a few miscellaneous issues that have been found recently with Update Rollup 2 for Media Center 2005 and describe how to workaround them. Some of these have already been described individually elsewhere, but I wanted to make it more likely that they are found in search engines by posting them again.
1. DVB radio tuning causes a blue No TV Signal overlay
Peter Rosser described this issue and workaround in more detail in this blog post. He lists the registry value that needs to be changed to workaround this problem until it is released in a future Media Center rollup package. As a convenience, here is a command line that you can run to update this registry value do you do not have to use regedit:
Note: You can copy and paste this command into the cmd prompt by highlighting it in this blog post, pressing Ctrl + C, then right-clicking on the cmd prompt window and choosing Paste. Make sure that you copy the entire command as it is listed above, including the space between Media and Center, and do not add any extra carriage returns in the middle of the command line or it will not work correctly.
2. High-definition (ATSC) tuners stop working after uninstalling Update Rollup 2
Peter Rosser also described this issue in his blog, and you can find more information in this post. Here is a set of steps that will delete the registry value that is needed to restore ATSC tuner functionality if you uninstall Update Rollup 2:
Note: Like in the issue described above, you can copy and paste this command into the cmd prompt by highlighting it in this blog post, pressing Ctrl + C, then right-clicking on the cmd prompt window and choosing Paste. Make sure that you copy the entire command as it is listed above, including the space between Media and Center, and do not add any extra carriage returns in the middle of the command line or it will not work correctly.
3. Media Center will not correctly enter standby mode if the TV tuner was used prior to going into standby
This is a recently discovered regression introduced in Update Rollup 2 that we are currently working on a fix for. Once a fix is ready, it will likely be included in the next Media Center hotfix rollup package. The only known workaround at this time is to disable Media Center sounds by navigating to Settings | General | Visual and Sound Effects and unchecking the box labeled Play sounds while navigating Media Center.
4. ATSC minor channels are listed incorrectly in the Media Center television guide
Peter Rosser described this issue in his blog in this post. This is a known issue that will be fixed in the next hotfix rollup for Media Center 2005, but unfortunately there is not a way to workaround this issue in the meantime.
I have gotten several comments in blog posts and emails from customers who have been running into error code 13 while trying to download television guide data in Media Center. As a result, I decided to create an article that can serve as a central repository of all currently known information and suggested workarounds for this error. You can find the new article that I created at this location.
Unfortunately, this list of suggestions is all that I currently know of to try to troubleshoot this type of failure, and the log files that I have previously requested in earlier blog posts have not been helpful in identifying additional root causes. As our team discovers new issues and workarounds, I will add them to the article. I apologize for the inconvenience that this issue is causing you if you are running into it :-(
Given the number of people that I have heard from who have been having trouble getting guide download functionality to work correctly with their ISP (particularly the Direcway satellite internet provider), I thought it might be useful to post some steps that can be used to transfer downloaded guide data from one Media Center PC to another.
First, you will need to copy all of the values from the following registry hive from a machine that has downloaded guide data to the one you want to transfer it to:
This only needs to be done once, and can be achieved using the following steps:
Note that the source computer and the destination computer must have the same directory structure and system drive (meaning the OS is installed on the same drive letter and the Documents and Settings and Windows folders are all in the same path on both computers, etc)
After you have performed this one-time transfer of the registry settings listed above, you will need to perform the following additional steps each time you want to transfer the guide data to the destination computer:
Note that you will need to repeat this second set of steps at least once every 2 weeks if you want to continue to have valid guide data on the destination computer.
A few weeks ago, I started working on a sample Media Center add-in using the test builds of the February CTP version of the Media Center SDK. During this process, I needed to figure out how to create a project in Visual Studio 2005 that could build Win32 resources and include them as part of a managed assembly.
I struggled for a while as I looked through the documentation for Visual Studio 2005 and tried different scenarios. Eventaully I asked a friend of mine who works on the MSBuild team and his advice along with a little further experimentation got me to a working solution. Since I struggled for a while with this scenario, I decided to document it here as well in the hopes that it will save some effort on the part of anyone who searches for help about this topic later on.
Here are the steps I followed to add Win32 resources to a managed assembly in Visual Studio 2005.
1. Create a .RC file to represent the resources
If you know the syntax, you can create a .RC file directly in a text editor such as notepad. You can also use Visual C++ and choose Add Resources to create a .RC file, or you can use an example from another application you have already created and modify it in notepad.
2. Compile the .RC file into a .RES file
You can use resource compiler tool (named rc.exe) that is available in %ProgramFiles%\Microsoft Visual Studio 8\VC\Bin if you have Visual Studio 2005 installed to the default location. The command line is rc.exe /r <path to the .RC file>. This will create a .RES file with the same name as the .RC file in the same location as the .RC file.
You can also configure your .csproj file to automatically compile the .RC file into a .RES file as a pre-build task. In order to accomplish this, open the .csproj file in a text editor such as notepad, uncomment the section at the bottom of the .csproj file that includes the BeforeBuild target and author a target similar to the following as a BeforeBuild step:
<Target Name="BeforeBuild" Inputs="my_resource_file.rc" Outputs="my_resource_file.res"> <Exec Command=""C:\Program Files\Microsoft Visual Studio 8\VC\bin\rc.exe" /r my_resource_file.rc" /></Target>
Note that this command line assumes that you have Visual Studio 2005 installed to the default location on your system. You may need to adjust the command line as appropriate based on where rc.exe exists on your system.
If you decide to manually edit your .csproj file, I suggest making a backup copy in case you run into syntax errors and need to revert to a known-good copy and start over.
3. Build your managed assembly with a reference to the .RES file included
You can associate a .RES file to a Visual C# project in Visual Studio 2005 by right-clicking on the project in the Solution Explorer, choosing the Application tab, clicking the Resource File radio button and then specifying the .RES file in the text box. The .RES file must already exist in order to specify it in the Visual Studio UI.
Alternatively, you can open your .csproj file in a text editor such as notepad and add the following line to the <PropertyGroup> section at the top of the file:
Visual Studio will pass the file listed in the <Win32Resource> tag to the C# compiler (csc.exe) using the /win32res:<file> command line parameter if it finds that tag in your .csproj file.
Media Center-specific side notes if you're interested:
We have found another possible root cause of Digital Audio Service overlays in Update Rollup 2 for Windows XP Media Center Edition 2005. There are tuners manufactured by AVerMedia that are being shipped with certain types of Media Center systems that we are able to consistently reproduce Digital Audio Service errors with in our test lab.
The Media Center systems we have seen so far that ship this brand of tuner are built by Shuttle but there may be others. Unfortunately, this appears to be a driver issue with this particular tuner, and we are working with the manufacturers currently to try to help them resolve this issue and provide updated drivers. In the meantime, the only workarounds that we know of are to uninstall Update Rollup 2 or to use an alternate program such as Windows Media Player to playback your recorded TV content.
Note - if you are seeing Digital Audio Service overlays and your system does not have an AVerMedia tuner, you can find other Digital Audio Service troubleshooting suggestions at the following locations:
I ran an MSI inventory tool on my system and it showed an item named Visual Studio.NET Baseline - English installed. I have Visual Studio .NET 2003 installed, but I cannot find this particular item in Add/Remove Programs. What is this item for?
The Visual Studio.NET Baseline product is a small MSI-based setup package that is installed as part of the prerequisites in Visual Studio .NET 2002 and Visual Studio .NET 2003. It appears in the list of prerequisites during VS 2002 and 2003 setup with the name Setup Runtime Files.
This package originally installed files needed to display setup UI when we first started working on VS 2002. Since then, the operating systems that VS will install on contain those files, so the final shipping version of this setup runtime files package installs some system-wide debugger components. The same debugger components are included in the main vs_setup.msi, but we included them in the prerequisites in order to front-load reboots that could be caused by the debugger files being in use on the system.
This package uses the ARPSYSTEMCOMPONENT property to install itself in such a way that it does not create an Add/Remove Programs entry, but it will appear when performing an MSI inventory on a system with VS 2002 or 2003 installed.
I heard from a customer who received an error message while trying to install Visual Studio 2005. The dialog box had the title Document Explorer and the text Unknown error. The customer pressed OK and the dialog did not cause setup to fail. However, the same error appeared again when attempting to launch the VS IDE, and pressing OK caused the IDE to exit and be unusable.
It turns out this error can be caused by a product named Icon Packager being installed on the system. The customer found this MSDN Forum post that described his scenario, and the workaround listed there fixed this error. I wanted to post a link to it on my blog as well to hopefully make it easier for others to find it.
The workaround is to do one of the following:
I noticed a post on Matt Goyer's blog today that I wanted to post here as well to help improve discoverability. Like him, I hear from customers via the contact form on my blog fairly frequently, and one of the common issues I hear is that one of the high-definition (HD or ATSC) channels that has been working correctly suddenly stopped tuning correctly on a user's Media Center.
One of the folks on the TV team explained the underlying cause of most of these issues to me:
Typically the reason this happens is that a broadcaster starts broadcasting on some other frequency, and Media Center no longer receives the signal. Media Center uses a tuning table that is supplied by our metadata provider (which they get directly from the FCC), to know which channels are broadcast on which frequencies.
When broadcasters change frequencies (either because they switch from a test feed to a live production feed or for some other reason), Media Center has no way to know about it unless the FCC knows and updates the database that the metadata provider gets its data from. Media Center does not perform exhaustive channel scanning the way that a TV, or some other TV applications, do.
There is a web page where you can report tuning issues like this - the Electronic Program Guide (EPG) issue submission form. I encourage you to report issues that you see via this form as soon as you find them to help speed up the turnaround time for providing updated guide/channel data for your Media Center system. If you send issues to me, I can try to help, but in most cases the information ends up going into this same submission form.
I am running the Windows Vista December Community Technology Preview, which includes the .NET Framework 2.0 as part of the OS. When I try to install Visual Studio .NET 2003 on this system, setup tries to install the .NET Framework 1.1 even though .NET 2.0 is already there. Why?
Each version of the .NET Framework is designed to co-exist side-by-side with all other versions of the .NET Framework. That means you can have the .NET Framework 1.0, 1.1 and 2.0 on your system at the same time. In addition, each version of Visual Studio is tightly coupled with a specific version of the .NET Framework, and the setup for Visual Studio will always try to install the exact version it is coupled with if it is not already installed on the machine. In this scenario, the system has the .NET Framework 2.0 installed but not 1.0 or 1.1. Visual Studio .NET 2003 is coupled with .NET 1.1, so setup will install it.
After spending some time reading Media Center SDK documentation regarding setup and deployment of Media Center add-ins, I decided to document a simpler way to create add-in setup packages (especially after reading this really scary list of 26 steps to create an MSI for an add-in in Visual Studio).
Although it took longer than I was originally hoping due to other things I've been busy with, I am happy to say that I'm finished with phase one of this project, and as a result I posted an article tonight that describes how to use the WiX toolset to create an MSI-based setup package for a Media Center add-in. You can find the article at this location.
This article includes a link to a sample WiX source file that you can use as a reference and as the basis for creating your own setup package. I encourage you to take a look if you have attempted to deploy a Media Center add-in in the past or are planning on doing so in the future.
I have spent some time looking through currently published Media Center add-ins available at the various add-in repositories on the internet. It appears that the large majority of current add-ins take the form of hosted HTML applications - probably because the Media Center add-in is limited to only be able to display message boxes and cannot display other UI to the user within Media Center.
The example that I outline in this article focuses how to create a setup package for a Media Center add-in as opposed to a hosted HTML application. I will cover an example setup for a hosted HTML application in the near future.
However, the setup for the example add-in described in the article will become much more useful in the Windows Vista version of Media Center because we are introducing the ability to create add-ins using Media Center Presentation Layer, which will allow for full access to the Media Center UI framework. New Vista add-ins that use the Media Center Presentation Layer will be setup in a way that is essentially the same as current Media Center add-ins. So, I think that makes this article a useful read even if you are planning to wait for Vista to start creating and deploying Media Center add-ins.
As always, let me know if you have any comments or questions based on the information in the article.
I stumbled across an interesting item posted a while back by Raymond Chen about the Add/Remove Programs control panel that I wanted to link to here. He describes the algorithm used by the Add/Remove Programs control panel to populate some of the information for each installed application, including estimated size, last used date, frequency of use, etc.
A related article on MSDN describes how Windows Installer will automatically populate some of the registry values used by Add/Remove Programs during installation of an MSI-based setup package. One of the items that is notably absent from the list of entries that Windows Installer populates is the DisplayIcon. This is why you will occasionally see applications in Add/Remove Programs with a completely unrelated icon next to the product name.
The Windows Vista February 2006 community technology preview (CTP) is now available, and with it comes a version of the Media Center SDK that contains tools and samples that you can use to get started developing Media Center add-ins using the new Media Center Presentation Layer and Media Center Markup Language.
You can check out these instructions that will walk you though the end to end process of downloading the Vista February CTP, the Media Center SDK February CTP, and installing and configuring both on your computer so you can start developing Media Center applications using this new technology.
Also, Charlie Owen posted some details and screenshots of the tools and samples that I encourage you to take a look at. Hopefully reading this will get you as excited as I am about the platform enhancements that will be available to developers in Media Center for Windows Vista.
One of the things I noticed when I first started looking into the Media Center SDK to try to build a Media Center add-in was that the SDK includes a file named RegisterMceApp.dll that is designed to be used in MSI-based setup packages that install Media Center add-ins. I also noticed that the core Media Center product includes a file named RegisterMceApp.exe that we tell customers to use to register add-ins. The natural question that came to my mind was - why do we have a DLL and an EXE that appear to do the same thing according to our own documentation.
After talking to the developer who originally wrote RegisterMceApp.dll and looking at the source code, I found that RegisterMceApp.dll is essentially a DLL-based wrapper around the same API calls used in RegisterMceApp.exe. There are 2 key behavioral differences in the DLL:
The interesting thing about these behavioral differences is that they can be handled by using RegisterMceApp.exe and correctly authoring the logic in an MSI setup, which would eliminate the need to have a separate DLL.
To address the first issue, you can author separate custom actions to run RegisterMceApp.exe in per-user mode and in per-machine mode and then condition them to check the ALLUSERS property and run at the appropriate times.
To address the second issue, you can author a custom action to unregister the add-in prior to trying to register it. This gives you the added benefit of being able to correctly fail and roll back your add-in setup if registration fails (which is impossible with the DLL because it always returns a success error code).
Authoring the custom actions in the manner I describe above is relatively straightforward in general, but it doesn't appear to be easy to accomplish in the UI of a Visual Studio setup/deployment project. I am working on an example MSI package using WiX to demonstrate how to create a well-behaving Media Center add-in, and I will be using the strategies that I describe above in that package. Stay tuned for more info....
I previously posted an article describing how to use the tool fsnap.exe to list all files installed in a specific path on a computer. This tool can be useful in many scenarios, such as locating orphaned files left behind by Visual Studio 2005 beta build.
Frank Dzaebel posted a comment on one of my blog posts this morning with a pointer to a tool he wrote that provides a graphical user interface front end to make the output generated by fsnap.exe easier to understand and sort. The tool looks pretty nice, and he provides downloadable source code as well. You can check out that tool at this location.
I previously posted a set of instructions that can be used to copy Visual Studio installation CD/DVD media to a local hard drive to try to eliminate 1308 and 1309 errors that can happen while installing Visual Studio.
One of the customers who found that previous post found an additional known issue in the Visual Studio readme with another possible workaround that I had forgotten about when I posted that other blog item, so I wanted to provide a link to it here as well. Ironically, I was the person who investigated that issue when it was originally reported during the VS .NET 2003 beta program, but I forgot to list the workaround as an option in my previous blog post. :-)
Visual Studio setup will show 1308 or 1309 error dialogs in 2 scenarios:
1. When attempting to install from a shared CD-ROM drive.
In this scenario, you have 2 systems - one system with a CD-ROM drive that is shared out and that contains the Visual Studio installation CD, and another system that is connected to the shared drive that you launch setup on.
You can start Visual Studio and start installing, but when setup gets to the point where it needs the first file from CD2, it will show a 1308 error dialog instead of a disk swap request dialog.
In this scenario, you can go to the system where the CD-ROM is physically located, swap CD2 into the CD-ROM drive, and then go back to the system that you are installing Visual Studio on and press retry on the 1308 dialog and setup should proceed normally. You will need to follow this procedure for each disk swap that is needed during the installation process.
2. When attempting to install from a system that has multiple CD-ROM drives where CD1 is in one drive and CD2 is in another drive
In this scenario, you have a single system that has multiple CD-ROM (or DVD-ROM) drives installed, and you are attempting to install in a jukebox-like fashion. Windows Installer has an issue that prevents it from supporting jukebox installations for a multi-CD setup. This issue will appear if you have CD1 in one CD-ROM drive on a system and CD2 in a different CD-ROM on the same system. Instead of showing a disk swap request dialog, it will show a 1308 error dialog.
In this scenario, you can remove CD2 from the other CD-ROM drive, put it into the CD-ROM drive where CD1 is currently located, then press retry on the 1308 dialog nad setup should proceed normally.
By default, an MSI-based setup will appear in Add/Remove Programs when it is installed on a system. The ARPSYSTEMCOMPONENT property can be used to hide the default Add/Remove Programs entry so that you can mark your MSI as a system component or create a separate entry that points to a wrapper setup.exe.
There are several factors to weigh before deciding to use this property in an MSI-based setup. A while back, I linked to a couple of blog posts written by Heath Stewart about design considerations to keep in mind if you decide to use the ARPSYSTEMCOMPONENT property in an MSI-based setup.
I just noticed that Heath has posted a blog article where he links to several additional posts he has written about the ARPSYSTEMCOMPONENT property. He covers topics including reasons for using this property, logistical considerations when implementing a setup that uses it, the dangers of using it, and some implications it has for patching/servicing. I encourage you to check out this article if you are using or thinking of using this property in your MSI-based setup.
I noticed that the .NET Framework 2.0 is being offered on Windows Update the last time I checked for optional updates, so I tried to install it. However, it failed with error code 4113. I found your previous blog post with a list of error codes for the .NET Framework 2.0, and this error code means "Beta components have been detected on the machine that must be uninstalled before installation can proceed."
I did have a previous beta of Visual Basic 2005 Express on my system, but I uninstalled it from Add/Remove Programs and I still get this error code when I try to install the .NET Framework 2.0 from Windows Update. How can I figure out what needs to be uninstalled so I can proceed with installation of .NET 2.0?
Windows Update launches the .NET Framework 2.0 setup in silent mode, which suppresses all setup UI. You can download and run .NET Framework 2.0 setup directly from this link and the setup UI will list the exact beta products that it has detected on your system that need to be removed before installation can proceed.
Alsternatively, there is a log file created during .NET Framework 2.0 setup named %temp%\dd_netfx20ui*.txt (where * is a randomly generated ending). That log file will contain a list of the beta products that need to be uninstalled. Each product will be listed as a separate log string and will contain the phrase BETA CHECK: Found <product name>