I've got a Media Center machine that I have been playing around with at home in order to ramp up on the functionality we offer now that I've joined the Media Center team.  One of the really cool things I've found so far is the ability to remotely schedule TV recordings via the web.  I have a first-series Tivo at home that I've been using since sometime in 2001, and I have found myself at work surfing the web during lunch a few times in the past when I stumble across an article about an interesting-sounding TV show coming up that night that I wish I could record without needing to brave rush hour traffic to get home in time to configure the recording options.

While I was sitting at home last weekend browsing through the Online Spotlight in my Media Center PC I noticed the MSN Remote Record service and decided to try it out.  After installing a small MSI package on my Media Center machine, I was able to navigate to a web site from some other machine and schedule shows to record via a web service.  Not only that, but since I have 2 tuner cards in my Media Center I could remotely schedule 2 shows to record in the same timeslot.  :-)  Some of this isn't too valuable right now since we just went through season finale weeks on the major networks, but I'm seeing more and more interesting new summer shows that are being released, plus there are random documentaries on the History Channel or highlight shows from old NBA Finals series on ESPN that I like to have on in the background while I'm working at home.

Overall, I found the remote record feature pretty easy to configure, but then after setting it all up I found a really good walk through that has been published on the Microsoft Media Center site that makes things even easier.  You can find this article here if you're interested in more information about what the remote record feature is and how to get it up and running on your Media Center machine.

I got a question from a customer asking for direct download locations for each of the VS 2005 Express Edition beta 2 packages.  I replied to that customer with a blog post previously posted by a colleague of mine here.  But as I thought about this question more, I realized that it is probably possible to figure out this information from the publicly available setup packages for the Express Edition beta 2 versions with a little bit of ingenuity and knowledge of setup technologies.  So I decided to try to figure out the download locations myself without using any Microsoft internal web sites or discussion aliases as part of my data gathering.

Here is how I proceeded:

1. Download the setup package for one of the VS 2005 Express Edition beta 2 packages - I randomly choose C# Express.  Instead of choosing the Run button when I clicked the link, I choose to save the package to my desktop so I can pull it apart and look at the contents.
2. Extract the contents of the setup package - when I save the package to my desktop I notice that the icon is a familiar one that normally indicates that the package is an IExpress self-extracting EXE.  So I tried to open the package by using IExpress command line parameters to extract but not run the setup - vcssetup.exe /t:c:\temp /c (I know this syntax because the .NET Framework is an IExpress package and I commonly need to extract the MSI to help customers repair broken .NET Framework installations)
3. Look at the extracted contents - Since there are a bunch of binary and non-binary files in the package, I make an educated guess that there is a generic setup.exe that is used for all Express Editions and there is some kind of data file in the self-extracting package that allows individual products to customize their appearance and/or behavior.  As a result, I started out looking for files that appear to be data files that are used by setup.exe to control the behavior of C# Express setup. 
4. Look for INI files - I find a file named locdata.ini.  Opening that file in notepad shows a bunch of ComponentName values, so this appears to not be very useful for what I'm looking for (side note - in fact this is a list of strings used in setup UI so that setup can be localized).
5. Look for files named setup.* - Doing this takes me to a file named setup.sdb.  When I open this in notepad the results are much more promising.  There is a bunch of information about "dialog pages" and even an item named BootstrapperURL at the top that use the syntax fwlink/?LinkId=#####.  Since I noticed that the link I originally downloaded C# Express from was of the form http://go.microsoft.com/fwlink/?LinkId=##### I decide to try copying the BootstrapperURL and building a full URL using the prefix http://go.microsoft.com/.  When I enter that in my browser and choose Go I get a prompt to download vcssetup.exe again.  So I'm getting closer but I'm not quite there yet.
6. Look deeper into setup.sdb - As I continue to look at the contents of setup.sdb, I find a section named [VS Custom].  I see an entry in there that has the data ComponentFile=baseline.dat.  Previously, I also happened to notice that the setup package I extracted contains a file named baseline.dat, so I decide to look there next.
7. Look at baseline.dat - This file looks like it has a list of components that are part of C# Express setup or are prerequisites that setup does not install but requires to be present on the machine.  Some of the components sections have URL values that use the syntax fwlink/?LinkId=##### just like the BootstrapperURL value in setup.sdb.  I try to use the same trick as above to build a full URL for the item in [gencomp18] and I'm prompted to download dotnetfx.exe.  So I've found the direct download location for the .NET Framework 2.0 beta 2 package!  I build similar URLs for [vs_setup.dll] for the main C# Express installer, [gencomp30] for MSDN Express and [gencomp31] for SQL Express.

