Visual Studio.NET 2005 Beta 2 - 64-Bit
Installation
and Dual Boot Scenarios
by Peter A. Bromberg, Ph.D.

Peter Bromberg

"Officer, how would you expect me to know I was speeding. I was talking on the phone!" -- Baxter Black

The long - awaited BETA 2 release of Visual Studio.NET appeared on MSDN Subscriber Downloads over the weekend, and after more than a few hours Saturday evening competing for bandwidth with other earlybirds, I had my DVD burned.

These notes are about installation on an AMD 3400+ with Windows Server 64-Bit Edition, so they may not apply at all if you are using a 32-bit OS version.

First, a quick note about 64-bit: I remember when I was at the PDC in Orlando in 2001 (which is ancient history by today's internet standards) Microsoft had a kiosk running an early 64-bit alpha of Windows Server. So, they have been working on this for a very long time. These OSes are out and RTM now, today, and the landscape has changed totally. If you are a software developer or vendor and don't "get it" by now, too bad for you!

All I can say about 64-bit at this point is my two cents: If you are gonna get a new PC, make it an AMD 64-bit, either an Athlon or one of the newer versions. AMD really got the message early on with their dual mode CPU's and beat Intel to the punch big-time -- as I write, Intel is still playing catch-up. So far, every piece of 32-bit software I want to run has installed and runs perfectly on my AMD machine under the 64-bit OS. They act exactly the same as they do on my 32-bit machine and 32-bit OS. The only difference is, they RUN A LOT FASTER. Microsoft Word 2003 loads before you can blink your eye.

The only notable exception is Symantec AntiVirus 8 Corporate - apparently, Peter Norton wasn't advising them so they just didn't get the message. However, McAfee Viruscan 8 Enterprise works great on Windows Server x64 and seems to be a better product anyway, now that I've had a chance to compare. The only issue I found is finding a 64-bit compatible driver for my Canon i9900 large format printer - it's a fairly new model and a revised driver didn't make it into the RTM release of Server x64 so I had to install a driver for a lower-version Canon. And, Canon, although they've had plenty of time, seems not to have gotten the 64-bit message either, because they don't have one yet on their site as of mid April, 2005.

Visual Studio.NET 2005 Beta 2 Standard installed without a hitch. There are a couple of gotcha's for you 64-bitters out there:

1) IIS on 64 bit Windows is 64 bit. In order to make it run 32 bit ASP and ASP.NET apps, you need to run this handy little script in \Inetpub\admincripts\ (I just saved this as a .bat file):

cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1

The above will enable 32 bit Application Pools on IIS 6.0 64-bit, and you'll be fine.

2) If you want your ASP.NET 2.0 web apps in IIS to run properly, you have to drop to the Framework 2.0 64 bit Framework folder (you may have both 32 bit and 64 bit frameworks) --and run

ASPNET_REGIIS -i -wow64


The -wow64 switch is required for a full install on 64 bit machines. Otherwise, when you attempt to run or debug your app, you will get an HTTP "Service Unavailable" error.

Another little trick I had to learn over the weekend revolves around debugging when you use IIS 6.0 and have set up multiple sites on your development box. I like to run Windows Server because IIS 6.0 allows me to add as many IP addresses as I want and configure completely separate web sites.

This is a big advantage with ASP.NET projects because now everything you do is relative to the real web site root (not the Virtual Directory root) and so you can expect exactly the same behavior in your app during development and debugging as you will when it is deployed to a real web site remotely.

The problem I've run into is that ASP.NET debugging doesn't always work. There are lots of reasons why ASP.NET debugging doesn't work, and there are lots of fixes, but this one is germane to the specific situation mentioned above:

If you have an ASP.NET app that is targeted to a specific web site root at a specific IP Address in IIS (not "all available" as is the default), you may need to modify both the .sln file and the .webinfo file to replace the site name with the actual IP address of the site. Then, ASP.NET debugging will work fine (provided you comply with the other 25 things you might still have wrong!).

Example:

.webinfo file:
<VisualStudioUNCWeb>
<Web URLPath = "http://192.168.0.110/MyWebSite.csproj" />
</VisualStudioUNCWeb>

.sln file:

Microsoft Visual Studio Solution File, Format Version 8.00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MyWebSite", "http://192.168.0.110/MyWebSite.csproj", "{1EB1C062-1990-4483-AB4C-EA7854FE0E22}"
ProjectSection(ProjectDependencies) = postProject

Note that in both the above, the previous entries would have been "MyWebSite" and have been changed instead to the actual IP address the hosts file entry for it points to, or "192.168.0.110" in this case.

That does it!

Dual Boot Windows 64 bit and Windows XP 32 Bit Scenario

I held off for quite a bit on installing Windows XP Pro 32-bit on the other drive, but surprsingly, despite all the cautionary tales I've read, it was a non-event. I have two drives a big SATA 200G primary, and another ATA 60G I threw in there as a slave. Simply booted off the XP CD, chose the correct drive, installed XP, and it was fine. Contrary to what I had read, it DID NOT replace the NTLDR and related files on the primary partition with their 32-bit counterparts (Although I'd still recommend backing them up somewhere safe -- that's boot.ini, NTDetect, and NTLDR).

The only remaining task was to edit the boot.ini file on the primary to allow for the dual boot. Mine looks like so:

[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

Note that the key number is rdisk(1) in the second OS line. Rdisk(0) is your primary drive, then rdisk(1), etc. That's all there is to it! I have a 5 second timeout set so if I do nothing when the list comes up, I get my desired default OS.

That's all for now, I'll revise this with more later as time permits and new discoveries are made. In the meantime, if you have an issue or a fix for Visual Studio.NET 2005 Beta 2, post it at the little discussion board at the bottom of this article.

P.S-- I've started a Google Group for Open Source .NET discussion. You're invited to join!

Google Groups Subscribe to Open Source .NET forum
Email:
Browse Archives at groups-beta.google.com



Peter Bromberg is a C# MVP, MCP, and .NET consultant who has worked in the banking and financial industry for 20 years. He has architected and developed web - based corporate distributed application solutions since 1995, and focuses exclusively on the .NET Platform.
Article Discussion: