JetBrains .NET Tools Blog

A few months ago, Scott Hanselman gave a session at TechEd US were he showed some new features we were working on for TeamCity, in order to provide first class support for NuGet. He later blogged about it here.

Instead of delaying until the next release of TeamCity, this feature (like many), has been developed as a plug-in. Eugene, who has been working on it, announced the availability of a first build a few weeks ago. After some initial trials and changes, I decided to setup YouTrackSharp to automate the publishing of the NuGet package. It was surprisingly easy as you’ll see.

1. Installing the Plug-in

If your project is running on TeamCity at Codebetter.com, you can skip to Step 3, since it’s already installed and configured. If not, then grab the latest build from our public TeamCity server. Place the zip file into the plugins folder of your TeamCity installation and restart the server.

2. Configuring the NuGet version

Once the server is running, and agents updated (automated procedure), you then need to tell TeamCity what NuGet version you want to use. The plug-in knows about the nuget.org feed to it can grab the latest version of the command line tool directly. Click on Administration | Server Configuration. If the plug-in installed correctly, you should now have a new Tab called NuGet:

Click on the “Install additional versions of the NuGet.exe Command Line”. TeamCity will read from the feed and display available versions to you in the dialog box. Select the version you want and click Install:

Pull, Pack, Publish

The plug-in offers three main operations:

• Pulling NuGet packages required to build your project
• Creating NuGet packages
• Publishing Packages

In my case, I want to create the package and publish it. To give you a general idea of my build process, here’s the outline of the build steps:

The NuGet related steps are 3 and 4. Step 1 simply builds the project by building the solution file. Step 2 runs the MSpec tests.

3. Building the package

This step is for building the actual package. We create a new Build Step in our project and select NuGet Packages Pack. This will give us the following configuration screen:

As you can see, the configuration is pretty straightforward. Notice that in the Specification file, we can also provide a csproj file as opposed to a NuGet spec file. The advantage to this is that we do not have to redefine information such as version number and copyright information in the spec file. If you’re not familiar with this feature, check out David Ebbo’s post.

I’ve also checked the option to Include Sources and Symbols. This is also explained in David Ebbo’s post and it’s for publishing the sources to Symbolsource. Additional command line parameters (if required) can be passed in the Additional Commandline arguments. If you want to make this a release build, you can also do this by defining Configuration=Release in the Properties field.

Finally I’ve specified the Build number of the package using the TeamCity variable %build.number% which auto increments on each build, and is also used by another feature of TeamCity new in 6.5 which is called the AssemblyPatcher, which I’ll show you as the last step.

4. Publishing the package

The next step is to publish the package. As before, we need to add a Build Step and select NuGet Packages Publish.

This step is even easier to configure. By convention it uses nuget.org as the destination to publish the package. If you have your own NuGet server then fill in the address in the Packages Sources field. If you’re using nuget.org, leave it blank. You need to provide your API key which is stored in a password protected field and finally indicate which packages you want published. Here you can list each package individually or use wildcards. [Note: relative paths are allowed but at the time of writing this post, there was an issue and I was using the full path. This should be fixed soon].

If you want to publish to multiple sources, all you need to do is add another step. Note however that we did not have to specify an extra step to publish the sources to symbolsource.org. TeamCity will follow NuGet’s convention and do this for you automatically.

5. AssemblyInfo Patcher

Although this step is optional I recommend you use it. The AssemblyInfo Patcher is a new Build Feature added to TeamCity which temporarily patches all your projects AssemblyInfo.cs files to update the version number, and then reverts it back after the build is complete. This allows your build number, artifacts, packages and assemblies to all have the same version number. Adding this option is as simple as selecting it from the main project configuration screen:

That’s it. There’s nothing more to it. With a few simple build steps we have now fully automated packaging and publishing NuGet packages. As I mentioned initially, if you’ve got your project on CodeBetter, you already have this feature enabled. If you’re running your own server, just download the plugin and set it up. It’s very simple.