The only remaining trick is how to translate from the "fwlink" to the actual location on the Microsoft download center.  Microsoft uses the concept of an "fwlink" (or forwarding link) to provide a public link that can be changed to a new location via some server-side settings later on.  This is useful to allow users or other Microsoft products to link to locations and always have their links point to the most up-to-date versions of documents or products, even after other products have shipped with these links embedded in the product code or documentation.  I have to admit I'm not much of an expert on networking, so the exact method of translating this is left an exercise for the reader  :-)  If anyone has an easy way to do this, please post a comment and I'll give it a try.

I just noticed that there has been a new release candidate published for the Avalon and Indigo beta 1.  This package will work correctly with .NET Framework 2.0 beta 2 and will integrate into the IDE in VS 2005 beta 2.  This will eliminate the problems described in this previous blog post.  You can download this build by clicking here.  There is also a link on this page to an ISO image for an SDK that will provide documentation, samples and tools.

I got a question from a customer who found this blog post describing how to chain silent installation of VS .NET 2003 prerequisites, VS .NET 2003 and MSDN.  They wanted to know what the equivalent set of steps would be for chaining silent installation of VS 2005.  There have been some modifications to how setup works behind the scenes in VS 2005, most notably the elimination of the separate step that used to be required to install prerequisite components for VS, so happily I can say these steps are much simpler than in the past.  Here are the steps for VS 2005 (using the same format as my previous post).

To start with you should stage Visual Studio bits to a network share so that you can use this as your installation source later on.  You can accomplish that with the following steps (also described in the VS readme located in the file adminreadme.htm in the Setup subdirectory on VS Disk 1):

1. Create a folder on your server, such as \\server\vs2005
2. Create subfolders named \\server\vs2005\vs and \\server\vs2005\msdn
3. Copy the contents of all CDs labeled Visual Studio 2005 to \\server\vs2005\vs.  If prompted, choose yes to overwrite existing files.
4. Copy the contents from all the CDs labeled MSDN Library for Visual Studio 2005 to \\server\vs2005\msdn.  If prompted, choose yes to overwrite existing files.
   NOTE: You can substitute a different MSDN Quarterly Library for the version of MSDN that shipped with Visual Studio 2005 if you choose

Now that you have a network image, you can create the unattended INI file to install VS 2005 and MSDN using the following steps:

1. Locate a test computer that has the same operating system that you want to deploy Visual Studio to in your network, and make sure that it does not already have Visual Studio 2005 installed
2. Install .NET Framework 2.0 on your test computer (because this is required for creating an unattend file for Visual Studio in the next step)
3. Run \\server\vs2005\vs\setup\setup.exe /createunattend \\server\vs2005\datafiles\vs.ini /vsupdate=\\server\vs2005\MSDN\setup.exe /vsupdateargs="qn"
4. Open \\server\vs2005\datafiles\vs.ini, go to the [PostSetupLaunchList] section and change """qn""" to /qn
5. Go to a clean computer without Visual Studio 2005 installed and run \\server\vs2005\vs\setup\setup.exe /unattendfile \\server\vs2005\datafiles\vs.ini to test the unattended installation process

There are a couple of gotchas that I have seen that you should keep an eye out for when following these instructions:

