JetBrains TeamCity Blog

Over the last few weeks we have made a great deal of improvements in .NET inspections support. As a result .NET Inspections (powered by JetBrains ReSharper) and FxCop inspections runners produce much more clear results.

In case you missed, some time ago we announced new .NET inspections runner based on ReSharper inspections engine, and we already received feedback on it. Thanks to our EAP users we were able to fix a number of serious problems:
- LINQ usages are marked as unresolved symbols;
- TW-18724 NUnit attributes usages (and all External Annotations);
- TW-18730 Usages of resources in WPF, Silverlight projects.

Now the updated plug-in is available for download: follow the installation instructions and share your feedback with us.

As for FxCop runner, it now has a new setting – ‘FxCop version’.

It is really useful in case you have several FxCop versions installed in your build farm: selecting the version of FxCop to use in the runner settings will allow to keep the results consistent. If you’re not sure which FxCop versions you have installed, just go to Agents > Parameters Report page and use ’system.FxCopCmdFileVersion’ parameter name. You’ll get something like this.

Updated plug-in is available to download too.

Note that both plugins are compatible with the latest TeamCity 7.0 EAP and are not intended to work with earlier TeamCity versions.

Enjoy!

“I see dead code” – .NET developers all over the world know this slogan due to incredible code analysis feature provided by JetBrains ReSharper. One of the most wanted TeamCity features was to have .NET inspections results right on build server. Starting with the latest EAP you have it!

The only thing you need to do to get all the benefits of ReSharper’s analysis right in TeamCity is to add Inspections (.NET) build runner as a build step to your build configuration.

Configuration is quite easy, so let’s just take a look at how the results look when this runner is configured – you can find them at the dedicated “Code Inspections” tab of the build results.

Here we’ve got all the usuall options like exploring overal inspections statistic, opening problematic sources in IDE, viewing inspections description, etc.

Moreover, using this build runner together with another fresh feature – build failure conditions, you can update your builds status based on of inspections results.

What’s next? First of all, in the nearest future it will be possible to share ReSharper inspections settings profile between your team members and use this profile in TeamCity build. More to come, you will be able to ask TeamCity to run custom inspections related to your code base as well.

As always, your comments and feedback are very much welcome. To try it, install TeamCity 7.0 EAP build.

Enjoy!

New TeamCity 7.0 EAP build is ready and waiting for you to try! We have improved features introduced in the first EAP build, and of course we’ve got some completely new stuff.

.NET Inspections runner

Yes, it’s finally here and it’s based on powerful ReSharper code analysis engine! Now you can run .NET inspections and see the results right in TeamCity.

Global Maven settings

Previously you could specify path to alternative user settings file (equivalent to Maven command line option -s or –settings) in build configuration.  Now you can define these settings xml files globally in Server Configuration area, and use them in your Maven builds. When you create or modify a build configuration you will only need to select, whether you want to use default settings file (chosen by Maven), specified by path or global (uploaded on server). Since TeamCity stores these files under <TeamCity Data Directory>/config/_mavenSettings , you  can update them there whenever you need.

Per-check-in builds

If you have fast builds, you can now trigger them for each check-in, or for a group of check-ins made by the same user. Why? Thus you will see right away who broke what! When a build contains one check-in, or a couple of check-ins by one user, there can be no doubts, who’s responsible for a new failed test.  ;)

Fail build on a specific text in build log

We’ve already mentioned this feature in one of the recent posts, though we have improved it since then and we would like to hear your feedback on it.

Graph of commits

If your project uses Git or Mercurial you can see graph of commits on build configuration change log page. Graphs are also useful for non-DAG-based VCSs: they make it easier to understand where a VCS root modification comes from.

…and the rest gets only better!

We’ve improved, reworked and made better:

• Administration interface for Agent Pools
• Snapshot dependencies graph
• Tree view in build log
• NuGet integration
• and more…

Don’t forget to back up your TeamCity instance, try the build and help us make another one better for you!

Happy building!

Today I’d like to share with you a plugin for TeamCity 6.5 that provides support for NuGet, the open source developer focused package management system for the .NET platform. What does the plugin bring?

NuGet Packages Installer

The plugin adds dedicated build runner that allows you to:

• Install NuGet packages without having to check them in to the version control, which comes in handy especially when using a DVCS, like Mercurial or Git. The problem and a workaround is also covered in David Ebbo post.
• Automatically update package dependencies to the most recent ones (optionally).

Note, that for installing and updating packages we use NuGet.exe install and NuGet.exe update commands respectively.

NuGet Packages Tab

Once you start using NuGet Packages Installer in your build, you most likely will need to know the exact versions of packages used in the build, and that’s very easy to do – they are listed in the build results at the corresponding tab:

New TeamCity 6.0 EAP build is now available with Gradle support described in previous post and several new features and major improvements:

