So I was on the road when I heard the announcement that the RTM version of Visual Studio.NET 2008 had been released to MSDN subscribers. It caught me unaware – I hadn’t been keeping up with the timeline for the release. I tried to download it from my hotel room, but if you’ve tried to download anything bigger than, say, a text file on a hotel’s free WiFi, you know the folly of trying to grab a 4 Gigabyte file.
When I got back home and finally got my hands on it, the game was on. I had been playing with the beta 2 release of VS.NET 2008 for some months, so it was cool to get the real thing. To get that program, I had downloaded the Virtual PC from MSDN that had VS.NET 2008 beta 2 and SQL Server 2005 pre-installed. Being a Virtual PC junkie, I was touched by MSDN’s gesture of making that available to everyone.
Seriously, though. I'm deep with virtual machines. Since my work involves multiple clients, and my interests range far afield, I tend to organize through Virtual PCs. So if I go to one client, I’ll use one VPC with all the relevant programs and files, then when I go to another, I have a different VPC. My personal stuff is contained on other VPC’s still. I keep the whole shooting match synchronized through the excellent and underrated program Groove (which I will undoubtedly blog about later). The only downside is that I have about 15 Petabytes worth of VPC’s.
Naturally, then, I decided to install the RTM version of VS.NET 2008 on a VPC. Some interesting things came out of the exercise. Because of the nature of this blog, I’ll tell you about the problems.
I started with a base VMWare image that was running the Vista operating system. It also had the Microsoft Office 2007 Ultimate suite, which I considered vital, since developing Office Business Applications is one of my current interests. I cloned the virtual machine, and then installed programs in the following order:
1. Visual Studio.NET 2008 Team Edition
2. SQL Server 2005 Developer Edition
3. SQL Server 2005 Service Pack 2
I had been through the painful process of trying to get VS.NET 2005/SQL Server 2005 to run on Vista, so that’s why I went straight from the base installation of SQL Server 2005 through Service Pack 2 without pause. There is a good description of that process here.
Well, this “leave the configuration up to the programs” approach caused problems. It seemingly always does, of course, but I’m a hopeful sort. The first problem was that VS.NET 2008 gave me a warning about IIS not being configured. SQL Server 2005 did the same. Worst of all, I found myself without an instance of SQL Server Management Studio 2005. And yes, I had selected Management Tools under Client Tools node in SQL Server Setup during installation. It just apparently didn’t see fit to install or give a descriptive error of what caused the installation failure.
The IIS problems were understandable after a bit of detective work. VS.NET wanted certain features to be turned on, and SQL 2005 wanted some to be turned on as well. Even if you have IIS 7.0 turned on, the installers will not necessarily recognize it. The correct configuration was hardly intuitive, but the information was available.
The lack of SQL tools was a bit more troublesome. Most of the discussion around the issue either blamed the person installing SQL for not selecting Management Tools. There was some sporadic advice about how to install the client tools on their own.
I tried to install the SQL client tools on their own. First, I went the route of changing the program through the usual Vista method: Control Panel -> Programs and Features -> Uninstall a program (I regret that when you want to change a program installation in Vista, you have to select Uninstall a program, but I digress.) That didn’t work. I ran the main SQL Server Installer, and I ran the specific MSI for the client tools (SqlRun_Tools.msi). I was unsuccessful, but the errors were ambiguous. I believe it had something to do with the fact that I had already applied Service Pack 2, and I was trying to go back to the original discs to add the client tools.
I still haven’t got a concrete answer, but I could guess at some possible problems with the initial installation. Maybe when SQL tried to install VS.NET 2005 (as part of Business Intelligence Studio), the installer recognized that a later version was installed (VS.NET 2008) and aborted the operation. Or maybe VS.NET’s installation of SQL Express gummed up the works. I just decided to attack the problem another way.
Solution abound
Internet Information Services
Web Management Tools
IIS 6 Management Compatibility
IIS WMI Compatibility
IIS Metabase and IIS 6 configuration compatibility
IIS Management Console
World Wide Web Services
Application Development Features
.NET Extensibility
ASP.NET
ISAPI Extensions
ISAPI Filters
Common Http Features
Default Document
Directory Browsing
HTTP Errors
HTTP Redirection
Static Content
Health and Diagnostics
HTTP Logging
Request Monitor
Performance Features
Static Content Compression
Security
Request Filtering
Windows Authentication
(The features in bold were the ones I checked).
Then I changed the order of my installation:
1. SQL Server 2005 Developer Edition
2. SQL Server 2005 Service Pack 2
3. Visual Studio.NET 2008 Team Edition
Right as rain this time. Both programs were happy with how IIS was configured. The SQL client tools appeared as expected. I now have my installation of VS.NET 2008 rocking. And there was much rejoicing.
What have we learned?
If you are going to have a full version of SQL running with VS.NET 2008, install it first. Tread carefully when configuring IIS on Vista, to work with VS.NET and SQL.
No comments:
Post a Comment