Setting up Code Coverage Analysis in TeamCity

If you are using Visual Studio 2015 Professional Edition, unfortunately, you are out of luck when it comes to getting Code Coverage of your Unit Tests since this is only available in Visual Studio Enterprise edition (https://www.visualstudio.com/en-us/products/compare-visual-studio-2015-products-vs.aspx)

However, Jetbrains TeamCity has provided a solution for those development teams lacking licenses to Visual Studio 2015 Enterprise Edition in the form of dotCover!

dotCover is bundled for FREE with Jetbrains TeamCity and can be used to perform Code Coverage Analysis of your Unit Tests.

For information on how to set up dotCover to run Code Coverage for your Unit Tests, you can check out this article: https://confluence.jetbrains.com/display/TCD10/JetBrains+dotCover

Unfortunately, one of the main limitations of TeamCity documentation is the lack of screenshots for how to accomplish a particular task.

Thankfully, though, this blog article addresses that gap by providing screenshots of just how to configure dotCover within TeamCity: https://blog.jetbrains.com/dotnet/2010/12/10/coverage-with-dotcover-teamcity-mstest-nunit-or-mspec/

Once you have set everything up correctly, you will end up with Code Coverage Reports in TeamCity like the following:

Add xUnit.Net support to TeamCity

If you want to run your xUnit.Net Unit Tests to your TeamCity Builds, you can accomplish this quite conveniently using the xUnit.Net TeamCity plugin.

You can download the latest release of the xUnit.Net TeamCity plugin from here: https://github.com/carlpett/xUnit-TeamCity/releases/tag/1.1.3

Once you have installed the TeamCity plugin, you will be able to use xUnit.Net as a TeamCity Build step as follows:

That is all there is to it!!

Using the FxCop Build Runner in Jetbrains TeamCity

If you want to use the FxCop Build Runner in Jetbrains TeamCity, you can consult the documentation here: https://confluence.jetbrains.com/display/TCD10/FxCop

For the path to FxCop, using the option for "Autodetect installation" should work well for you in most cases:

In some cases, if you have multiple versions of Visual Studio installed on your machine, you may want to select a specific version of FxCop:

• For Visual Studio 2013, you will select 12.0
• For Visual Studio 2015, you will select 15.0

For the list of Assemblies, you can specify a relative path to the assemblies by using a wildcard expression such as *.dll.  Of course, since you are probably compiling a solution with multiple projects, you will want to specify the path to each set of assemblies in your solution such as MyProject\bin\MyProject.dll, MyProject2\bin\MyProject2.dll as follows:

You need to make sure that the names of your assemblies are all SPACE SEPARATED in order to ensure that FxCop runs correctly against them.

You must then configure the Advanced Options for FxCop in order to be able to run correctly against referenced assemblies etc.:

I like to specify the path to "Search referenced assemblies in directories" and uncheck the option for "Search referenced assemblies in GAC".  This is especially relevant since I distribute most of my assembly references through NuGet packages rather than installing them into the GAC.

Optionally, you can also configure the "Build Failure Conditions" such that any "Fail on analysis errors" in FxCop will also trigger a failure of the build

Personally, I avoid this setting since I generally work with offshore development teams which do not run regular code analysis on their projects/solution nor may they be licensed to run Code Analysis on their solution with their edition of Visual Studio.  Visual Studio 2015 Professional and above now offers Code Analysis and Code Metrics, but earlier editions of Visual Studio such as Visual Studio 2013 did not.  However, setting this value can potentially be disruptive to any team which is not very particular about following all of the guidelines outlined by FxCop.

Finally, once you have specified the correct path for your build, you will be able to use the TeamCity FxCop Build Runner to generate a Code Inspection report!

You can access the Code Inspection report from the "Build shortcuts" dropdown menu:

Handling spaces in Git Urls using TeamCity

If you are using Team Foundation Server/Visual Studio Online for your Git repository, there is a good chance that you may end up with spaces in your Git repository Url!

This is because TFS/VSO uses the Project Name as the method to generate the Git repository Url.

Unfortunately, this presents an immediate problem for TeamCity because spaces in Urls are translated as the %20 character!  Once you run a build in TeamCity with a Url containing these characters, the build on the build agent will fail with an error such as this:

"20Reports defined in VCS Root: VSO Reports"

Thankfully, there is a solution to this problem even though it is not perfect. To workaround around this problem, you simply escape the %20 characters with an additional % sign like so in your VCS Url:

VSO%%20Reports

This should resolve the issue with being able to execute a build with a VCS Url that contains spaces.

However, you may still end up with an error message like this in your build log beneath the Artifact dependencies:

Parameter "20Reports" is undefined

You can ignore this error message in the build log, but hopefully the Jetbrains TeamCity development team will fix this issue completely in the near future!

Running Visual Studio Unit Tests in TeamCity

As I start writing Unit Tests for my application, I usually also want to ensure that all of my Unit Tests are also passing whenever I check in my code!

The easiest way to accomplish this is to integrate the execution of my Unit Tests within TeamCity is to add a "Visual Studio Tests" build step:

Once you add the Visual Studio Tests Build Step, you will need to add the paths to the Unit Test assemblies.  I usually like to create TeamCity parameters and then pass the list of Unit Test assemblies to the Visual Studio Tests Build Step.

However, even though it is stated in the TeamCity User Interface and documentation that you can pass multiple Unit Test assemblies by including each path on a separate line, this has been quite unreliable since in a long list of Unit Test assemblies, any problems are not reported if those Unit Test assemblies are missing!  Therefore, I prefer to create separate Build Steps for each of my Unit Test assemblies to ensure I am able to see any errors that occur with any of my Unit Tests:

That is all there is to it!!

TeamCity server requires technical maintenance

With the recent release of TeamCity 10.0, I decided to upgrade my TeamCity instance when I suddenly saw this message:

Based on the information provided in the message, I would have to check the teamcity-server.log for the Maintenance Authentication Token.

So where is that log file exactly?

It can be found here for most installations of TeamCity: C:\TeamCity\logs\teamcity-server.log

Deploying Releases using Octopus Deploy and Jetbrains TeamCity

If you are using Octopus Deploy for your Release Management process, you can use the Octopus Deploy TeamCity plugin to assist in your deployments!

You can read about the TeamCity plugin here: http://docs.octopusdeploy.com/display/OD/TeamCity

Using Octopus Deploy provides many benefits over standard script-based deployments as outlined here: https://blog.jetbrains.com/teamcity/2015/11/automating-deployments-with-teamcity-and-octopus-deploy/

You can use one of 4 different build steps in TeamCity:

• Create Release
• Deploy Release
• Promote Release
• Push Packages

The most common build steps you will probably use are the "Create Release" or "Deploy Release" build steps:

One of the unfortunate parts of these build steps, however, is that the API Key does not allow parameterization, so you have to either enter this API Key manually each time or else derive from a Build Configuration Template in order to be able to inherit this property.  All other parameters in this build step can be parameterized readily through TeamCity.

Performing a TeamCity Project Restore

In recent releases of Jetbrains TeamCity, a "Projects Import" feature has been provided which allows you to restore most of your data from one TeamCity installation to another.

The process requires you to first take a Backup of the TeamCity installation which is then stored as a .zip file in the TeamCityData\backup directory.

I recently had to migrate TeamCity from one server to another, so I decided to try out this feature for myself.

When you first get to the Projects Import screen, you are informed that you need to place the backup .zip file in the TeamCityData\import directory (which did not already exist on the system).  Consequently, I manually created the import directory and placed my most recent backup file into it.  After refreshing the screen, TeamCity readily found my backup file:

After I clicked on "Configure Import Scope", I was prompted for the information that I needed to import into TeamCity:

After selecting "Start Import", my import process started and my project was restored!

I looked over my project build configurations and everything seemed in order just as it was configured on my earlier server.

Of course, I quickly discovered that the reason that this feature is called "Projects Import" is because it is not a full TeamCity restoration!

I discovered several items that I had configured on my other TeamCity server to be missing:

• Email Notifier
• Notification Rules
• NuGet
• Plugins such as Octopus Deploy and Visual Studio Online Work Items
• Issue Tracking integration dependent on my Visual Studio Online Work Items plugin

Therefore, while this is not a comprehensive restoration of a TeamCity installation from one server to another, it does a fairly good job of retaining all of the information needed for a project to perform continuous integration builds!!

Integrating TeamCity with Visual Studio Online Work Items

If you want to integrate Jetbrains TeamCity with Visual Studio Online Work Items, unfortunately, TeamCity does not provide this functionality out-of-the-box.

However, you can still link these 2 systems together using a TeamCity plugin as outlined in this article: https://blog.jetbrains.com/teamcity/2014/11/integrating-teamcity-and-visual-studio-online-work-items/

You can obtain the Visual Studio Online Work Items plugin from here: https://confluence.jetbrains.com/display/TW/Visual+Studio+Online+Work+Items

Reading the article is a bit confusing as to where to obtain the plugin, so I am providing the direct link here: https://teamcity.jetbrains.com/project.html?projectId=TeamCityPluginsByJetBrains_VisualStudioOnlineIssueTrackin

You then have to click on the link for "Artifacts" and then download the .zip file appropriate to your version of TeamCity.

 Once you upload the Visual Studio Online plugin and re-start your TeamCity Server and TeamCity Build Agent, you should see a screen similar to the following:

Then, once you go into your Project and select Issue Trackers, you should now have an option for Visual Studio Team Services:

Next, you can simply add your settings for Visual Studio Online:

You should then fill out the screen with information similar to the following:

Finally, you can test the connection to make sure all of your settings are valid and you should get a result similar to the following:

Finally, your newly configured Issue Tracker with Visual Studio Online Work Items should show up in TeamCity like this:

TeamCity Build Agent path causes problems in PowerShell build runner

I was recently working with an installation of TeamCity that was installed into the Program Files directory when I discovered that none of my PowerShell scripts were working properly!

This was the error message I was receiving:

[Step 3/3] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[21:09:28][Step 3/3] Working directory: D:\Program Files\TeamCity\buildAgent\work\2f8c6ee9aa79151b
[21:09:28][Step 3/3] PowerShell arguments: [-NonInteractive, -ExecutionPolicy, ByPass, -File, D:\Program Files\TeamCity\buildAgent\temp\buildTmp\powershell3015355379462820230.ps1, -SrcDir:"D:\Program Files\TeamCity\buildAgent\work\2f8c6ee9aa79151b\src", -DestDir:D:\Websites\MyWebsite]
[21:09:28][Step 3/3] D:\Program
[21:09:28][Step 3/3] Files\TeamCity\buildAgent\temp\buildTmp\powershell3015355379462820230.ps1 : A
[21:09:28][Step 3/3] positional parameter cannot be found that accepts argument
[21:09:28][Step 3/3] 'Files\TeamCity\buildAgent\work\2f8c6ee9aa79151b\src'.
[21:09:28][Step 3/3]     + CategoryInfo          : InvalidArgument: (:) [powershell3015355379462820
[21:09:28][Step 3/3]    230.ps1], ParentContainsErrorRecordException
[21:09:28][Step 3/3]     + FullyQualifiedErrorId : PositionalParameterNotFound,powershell3015355379
[21:09:28][Step 3/3]    462820230.ps1
[21:09:28][Step 3/3] 
[21:09:28][Step 3/3] Process exited with code 0

Well, as it turns out, this is a flaw/defect in the current version of TeamCity (v. 9.1.7 as of this writing) that does not escape the PowerShell paths correctly!

You can track the status of this issue here: https://youtrack.jetbrains.com/issue/TW-45785

Of course, one workaround is to simply uninstall the TeamCity Build Agent into a path that does not contain spaces in the path. 

Another workaround was suggested by the TeamCity staff:
After further investigation, we have found, that if the parameters are passed to the script in the form -paramName:paramValue, TeamCity does not handle their escaping correctly.  For now, I suggest that in your script you use the format -paramName -paramValue (with space instead of :).   So the value of the 'script arguments' field will look like this: -SrcDir "%system.teamcity.build.workingDir%\src" -DestDir %system.DestDir%

As for me, I chose to simply re-install the build agent into a standard directory such as C:\TeamCityBuildAgent, and then my PowerShell build runner worked just fine!

Uninstalling a TeamCity Build Agent

If you look for documentation on TeamCity Build Agents, you will probably come across this article: https://confluence.jetbrains.com/display/TCD9/Setting+up+and+Running+Additional+Build+Agents

However, one of the things that you will find missing in the article is how to UNINSTALL a TeamCity Build Agent (particularly on Windows)!!

Fortunately, this is relatively easy to accomplish thanks to a set of batch files that are stored in the bin directory of the build agent.

Instead of running the service.install.bat file to install a Build Agent as a service, instead, you simply run the service.uninstall.bat file to uninstall the TeamCity Build Agent!

Then, you can go ahead and re-install the Build Agent as you please!!
 

 

Change the port number for Jetbrains TeamCity

I recently encountered a port conflict for Jetbrains TeamCity when I was running TeamCity on port 8080 which required me to change the port on which TeamCity was running.

Therefore, I needed to figure out how to change the port number without having to completely re-install TeamCity!

Fortunately, this is relatively easy to do based on this article:  https://confluence.jetbrains.com/display/TCD9/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-ChangingServerPort

I simply had to go into the <TeamCity home>\conf\server.xml file and edit it in my favorite text editor to my new desired port number.

Once I did that, I had to re-start my TeamCity Server and TeamCity Build Agent services and I was up and running on my new port number!

Setting up Issue Tracking integration with Jetbrains TeamCity

If you want to integrate TeamCity with an Issue Tracking system such as Bugzilla, JIRA or YouTrack, fortunately, you can accomplish that rather readily using the built-in integration with these Issue Trackers in TeamCity!

You can read about how to set up this integration here: https://confluence.jetbrains.com/display/TCD9/Integrating+TeamCity+with+Issue+Tracker

If you are specifically looking to integrate with a specific Issue Tracker such as JIRA, then you can check out this documentation: https://confluence.jetbrains.com/display/TCD9/JIRA

So, to get started with setting up the Issue Tracker integration, you need to click on your Project Settings in TeamCity.  In the left hand navigation, you will see a link for Issue Trackers:

You will then want to click on "Create new connection":

You can then choose an Issue Tracker such as JIRA:

You can then enter all of your relevant JIRA information to link up the Issue Tracker:

If everything connects properly, you should now see the Issue Tracker in the TeamCity Project Settings:

Now whenever your development team checks-in source code along with a code comment that includes the ID of the JIRA Issue, you will see a link DIRECTLY to that specific JIRA Issue from that particular TeamCity build!

That is all there is to it!

Resolving NuGet Assembly Reference errors in Jetbrains TeamCity

If you have ever encountered an error similar to the one below in Jetbrains TeamCity, then you have a problem with NuGet Assembly References:

Thankfully, this is easily resolved using the NuGet Restore feature available as a Build Step within TeamCity.  You simply add a new Build Step using the NuGet Installer Build Runner:

Next, when you order the Build Steps, you just need to make sure that you run the NuGet Restore Build Step prior to building your actual Visual Studio solution as follows:

It is easy as that to resolve your NuGet Assembly Reference errors in TeamCity!  

Changing the Assembly Version using Jetbrains TeamCity

If you are using a process outside of Jetbrains TeamCity to manage your assembly version information, then you may end up using a process that leverages MSBuild to alter AssembyInfo.cs files or GlobalAssemblyInfo.cs files.

In the past, I have used MSBuild Extension Pack with the AssemblyInfo task to accomplish this: http://msbuildextensionpack.com/

However, since I am using Jetbrains TeamCity as part of my CI build processes, I can use the AssemblyInfo Patcher Build Feature instead!  https://confluence.jetbrains.com/display/TCD9/AssemblyInfo+Patcher

This can be done as follows:

Since this runs before the 1st build step it requires no changes to your existing build steps and configuration!

Pretty awesome, huh??

Grant Administrative privileges to user accounts in TeamCity

If you are attempting to grant Administrative privileges to user accounts in Jetbrains TeamCity, it is not as readily obvious as you would think.

Under Administration for the specific User Account, there is a checkbox for "Give this user administrative privileges"

You check that checkbox and now that user has administrative rights in TeamCity!

Available Plugins for TeamCity

If you are looking for information about some of the Plugins in TeamCity as well as how to install Plugins in TeamCity, you can check out this article: https://www.jetbrains.com/teamcity/plugins/

For a comprehensive list of available TeamCity Plugins, you can check out this link: https://confluence.jetbrains.com/display/TW/TeamCity+Plugins

The Plugins labeled with a JB icon are Plugins provided directly by Jetbrains while other Plugins are provided by various 3rd party developers/companies.

Figuring out Build Parameter values in TeamCity

If you work with build parameters in TeamCity, you may configure your own build parameters, or you may end up using the built-in build parameters that TeamCity provides.

The problem with using TeamCity's build parameters though is that it is not easy to determine what the expected values are based on their names!

So how exactly do you figure out what the values are for each of these pre-defined build parameters?

Quite easily in fact!  You simply run a build in TeamCity for your build configuration!

Now, when you go into the dialog for the completed build, you will see an option for "Parameters"

When you click on Parameters, you will see a list of all the values populated for the TeamCity Parameters:

Now, you can see all of the values that TeamCity is using for all of the various parameters and you can use them accordingly in your build steps and build configurations!

Adding additional Jar files to Ant ClassPath in TeamCity

I recently began working with Java again after a period of many, many years and had to start working with Ant to perform some Java builds.

Well, I soon discovered that, unlike MSBuild, Ant does not have a built-in XMLTask!!

There is a company that has provided this functionality to Ant in the form of a separate .jar file called xmltask.jar.  http://www.oopsconsultancy.com/software/xmltask/  On the downside, since this is not included as part of Ant, you have to specify the path to the .jar file while you are building your Ant script.

TeamCity supports this through Ant command line parameters in the Ant Build Step:  https://confluence.jetbrains.com/display/TCD9/Ant

You specifically need something like the following line to reference your additional Ant libraries:
-lib "%teamcity.tool.ant-net-tasks%"

In my case, I ended up using the following path:
-lib C:\BuildTools\xmltask.jar

That was all that was needed to get my Ant build script to build!!



 

Understanding TeamCity Checkout Rules

At some point in time while using TeamCity, you may find that you need to provide checkout rules to control the directory or directories in which TeamCity pulls code from your source control tree (VCS Root).

Well, if you read over the dialog for the checkout rules, you may find this very confusing at first:

If you read over the TeamCity documentation on using checkout rules, it is only slightly more helpful: https://confluence.jetbrains.com/display/TCD9/VCS+Checkout+Rules

Therefore, what is an actual example of how to use checkout rules?

In this dialog, I am using +:. (the . means the root of the checkout directory) and mapping it to a Common directory by using the => notation. 


Thus, TeamCity will create a Common directory on the file system before pulling the source code from the VCS Root/Source Control Repository.  Then, it will automatically take the contents of the VCS Root and place it in the Common directory instead of in the root of the build checkout/build working directory. 

That is all there is to it!!

Simpler than you thought, huh???