• Improved upgrade procedure. First of all, we have reworked the upgrade procedure. Though it already was quite painless, we’ve made it more explicit and smooth. Usually, a typical TeamCity upgrade requires conversion of database and configuration files. Since, previously this was performed automatically, it could be not clear what and why had happened. Now, when TeamCity decides that the data conversion is required, it asks for confirmation from server administrator and suggests to perform a backup (which we highly recommend in any case). Thus you’ll always know what’s going on, and when it’s time to back up your TeamCity instance. Automatic backup will be available, but only starting with version 6.0 or higher.
• Ability to explicitly select build configurations for an agent. Though TeamCity can distribute builds to agents based an agent requirements specified in build configurations, we know that some of our users prefer to explicitly specify which configurations can be built on which agents, and do not want to allow building of other configurations on these agents. That was possible in previous TeamCity versions, but starting with this EAP we have improved the UI for manual configurations selection. Give it a try! We believe, new UI has become better and more convenient, even if you have a huge number of build configurations.
• Auto-Completion in agent requirements. Now specifying agent requirements is easier and faster – just start typing a parameter’s name or value. Plus, you can see how many agents have this parameters defined, and with what values.
  
• JetBrains dotCover integration. Recently our .NET guys have released a brand new .NET coverage tool called dotCover, which includes lots of neat features, like reporting statement-level coverage in .NET Framework and Silverlight applications, highlighting for covered and uncovered code right in Visual Studio, detecting which tests cover a particular location in code and much much more. Starting with this EAP, this promising coverage engine is bundled with TeamCity and is available next to NCover and PartCover.
  
• and more…

See the release notes for complete list of changes, download the build and send us your feedback!

And as usual, don’t forget to back up your data!;)

Have you already tried multiple runners in latest TeamCity 6.0 EAP builds? If you have, there’s no need to repeat that now you can split the build procedure into steps and add as many build runners to be invoked sequentially as you need, for instance, call a NAnt script before compiling VS solutions. Having this approach implemented, we decided to review existing .NET runners in TeamCity.

As you know, TeamCity provides bundled support of NUnit and MSTest. In previous versions you could configure running such tests within MSBuild and VS.Solution build runners. That was reasonably good and handy solution for everyone to run unit tests without writing a line of script/code. Nevertheless, we removed NUnit and MSTest options from these runners. Don’t worry! You’re not going to miss them. Instead, we’ve introduced separate NUnit and MSTest build runners which you can now add as a build step to your configuration.

If you previously used to run the tests by means of MSBuild and VS.Solution build runners, you probably won’t even notice the difference, because such build configurations will be just split into two build steps during upgrade.

But here goes nice news for those who combined NUnit tests with Rake runner, NAnt, or for some other reason had to pick up some convoluted way to pass test reports to TeamCity, like using TeamCity NUnit launcher from command line, or service messages, or TeamCity addin for NUnit, etc. Now you can forget about all those tricky configurations and relax. Just add one more runner.
Of course, all old approaches will still work, but will remain mostly for exceptional cases.

Enjoy!

In the latest TeamCity 6.0 EAP we’ve added new feature to Visual Studio add-in. Now it is tightly integrated with another popular JetBrains product – ReSharper! So if you have both ReSharper 5.0 (or later) and TeamCity add-in installed, you gain the following benefits:

• From the add-in’s Failed Tests tool window you can navigate to source code of a failed test.
• From the same tool window, you can re-run tests failed in a TeamCity build locally with ReSharper.

Note, that by “tests” we mean all kinds of tests supported by TeamCity and ReSharper.

This feature is just the beginning, we plan to greatly improve TeamCity integration with ReSharper, so there’s more features to come. As usual, we’re looking forward to your feedback and all the feature requests are trully appreciated.

Stay tuned!

In the previous post about .NET coverage, we’ve told about configuring NCover/PartCover settings right in the web UI. This solution suits perfectly well for those, who use MSBuild, NAnt or Visual Studio (sln) runner. However, since version 5.1, you can get the coverage results displayed in TeamCity, even if you use a runner other than listed above.
If your build produces coverage report .xml files, you can populate your build script with simple service messages – and voila! TeamCity will merge those coverage reports, publish statistics and generate html-report for you.

Start with configuring TeamCity .NET Coverage reporting parameters in your build:

##teamcity[dotNetCoverage key='value']

where key is a .NET Coverage reporting parameter (the complete list of the values can be found in our docs).  Make sure to set up all parameters before reporting coverage .xml files.

Now, to pass generated coverage .xml files to TeamCity, use the following service message:

##teamcity[importData type='dotNetCoverage' tool='<tool name>' path='<path to the results file>']

where tool name can be partcover, ncover or ncover3. Hope, you’ll find it useful.

Stay tuned for TeamCity 5.1!

Sincerely, The JetBrains TeamCity team