• Make sure to note the extra \setup\ directory for the Visual Studio setup.exe in the steps above.  Unattended installation will not work correctly if you run the setup.exe in the root of the \\server\vs2005\vs folder; you must use \\server\vs2005\vs\setup\setup.exe.
• Make sure that you have write permission for the location that you create your data file at in step 3 (in this example I used \\server\vs2005\datafiles).  You will get an error if you try to create the data files on a share that you do not have write permissions for.
• Make sure that you create the INI file on a computer that does NOT already have Visual Studio 2005 installed.  If you have VS installed, you will end up creating an INI file for a maintenance mode update instead of an initial install of VS.
• The INI file for VS is unique to each version of VS (such as Pro, Standard, Team System), and also unique to the OS that you want to install on (Windows 2000, Windows XP, etc).  Make sure that you create INI files on computers that match what you will eventually be deploying to.

There is an advanced trick that you can use when creating this unattend script as well:

• If you want to perform a full install of MSDN to the local hard drive instead of a default installation, you can read the steps at this blog post to learn how to update your vs.ini file to call MSDN setup with the correct parameters to accomplish this.

In the VS 2003 instructions there was an additional advanced trick regarding waiting for the setup process to exit and checking the return code.  The workaround I listed in my previous post is not necessary in VS 2005 because setup now has specific logic to not copy itself to the %tmep% folder and start a new process if it detects it is being run in administrative installation mode.

I generally don't use my blog to talk about non-technical topics, but I wanted to take a moment to talk about my new job and team at Microsoft.  About a month ago I swiched from the Windows Embedded team to the Windows Media Center team.  In addition to switching groups, I also switched roles - moving from testing to program management.  I have been a tester for my entire career at Microsoft up until now, but switching roles is not going to dampen my passion for quality.  I feel very strongly that passion for quality, customer focus and problem solving are valuable traits for all job types at Microsoft and I'm planning to approach my new role with the same values and priorities I brought to my previous roles.

My role on the Windows Media Center team also brings me back to a setup team.  I will be working on setup for the Windows XP Media Center Edition and also for Media Center features that will ship in future versions of Windows.  It will be interesting to transition from the Embedded team (which is a part of the Windows Core OS division that produces setup technologies for everyone to use) to the Media Center team (which will be consuming the technologies created by my old division).  It is also going to be interesting working on slightly different types of setup technologies than I did on the Visual Studio and .NET Framework setup team.  Media Center use INF-based installation technologies (OCM and update.exe).  I am able to bring some of my background working on the .NET Framework OCM packages that shipped in Windows XP Media Center and Tablet PC Editions (for v1.0) and Windows Server 2003 (for v1.1).  I'm also working closely with the new setup technologies being introduced in Longhorn.

So, in the future, I'll be blogging about Windows Media Center features and development in addition to topics I've posted about in the past such as Windows Embedded, Visual Studio and .NET Framework, and general setup and deployment issues and troubleshooting.

Some customers have seen an error dialog launching the Visual Studio IDE after uninstalling VS 2005 beta 1 or one of the VS 2005 Community Tech Previews (CTPs).  The exact text of the dialog is A problem was encountered loading the Microsoft Visual Studio menu. Please run setup and select Repair.  In these scenarios, rerunning setup and trying to repair does not solve the problem.

You can workaround this issue by doing the following:

1. Launch regedit.exe
2. Go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Profile
3. Rename the entire Profile sub-key
4. Close regedit.exe and re-run the Visual Studio 2005 IDE
5. Choose your preferred development profile in the dialog that appears

The redistributable package for installing Windows Installer 3.1 is available for download again on the Microsoft Download Center.  It was available briefly a few weeks ago and was included on Windows Update but then was removed, and finally got re-posted at the end of last week.  You can find documentation about Windows Installer 3.1 in this KB article.

