NuGet is a valuable tool for managing references to external libraries in your projects. If you’re not using it yet, you owe it to yourself to try it out and see what you’re missing. Though, that’s not what this post is about. Not only are NuGet packages a great way to distribute publically available libraries, they can be used just as well for custom internal libraries with their own release management which are used in multiple projects. Since there’s a lot of information already available on this topic, instead of repeating it I’ll rather link to it from one place and add a few helpful hints and tricks along the way.

The first step is to create a NuGet package from your library. To do it you need NuGet.exe, it’s not enough to have NuGet Package Manager Visual Studio extension installed, neither is that necessary when this step is being done on your build server. Although it is possible to create a package directly from a Visual Studio project, I strongly suggest to put in a little extra effort from the beginning and use a convention based working directory instead. It gives you many more options which you’re going to miss very soon if you do it the easy way. Don’t forget to set the correct version in the manifest file during each build -  it is only done automatically for you when using a project file as the source. This short NAnt task should do the trick (CCNetLabel property contains the desired version since this is being built with CruiseControl.NET):

<xmlpoke file="MyLibrary.nuspec"
         xpath="package/metadata/version"
         value="${CCNetLabel}" />

Once *.nupkg files are being generated on every build of the library, it’s time to set up an internal feed to distribute them. While it is possible to host a proper feed in IIS, a poor man’s version in the form of a file share will work just as well. Just create a shared folder somewhere on your network (e.g. \\buildserver\NuGet) and copy every generated package file into it. Now you can instruct your developers to add this feed to their NuGet configuration and they can start referencing your libraries the same way they are already used to with libraries from the official NuGet gallery:

You could already stop at this point but I’m convinced that you should go one step further and take care of package restore to avoid putting the libraries in your source control system. There are only three easy steps to follow:

• Open Package Manager Console Window (Tools > Library Package Manager > Package Manager Console menu item in Visual Studio with NuGet Package Manager installed).
• Run the following commands:

Install-Package NuGetPowerTools
Enable-PackageRestore

• Instead of the packages folder put the .nuget folder into source control (both are inside the solution folder).

Once this is done, NuGet will always make sure the correct versions of all the packages are present locally before the build starts. There’s even no need to have NuGet Package Manager installed for this to work. There’s only one more change required to make this work flawlessly with the internal feed that we have set up. Open up the NuGet.targets file in the generated .nuget folder and add this feed to the PackageSources property group:

<PackageSources>\\buildserver\NuGet -source https://go.microsoft.com/fwlink/?LinkID=230477</PackageSources>

Without this modification the package won’t be found if NuGet is not properly configured for the user the build is running under (the package sources configuration is stored in %APPDATA%\NuGet\NuGet.config). The second feed in my case is the official one which you should always add as well so that the public libraries can still be found.

Web.config transformations are a great but often overlooked feature introduced with ASP.NET 4.0. They provide a simple way to define a different configuration for Debug and Release builds of your project by only specifying the differences (typically only connection strings and similar settings) in a separate transformation file while keeping the core of the configuration file common and consequentially making it easier to manage.

Unfortunately files aren’t transformed until the web deployment package is created, i.e. they aren’t part of the core build process. This makes the transformations more difficult to use in some scenarios such as having a different configuration file for automated testing as a part of the build process.

Since the transformation is done by the TransformXml MSBuild task in Microsoft.Web.Publishing.Tasks.dll assembly there is a way to make this work by modifying the project file manually, though. Here is a snippet that I added to my project file (line break in the AssemblyFile added for readability only):

<UsingTask TaskName="TransformXml" 
           AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\
                         v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild">
    <MakeDir Directories="obj\$(Configuration)" 
             Condition="!Exists('obj\$(Configuration)')" />
    <TransformXml Source="Web.Config" 
                  Transform="Web.$(Configuration).config" 
                  Destination="obj\$(Configuration)\Web.config" 
                  StackTrace="true" 
                  Condition="Exists('Web.$(Configuration).config')" />
</Target>

As you can see the transformed configuration file is put inside the obj folder from where I copy it to the desired final location before running the tests. I find this a suitable spot for it unless you are precompiling views in your ASP.NET MVC project. A web.config file anywhere in obj folder brakes the build so you’ll have to put the file elsewhere or make sure you delete it before precompiling the views.

If you want to make this work on your build server without having Visual Studio installed on it, there is one more step remaining. The above mentioned assembly is not installed with .NET SDK meaning that you have to copy it there from your development machine. The file is located in the MSBuild extension folder, i.e. “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\” by default.

