The JetBrains team have been working hard at getting functionality and bug fixes into version 4.0 of ReSharper.  I'm very excited to see that it's finally reached RTM status and now fully supports Visual Studio 2008 and all the C# 3.0 goodness!  Go get it here.  For those who have been involved in the EAP program, it's actually build 819.

For those who've never tried R#, I strongly suggest that you take it for a spin.  The improvements it brings to productivity are just immense.  For the full list of features the JetBrains site has all the info, but here are a couple of my favourite features:

Go To File / Member
This functionality is brilliant at quickly navigating around large solutions.  You can type in the full name of the class / method / file that you are after, just the capital letters, you can use wildcards or you can combine all these techniques.

Refactoring Options
Yes I know that Visual Studio has included some refactoring functionality for a while now, but this one of ReSharper primary strengths.  It includes options such as:

• Rename class / method / variable / parameter / field / property (optionally searches within comments and strings)
• Change signature
• Extract / inline a method
• Extract interface / superclass
• Push members up / pull members down
• Introduce parameter
• Introduce field
• Introduce variable (I esp like the way it detects multiple occurrences of an expression of offers to replace them all)
• Convert anonymous delegates to / from lambdas
• Set field values from constructor arguments

There's so many of these - these are just the ones I can think of right now.  In fact, there are so many that I always keep a copy of the ReSharper keyboard mappings on my desk.

Coding in Reverse
Undoubtedly the most powerful feature available within ReSharper, JetBrains picked it out as the primary skill of the ReSharper Jedi.  This is a technique where you use variables / methods / classes before they exist.  ReSharper will then infer their definition from your usage and allow you to actualize them with a couple of keystrokes.  It's immensely powerful, but it's really got to be seen to be fully appreciated.

And More
I strongly ReSharper to all developers who want to improve their productivity ... which should be all developers.  I also strongly suggest that you take some time out to learn the featureset and some of the options available within ReSharper.  Joe White's blog series The 31 Days of ReSharper is a great place to start this journey.  Just be warned that you might get seriously hooked.

Some metrics that we captured on my project: (I think the numbers speak for themselves)

FYI our solution has 33 projects in it (including a database project, a web application project, numerous DLLs, an EXE and a WiX installer) and there are almost 1,600 unit and integration tests.

In my new project, we're using Team Foundation Server (TFS) as our source code repository and also as our continuous integration (CI) engine.  The CI aspect is handled neatly by Automaton which leaves me to setup the build process (or the Team Build Type, as it is referred to in TFS parlance).  Automated unit tests form the backbone of any decent CI process.  It wasn't entirely straightforward to set these up, so I thought I'd share my experience with the community.

It's worth noting that we are using MS Test for unit tests, i.e. the unit tests built into Visual Studio Team System (VSTS), and not Nunit.  I expected that this would simplify the build process since I wouldn't be integrating Nunit results back into the build report.  This has been the case, but there are a few gotchas.

As stated on MSDN "How to setup a build server":

In order to run tests during build, Team Edition for Testers must be installed on the build computer. In order to run unit testing, code coverage or code analysis, Team Edition for Developers must be installed on the build computer.

I find it quite surprising that I need a Visual Studio installation on the server, but the docs are pretty clear on this point.  Are there any licence implications of this?  The Visual Studio 2005 Team System licensing white paper states:

As part of the build process, Team Foundation Server may run quality tests and/or analysis on the precompiled or compiled code. These tests rely on functionality found within Team System client products, typically within the Team Edition for Software Developers or Team Edition for Software Testers products. These products may be installed on the build machine by licensed users of those products, as long as they are not directly used by any individuals who are not licensed for those products.

In short, licencing is not a problem.

Now unit tests really are just a type of test, so I'm not entirely clear whether I need VS TE for Testers or VS TE for Developers.  I'm planning to do some automated system testing and so I've installed the relevant bits from both editions on our build server.  I'd guess that you really only need VS TE for Developers.

So you would think that now our build server ought to be fully setup and we now ought to be able to execute unit tests.  Well you can, but only if they are part of a test list.  VSTS groups tests into lists and you need to specify (in the TfsBuild.proj file) the name of a test list containing unit tests to execute.  This is clear in the TfsBuild.proj file, where you need:

I don't think this is good enough.  It's enough of a problem for me to get developers to write unit tests.  I don't want to have to then get hold of a VS TE for Testers installation (which is the edition that allows you to edit test lists) and then add these unit tests into the appropriate list to get executed.  And it seems that I'm not the only one.  Enough people have complained about this that Buck Hodges (the dev lead for Team Build) has posted some modifications to TFS that allow you to execute all unit tests in a DLL.  These take the form of a DLL containing an updated MS Build task and a revised Microsoft.TeamFoundations.Build.targets file (plus some docs).  Both of these files need to be installed on your build server.  Having done that, you can get rid of the MetaDataFile element in TfsBuild.proj and replice it with:

This (rather odd) syntax translates into **\*.UnitTests.dll.  In other words, you can just specify which DLLs contain your unit tests and the Team Build will now execute them all.

There are two main ways to develop WPF/E within Visual Studio 2005 - one is to edit the XAML in the XML Editor, and the other is to use Cider, the XAML WPF designer.  There are pros and cons to each approach, and some configuration for each.

Using Cider
Cider is the Visual Studio designer for WPF and XAML and is shown to the right.  It is available in CTP (there are no plans for an RTM version for VS 2005).  You can edit in a design view or a XAML view and they are synchronised.

This sounds great.  The only problem is that you have to be very careful to limit yourself to the WPF/E subset of XAML.  Cider targets the full set of XAML and WPF, so you may find that you end up developing something that doesn't work in WPF/E.  If you've developed anything with WPF/E, you'll know that the runtime errors are not particularly informative and so you might not want to go down this route.

Also, for Cider to work your XAML document needs to be in the namespace http://schemas.microsoft.com/winfx/2006/xaml/presentation. This isn't the WPF/E namespace.

Using the XML Editor
I was very disappointed when I'd installed the WPF/E SDK and Visual Studio didn't give me Intellisense on my WPF/E XAML.  It turns out that this isn't very difficult to enable.  All you have to do is copy the file "wpfe.xsd" from the WPF/E SDK Schema directory into the Visual Studio schema directory.  In my case, I copied the file from

C:\Program Files\Microsoft SDKs\WPFE\Help\XSD 
   to   
C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas

These are the default directories so your system is likely to be the same.

It's worth noting that the default namespace on your XAML document needs to be http://schemas.microsoft.com/client/2007 for Visual Studio to associate the schema.  This is the proper WPF/E namespace.

Getting Visual Studio to Use the XML Editor
If you have installed Cider, you will find that Visual Studio wants to open all XAML documents using this and not using the XML editor.  If you do want to use the XML Editor, you need to inform Visual Studio of this.  To open XAML files in the XML editor by default you can go to the Tools / Options window and under Text Editor / File Extensions set .xaml files to open in the XML Editor.  A screenshot of this is below.  If you then want to open a XAML file in Cider, you will need to right-click from the Solution Explorer and choose "Open With ...".

And this is the other way of getting XAML files to open in the XML Editor (i.e. without modifying your options).  You can always right-click on your XAML file and go through the "Open With ..." dialog.  Personally, I prefer just to double-click.

UPDATE: WPF/E is now better known as Silverlight.  An unusual example of Microsoft changing from a clunky codename to a cool product name!