Windows Installer 3.1 was removed from the Download Center and Windows Update in order to fix the issue described in this KB article.  When trying to install a product that tries to update files that are protected by Windows File Protection, Windows Installer will display an error dialog with error code 1931 and a message stating that Windows Installer cannot update the file because it is protected by Windows.  This dialog has an OK button and a Cancel button with Cancel being the default.  Pressing Cancel will roll back the installation and pressing OK will cause the installation to skip the file in question and continue without updating it.  In previous versions of Windows Installer, running setup in silent mode would cause the OK action to be taken on behalf of the user.  However, in the original Windows Installer 3.1 release, this behavior was changed to cause the Cancel action to be taken on behalf of the user, which caused products that used to install correctly to cancel and roll back instead.  The re-posted Windows Installer 3.1 reverted this behavior back to what was seen in previous versions so that silent installs will default to the OK action if 1931 errors are encountered.

In most cases, it should be possible to author an MSI to avoid 1931 errors from ever appearing when trying to install a product.  Components that contain files that are under Windows File Protection on certain operating systems can be authored with a condition that will prevent Windows Installer from trying to install them on those OS's.  This is described in the workarounds in the KB article describing the bug that caused Windows Installer 3.1 to be unposted.  Unfortunately, that workaround only works for a setup author who fully knows all of the supported OS's for their products - even into the future.  I have seen cases where products ship with no known issues with installing files under Windows File Protection but then a later version of Windows starts protecting new files and introduces 1931 errors for applications that shipped in the past.

I am not sure how many people out there are running Windows Server 2003 Small Business Server and trying to install and use Visual Studio 2005 beta 2, but I wanted to let you know about this issue just in case.  There is a bug in setup for Visual Studio 2005 beta 2 (and also in beta 1 and any CTPs that shipped in the meantime) that prevents VS from installing correctly on Windows Server 2003 Small Business Server.  If you try to run setup, it will initialize the setup UI and then inform you that "A failed installation has been detected. Press OK to uninstall the product. Then retry installing."

Pressing OK and allowing setup to try to clean-up the failed installation will not allow install to succeed.  This bug has been fixed in later builds and will install correctly on this OS when it ships.

In the meantime, you can workaround this issue by doing the following:

1. Launch regedit.exe
2. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Integration
3. Rename the entire Microsoft Integration sub-key
4. Close regedit.exe and re-run Visual Studio 2005 setup

If you have had Visual Studio 2005 beta 1 installed and then removed it and installed VS 2005 beta 2, you may see an error like this when you try to set project properties in the VS IDE:

This can be resolved by running the VS 2005 beta cleanup tool.

The root cause of this issue is the issue I describe in this blog item.  The VS 2005 beta 1 version of the assembly named Microsoft.VisualStudio.Shell.Interop.8.0.dll is being orphaned in the GAC after beta 1 is uninstalled.  Then beta 2 installs a copy of the same assembly to a different location because the ProcessorArchitecture value for this assembly was changed between beta 1 and beta 2.  For some reason the VS IDE loads the old version from the GAC even if the newer one is present.

Sometimes, after uninstalling previous beta or Community Tech Preview (CTP) versions of Visual Studio 2005 (codename Whidbey) and then installing newer builds, the IDE may crash or display an error dialog stating “This application has failed to start because the application configuration is incorrect” after installing a newer beta or CTP.

This is normally caused by orphaned Visual C++ runtime assemblies left behind in the %windir%\WinSxS folder after uninstalling the previous build.

Steps to fix this issue

You can use the following steps to resolve this issue in most cases:

1. Create a batch file that has the following commands and run it from a cmd prompt (you can also get a copy of this script in text file format here):
   cd %SYSTEMROOT%\WinSXS
   for /D %%i in (*vc80*) do rd %%i /s /q
   del manifests\*vc80* /q
   cd policies
   for /D %%i in (*vc80*) do del %%i\* /q
2. Launch Visual Studio 2005 setup again from the entry in Add/Remove Programs or by rerunning setup.exe from the original installation location
3. Choose the option to repair Visual Studio 2005
4. After repair completes, re-launch the Visual Studio IDE

Additional information