This takes care of transforming web.config files during build. How about transforming app.config files and even other XML files in your projects? I guess it would be possible to use the same MSBuild task on them but no Visual Studio support for transforming those files would mean even more tempering with project files to make transformation files appear under the file they are used to transform.

This is where SlowCheetah – XML Transforms Visual Studio extension can help. After installing it you can define transformations for app.config the same way you are already doing it with web.config files. The transformation is part of the build process in this case, i.e. the transformed file is put in its usual spot in the build output folder (usually bin) instead of the original one. It couldn’t get any simpler.

As an added bonus the extension features support for previewing the results of the transformation: after right clicking the transformation file and selecting the Preview Transform command a diff window will open graphically showing the differences between the original and the transformed file. Of course this works with web.config transformations as well making the debugging of transformations much simpler. A good reason in itself to install this extension.

To avoid failed builds on your build server as well as with the other members of your team not having this extension installed it’s best that you copy the SlowCheetah MSBuild targets and the corresponding assembly containing the tasks to your solution directory and put it in source control. In this case you’ll again have to modify the project file to set the new path. Just search for the SlowCheetahTargets property definition and modify the path accordingly (line breaks added for readability):

<PropertyGroup>
    <SlowCheetahTargets Condition=" '$(SlowCheetahTargets)'=='' ">
        ..\_References\SlowCheetah\SlowCheetah.Transforms.targets
    </SlowCheetahTargets>
</PropertyGroup>

Are there any ways to make your life simpler by using configuration transformations in your projects?

My favourite environment for running NUnit unit tests during the development process is definitely Unit Test Runner in CodeRush. I just love the way I can run the tests and see the results directly in the source code editor.

When I just recently had to get a usable development environment up and running with Visual C# 2010 Express, I had to find a different solution since extensions are not supported in the Express SKUs of Visual Studio which means that neither CodeRush nor TestDriven.NET can be used in this case.

The first step is pretty obvious: add the NUnit GUI runner as an external tool to the Tools menu. Configuring it that way even automatically opens the selected project in NUnit to really minimize the effort needed.  Just make sure that you add both the x64 and x86 versions of the tool if you have 64-bit Windows. You’ll need the second one if you compile your project for x86 which is the default setting in Visual Studio 2010. If you try to open it in the x64 version of NUnit you’ll only get a cryptic FileNotFoundException from NUnit.

This setup works just fine as long as you only need to run the tests. But sooner or later you’ll want to debug one of them to see why it isn’t working as expected. This is when you’ll start to miss the functionality of attaching the debugger to an external process (NUnit in this case).

Fortunately I stumbled across a great idea how to circumvent this limitation: start the test runner directly inside your own test project. I had some problems getting it to work exactly like this and I also didn’t like the idea of putting this code directly in the test assembly, so I’ve come up with a small modification. I added another “Console Application” project to my solution which I use only to start the test runner. I also changed the code to run NUnit in a separate AppDomain to give me more control over it.

class Program
{
    private static readonly string nunitFolder = @"C:\Program Files (x86)\NUnit 2.5.9\bin\net-2.0";

    public static void Main()
    {
        AppDomainSetup setup = new AppDomainSetup();
        setup.ApplicationBase = nunitFolder;
        setup.ConfigurationFile = Path.Combine(nunitFolder, "NUnit.exe.config");

        AppDomain nunitDomain = AppDomain.CreateDomain("NUnit", null, setup);
        nunitDomain.ExecuteAssembly(Path.Combine(nunitFolder, "NUnit.exe"),
            new string[] { Path.Combine(
                Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location),
                @"..\..\..\Tests\bin\Debug\Tests.dll") });
    }
}

You also might have noticed that I am running the GUI runner instead of console runner. It works better for me because I can select the test I want to debug instead of just blindly running all of them and waiting for the right one to start and hit my breakpoint. You can run the console runner just the same if you prefer.

Subversion and CruiseControl.NET can be invaluable tools in your .NET development process. There are many resources available to help you get started which I’ll try to gather in this post along with some of my personal experiences.

Let me start with the list of recommended software:

• VisualSVN Server is the ultimate Windows version of Subversion including a simple setup and powerful management tools. If you are planning to install a Subversion server on Windows it should be your first choice.
• AnkhSVN is a Subversion Source Control Provider (SCC) for Visual Studio. As long as you’re not using Express editions of Visual Studio, this is the suggested way of working with SVN directly from Visual Studio IDE.
• TortoiseSVN is a Windows shell extension for working with Subversion from within Windows Explorer. When you're not working with Visual Studio solutions this is the best choice for using SVN.
• CruiseControl.NET is a continuous integration server including a web dashboard and CCTray - a system tray client application for monitoring and controlling builds.

