Visual Studio 2008
		Home « Computers « DevBlog

Back to: Development Blog Contents

Upgrading to Visual Studio 2008

In early April 2008 I took the long overdue step of migrating from Visual Studio 2005 to 2008. Following are some jumbled notes about the experience in case they might be of use to others.

Uninstall the old stuff

Most of the extensions, kits and tools for using Framework 3.0 with Visual Studio 2005 are redundant and come built in with 2008. To be on the safe side I uninstalled absolutely everything I could find related to development and started afresh. I uninstalled (not in this order): Java runtime, MSMXL, Guidance Automation Extensions, CAB source and tutorials, Framework 3.0 and 3.5, Silverlight 1.0, FxCop, VS2005 extentions for Framework 3.0, Compact Framework versions, XamlPad, VS2005, Firefox, Devxpress and some other miscellaneous old stuff I found lying around.

The uninstall took about 3hours of concentrated work, most of the time (70 minutes) being taken by VS2005 uninstall. it was overkill to do this, but I feel that cleanliness and conservatism is always wise when you're dealing with so many complex and related pieces of software.

%PATH%

Because I had been running so much Framework 2.0 development over the previous years, I forgot I had added the SDK 2.0 bin and Framework 2.0 bin folders in my system PATH environment variable. This was for convenience of running tools like sn.exe and build.exe from the command line. This is a bad thing to do ... don't add specific Framework folders to your PATH. After the upgrade I found that important folders had moved or become empty and many of my batch files were broken.

If you're developing from the command line, then you must call the Microsoft supplied batch file that sets the environment for you. The line I currently put at the start of all batch files is:

call "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"

SDK

The SDK for Framework 3.5 has moved and changed name. On my machine it's now under:

C:\Program Files\Microsoft SDKs\Windows\v6.0A

I couldn't find this folder for a while, until I looked inside the vsvars32 batch file listed above. My first attempt to run an msbuild died with an error telling me that a registry entry did not exist rquired to locate the SDK. After a few minutes of searching I found that the following registry entry needed to be created:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv2.0"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A"

I don't know why I suffered from this problem, as it's apparently caused by installing things in the wrong order. I felt sure I'd installed everything in a sensible order, but so it goes.

Batch Compiles

I have an msbuild script that recursively finds all *.sln files in my development folders and rebuilds them all. I think every developer should have a similar script, as it's a kind of sanity test that you haven't broken anything. Now that my PATH and SDK references were all fixed and neatened, I ran the batch build over my solutions and received a cryptic error in 2 places that a project was referenced twice in the same solution. This weird error only happened during a batch build, not when building from Visual Studio 2008. I eventually found that I had a "Solution Folder" (the fake folder) with the same name as the solution. So make sure all of your solution folder names and project names are unique. After stripping out the validation, my batch build file looks like this:

iisreset
call "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
if exist build.log del build.log
for /R %%f in (*.sln) do "msbuild" "%%f" /nologo /t:rebuild /l:FileLogger,Microsoft.Build.Engine;logfile=buildl.log;append=true

Everyone should regularly run a bulk build like this. It's a kind of unit test for your solutions.

Better Experience

Visual Studio 2008 is a greatly improved development experience from 2005. The forms and web designers are much more stable. Under VS2005 I used to get "pink screens of death" often when working with controls derived from a nest of base classes. The new web designer shows you a lot more about the positions and attributes of controls, and there are 3 new very powerful Tool windows to help you work with CSS. Unit testing is built-in, so you can get rid of NUnit and Alt+Tabbing over to it all the time to run tests. There are lots of other features I haven't had time to investigate yet.

Most importantly, VS2008 can multi-target Framework 2.0, 3.0 and 3.5 (see Scott Gu's blog). And most fabulously, even if you target Framework 2.0 you can still use a lot of the new C# compiler features as this 2.0 sample code demonstrates.

var var = "Hello world";
Action<string> show = msg => Console.WriteLine(msg);
show(var);
var bar = new { Name = "Foo Bar", Age = 51 };
show(bar.Name + bar.Age);
MyThing thing = new MyThing { Name = "Foo Bar", Age = 51 };
show(string.Format("{0},{1}", thing.Name, thing.Age));

You can't use LINQ because it requires the new mscoree DLL, but extension methods can be used by creating a mock attribute class (see Phil Curnow's article). Start using the new C# language features and make your code look more groovy, functional and terse.

Post Scriptum (November 2008) — My initial excitement with the new built-in unit testing has been deflated totally. I have sadly found that navigating around the different panes is woefully tedious and you can't see "the big picture" of what happened with your test output. The output panes also display CRLF and LF line terminators differently, producing some awful formatting. I have dropped the VS2008 testing features totally and returned to NUnit.

Back to: Development Blog Contents