Try it out and please give us your feedback!

On the 5th May, in collaboration with our partners Pluralsight, we will be doing a webcast on Agile environments:

- What exactly is an Agile environment

- Best practices for setting up environments with TeamCity, YouTrack and an OSS stack

This webcast is completely free and open to all. Please check out Pluralsight’s website for more information and registration information.

On Tuesday, 5th April 2011, I’ll be giving a webinar (in Spanish) on how to setup an environment with TeamCity, YouTrack and your favorite OSS tools and frameworks.

Things we’ll see:

• TeamCity: Overview and benefits
• YouTrack: Mouseless Web Issue Tracking
• Introduction to Distributed Version Control Systems and benefits over Centralized
• Creating Continuous Integration Processes with TeamCity and OSS stacks
• Integration with Visual Studio and other IDE’s

The webinar will be roughly 2 hours and it will be mostly demo-centric.

It is a completely free event. If you’d like to attend, please register here

As some of you know, we recently shipped TeamCity 6 which includes, out of the box, a bundled version of dotCover. What this means is that you can now get free coverage for your code easily, and of course even if you’re using the Professional version of TeamCity.  The setup is quite easy if you are using MSTest and NUnit. For MSpec, you need to take a few additional steps.

Using MSTest / NUnit Runners

Normally build files consist of a series of tasks that involve compilation and running of tests. With TeamCity, you can separate some of these steps out into individual TeamCity Build steps, which is what we will be doing in this case (everything that we see here applies to both MSTest and NUnit).

Here is our build.xml (MSBuild) file:

As we can see, other than compiling a solution, which in this case consists of the actual application and the test assemblies, not much else going on.

[Note: this could have been done using the SLN as the Runner Type under TeamCity since this example build script does not do much else. In real scenarios however, build scripts do more than just call a solution (in fact normally you’d call projects not solutions)].

In TeamCity, we create a new build project and setup the VCS root. We then add a new Build Step which calls this MSBuild file:

Notice that all we are doing here is calling our MSBuild script. No coverage settings yet.

Next thing is to add an additional build step in TeamCity. This time, we are going to call MSTest as opposed to MSBuild:

(the sections cut out are blank).

In the .NET Coverage tool section we select JetBrains dotCover and then  add the assemblies we want coverage for (just the name of the assembly) prefixing them with +: and filtering out those we do not want coverage for with –:.

That’s all there is to it. Once we run the Build, we should now see a new tab with Coverage Reports as well as a new Artifact which contains the Coverage files zipped up.

The Code Coverage tab goes into more detail:

We can even drill down into individual classes and examine the code coverage:

If we are using NUnit instead of MSTest, the only difference is there test runner we select when adding a new Build Step in TeamCity. Instead of MSTest we choose NUnit along with the version:

What about MSpec or my Specific Test Runner?

If we are using MSpec or a different test runner that is not supported directly by TeamCity, we can still get coverage reports; we just need to do a little bit of additional configuration. TeamCity has an API which allows us to send it messages when we want to interact with it (this is actually quite a powerful feature but out of scope for this post so please leave a comment if you’d like me to cover it in more detail). We can leverage this API to tell it when to start coverage and where to get the results from.

Here is the build script for MSpec:

We have created two targets. The second one (TeamCity) is the one we are interested in. This does a couple of things:

1. The first <Exec> runs all MSpec tests so that we can see the test results inside TeamCity. This is not strictly necessary for Code Coverage but usually build processes do display these results. The –teamcity option we are passing in to MSpec is for it to generate the system messages that are then fed to TeamCity (see point 3)

2. The second <Exec> is the one that runs dotCover. This uses a configuration file called dotCover.xml which we will examine further down. We pass in the c (or coverage) option when calling dotCover.

3. This is a message we send to TeamCity to tell it that we have run coverage. We indicate the tool we are using (dotcover in this case) and where the results are located. TeamCity uses this information to then display the results in the UI. This is one of the API messages mentioned earlier.