In most cases, these errors will cause entries to be written to the System event log. You can run eventvwr.exe and look for error messages with event source "SideBySide".

Another common symptom of this problem is that the file %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.manifest contains a reference to one or more dependent assemblies for Visual C++ runtime files with incorrect version numbers.  The most common incorrect version I have seen is 8.0.41204.256.  Unfortunately, this problem cannot be fixed by simply editing devenv.exe.manifest.  Instead you will need to follow the 4 steps listed above to remove the orphaned files and repair VS 2005.

I have heard from a couple of customers who have had problems getting toolbox to appear when trying to use the designers in the IDE in VS 2005 beta 2.  The customers I have helped so far have all had some previous version of VS 2005 (either beta 1 or a CTP) and removed it prior to installing beta 2.  I wanted to let everyone know a couple of options you have for fixing this problem because the VS 2005 beta cleanup tool only fixes this issue for Visual Basic 2005 Express Edition beta 2 currently.

How do I fix this issue?

This fix has been verified by a customer who contacted me (see this MSDN Forum post for more info) so I recommend using this as long as you feel comfortable using regedit.exe to modify your registry:

1. From a cmd prompt, run regedit.exe
2. Go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0
3.  Rename the Profile sub-hive to something else
4. Close regedit
5. Relaunch the VS IDE
6. Select your desired development profile
7. Rerun the form designer of your choice and verify that the toolbox now appears correctly

Note that the registry hive that you want to use in step 2 above depends on the version of Visual Studio you have installed.  If you have any of the Express Editions installed, you will need to use the following registry hive names in place of the one listed above:

• Visual Basic Express - HKEY_CURRENT_USER\Software\Microsoft\VBExpress\8.0 (this is removed by the VS 2005 beta cleanup tool)
• Visual C++ Express - HKEY_CURRENT_USER\Software\Microsoft\VCExpress\8.0
• Visual C# Express - HKEY_CURRENT_USER\Software\Microsoft\VCSExpress\8.0
• Visual J# Express - HKEY_CURRENT_USER\Software\Microsoft\VJSExpress\8.0
• Visual Web Developer Express - HKEY_CURRENT_USER\Software\Microsoft\VWDExpress\8.0

All other versions of VS use the hive listed in step 2 above.

Another possible, less invasive fix (but one that I have not had a chance to fully verify yet) is to launch the VS IDE, choose Tools | Customize from the menu bar and click the Reset button to reset the toolbar.

Why does this happen?!?

The underlying cause is that there is some leftover profile registry keys/values under HKEY_CURRENT_USER\Software\Microsoft\<Product>\8.0.  In general, user data stored in the HKEY_CURRENT_USER hive is not removed during a product uninstall.  But this is also complicated by the fact that this profile data is written by the VS IDE and not by the setup MSI.  Therefore setup does not have any way of knowing that the data is even there and cannot try to uninstall it.  Normally the profile data will not interfere like this, but it appears there was some data written there in previous beta versions that is now incompatible since some of the code for that feature has changed since then.  The most common place I have seen that show up is in VB Express (which is why I added it to the cleanup tool).  In beta 1, the IDE start page showed an HTML file that was installed with the product, but in beta 2 it connects to a web site to show the start page and the local HTML file is no longer installed as a part of the product.  If the registry value is present that points the start page to the local HTML file but that file is not installed, then you see a file not found error where the start page should appear.

I have gotten a couple of questions since VS 2005 Beta 2 released a few weeks ago asking how to integrate the most recent Community Tech Preview (CTP) of Avalon and Indigo into the VS Beta 2 IDE.  Unfortunately, because the Avalon/Indigo CTP depends on a pre-beta 2 version of the .NET Framework 2.0, that CTP will not install and work on the same machine as VS 2005 Beta 2.  Rob Relyea posted a good FAQ explaining what is going on behind the scenes if you're interested.  Fortunately, there is an updated CTP planned for release in the next month or so that will plug into VS 2005 Beta 2, so stay tuned for that....