If you’re not already familiar with the above mentioned products, you should consult their documentation or search for tutorials. I will rather focus on setting up your development and release process. If you haven’t done so already I suggest you first read the following articles by Ariejan de Vroom:

• How to structure your repository
• How to release software properly
• How to fix bugs properly

I mostly based my configuration on the ideas in these articles. I have projects configured in CC.NET to build all copies of the project: trunk (ProjectName-Trunk), all branches (ProjectName-REL-#.#) and all tags (ProjectName-v#.#.#). To identify individual builds I am using CC.NET’s Assembly Version Labeller together with AssemblyInfo MsBuild Community Task.

Assembly Version Labeller is really simple to configure. You only need to add a short snippet to each project:

<labeller type="assemblyVersionLabeller">
    <major>1</major>
    <minor>0</minor>
    <build>0</build>
</labeller>

I’m using the following versioning policy:

• I start each project with version 1.0.0.
• Once it’s ready for release I make a copy of the trunk in the branches directory, named REL-#.# containing the major and the minor version number. Immediately afterwards I bump the version of the trunk (only minor or major and minor, depending on the nature of the new features planned).
• In the release branch I make the necessary changes before release (e.g. I change the AssemblyProduct name to distinguish between development and release quality builds) and make another copy in the tags directory, named v#.#.# containing the major, minor and build version numbers. Immediately afterwards I increase the build version number in the release branch.
• I make no changes to the copies in the tags directory. All bug fixes go to the release branch. Once I’m ready for a new release I repeat the previous step.

Since I don’t specify the revision number directly, the SVN Revision number gets used automatically. This makes it possible to match each build to the revision of the code in SVN.

To put the generated assembly version in the build I am using the AssemblyInfo MsBuild task. There are two steps involved in doing this.

First you need to move the AssemblyProduct, AssemblyInfo and AssemblyFileVersion attributes from the auto generated AssemblyInfo.cs file into a new file. In my case the AssemblyVersion.cs has the following contents:

using System.Reflection;

[assembly: AssemblyProduct("ProjectName DEV")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Next you have to modify your project file (*.csproj) by importing the community tasks and adding a call to the AssemblyInfo MsBuild task:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
    <AssemblyInfo Condition="'$(CCNetLabel)' != ''"
        CodeLanguage="CS" 
        OutputFile="Properties\AssemblyVersion.cs" 
        AssemblyProduct="ProjectName TRUNK" 
        AssemblyVersion="$(CCNetLabel)" 
        AssemblyFileVersion="$(CCNetLabel)" />
</Target>

If you have never edited a project file before, you might want to read these first:

• How to: Edit Project Files
• How to: Extend the Visual Studio Build Process

One more thing to note which might not be all that obvious. The Condition in the AssemblyInfo task is met only when building from CC.NET. For builds in Visual Studio the task doesn’t regenerate the AssemblyVersion.cs file therefore the revision number is always 0 and the AssemblyProduct has a DEV suffix as defined in the original file. Also I remove the TRUNK suffix from the AssemblyProduct attribute of the AssemblyInfo task when moving code from trunk to release branches to separate between the two.

Once the number of projects in a solution comes up to thirty or more, most of the project related operations become really slow: setting the default project, building a project starting and stopping a debug session etc. There are no noticeable slowdowns with up to twenty projects in a solution though.

Although usually no solution with real projects should reach such numbers (I stumbled upon it by just adding sample projects to the same solution), it is something to have in mind when deciding how to group projects in solutions.

Trying to build a C++ project opened from a network share in Visual Studio 2005 might fail with a strange error: Command line error D8022 : cannot open '$(OutDir)\RSP00000115642624.rsp'. Double clicking it in the Error List window crashes the Visual Studio. The issue is reported in the MSDN Product Feedback Center.

Additional exploration and experimentation revealed that the problem only appears when the share host can’t authenticate the user reading from and writing to the share. This means there will be no error when the user and the share hosting computer are in the same domain. You can find a more thorough explanation in the following MSDN forum post.

Unfortunately this usually isn’t the case in the home environment. It’s best you just avoid the problem altogether by opening the project from a local drive. Just use a version control system or a synchronization tool to assure the same files are on the local machine and on the server when you need to.