Finally we need to define the dotcover.xml file with out configuration for running dotCover (for detailed information on creating dotCover configuration files, see here and here):

In terms of TeamCity, we then just define our build step that calls out to the build script:

Notice how we do not specify .NET Coverage options explicitly. And if all goes well, we can see the coverage output just as before:

Summary

We can see that running code coverage is now pretty straightforward when using MSTest, NUnit or even a custom test runner. Most of what we have covered for MSpec will work with pretty much any test runner in terms of coverage (feel free to vote here for MSpec support).

With any build process, there are numerous ways of doing the same thing. I’m going to show you one of them. Based on your setup and needs you might want to do things differently. Fortunately TeamCity is flexible enough to allow for many scenarios.

One thing to be aware of is that dotCover creates some temporary files for the XmlSerailizer in the Temp profile folder. This normally is not a problem unless the folder does not exist. If you are running TeamCity under the SYSTEM account, make sure that the folder C:\Windows\system32\config\systemprofile\AppData\Local\Temp exists. This will probably change in future versions so to avoid any possible issues.

Enjoy!

JetBrains’ renowned continuous integration and build management server, TeamCity, has just reached another milestone with its brand new version 6.

Apart from Gradle and Maven 3 support, multiple build steps, build priorities, new “My Changes” page and other valuable improvements that you can learn more about on the TeamCity blog, there’s a totally cool change that’s highly relevant for .NET developers: dotCover integration.

dotCover is now a first-class TeamCity citizen along with NCover and PartCover and can be used as a code coverage provider. That means, you can run unit test coverage analysis and view coverage reports generated by dotCover right in your continuous integration environment - of course, provided that your continuous integration environment is called TeamCity 6!

In order to analyze code coverage right in Visual Studio, you’ll still need dotCover installed on your dev machine but if you need dotCover reporting in TeamCity, it’s there for you, right out of the box.

Get the fresh, juicy TeamCity 6 from jetbrains.com/teamcity

What do Visual Studio Magazine readers and editors have in common?

They both like JetBrains tools!

As Visual Studio Magazine announced today, JetBrains ReSharper gets this year’s Readers Choice award in General Development Tools and the Editor’s Choice as Most Valuable Developer Tool - both for the second year in a row!

For the second year, JetBrains ReSharper earned top honors as the Most Valuable Developer Tool, dominating both our reader and panelist polling. Panelist and VSM Tools Editor Peter Vogel perhaps said it best: “I think I could write code without ReSharper—but I’m not sure anymore.”

Heavenly music to our ears!

These badges look pretty, don’t they?

That’s not all though!

Two more JetBrains products get Merit awards in their respective categories: dotTrace in Performance, Profiling and Debugging Tools, and TeamCity in Collaboration, Project Management, and Agile Solutions.

Many thanks and hugs to the panelists and readers of Visual Studio Magazine, and to all our users who’re spreading the love around! You’ve got style!

To be honest, we at the dev labs really liked ReSharper 5, too - probably more than any previous version. If ReSharper 6 lives up to expectations and becomes a stunner as we’re designing it to be, we’re hoping for a repeat success next year!

JetBrains tools continue to receive recognition and praise: three of them have been named finalists in this year’s Jolt Awards!

ReSharper, our intelligent add-in for Microsoft Visual Studio that you love so much, was honored as one of the five best Development Environments.

In the Change and Configuration Management category, the finalists included TeamCity, our distributed build management and continuous integration server.

And last but not least, dotTrace, our super-fast and efficient .NET profiling tool, was picked by Jolt judges as one of the best five Utilities.

Best of all, each of these products still has a shot at winning the big kahuna - the Jolt Excellence award, or maybe a Jolt Productivity award! We’ll keep you posted.

We thank you, our customers, for making our products a success.
Keep developing with JetBrains - and with pleasure!