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 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):
Now that you have a network image, you can create the unattended INI file to install VS 2005 and MSDN using the following steps:
There are a couple of gotchas that I have seen that you should keep an eye out for when following these instructions:
There is an advanced trick that you can use when creating this unattend script as well:
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.
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.
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:
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 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:
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'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 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:
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:
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 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:
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 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....
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:
After choosing a development profile, the IDE should launch normally.
The root cause of this issue is exactly the same as the toolbox issue that I describe in this article.
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.