Build and Deployment automation, VCS Root and Labeling in TeamCity

An article by Laurent Kempé No Comments

As you might now from reading my blog I tend to automate as much as I can.

Why? Because I hate to do repetitive tasks. First because it is boring, at least for me, and as a developer we have more interesting things to do. Second because executing repetitive tasks tend to be error prone.

So last week I decided that it was enough for me to have to create manually a subversion tag for Jobpingweb site then also took the time to do the same for my portal Tech Head Brothers.

At Jobping we are using TeamCity and Subversion. We use it as our Continuous Integration system but also to deploy to production server in one click. Something I promised to talk later on in more details.

So it was relatively easy to configure TeamCity so that after build/deployment process it tags our subversion.

First of all, I realized only the other day the way TeamCity works with VCS root 

A VCS Root is a set of settings that defines how TeamCity communicates with a version control (SCM) system to monitor for changes and to get sources for a build.

We are using the convention of trunk, branches, tags in our Subversion server (which is the great Visual SVN Server). In the past I always set the TeamCity VCS Root to our myproject/trunk url, and I have seen lots of people doing so on different websites/blogs…

At this point I realized that I missed a point with TeamCity VCS Root is that it contains Root in it’s name. So I might be using myproject/ in place of myproject/trunk as the VCS Root. But wait, if I do that TeamCity agent will make a checkout of my whole Subversion repository!

And here comes the VCS Checkout rules, which you can configure on every project which is using the VCS Root

So in my case it looks like that

Which specify that for that particular build I want to checkout from my VCS Root extended with trunk to the build folder /. So with that I restrict the checkout to the trunk. Good

Now back to my first topic, which was to automate the subversion tag creation when our build is successful which is done using TeamCity VCS Labeling.

Here is how we set it up for our staging build

For sure we have another one for our production build.

And here is the result in Subversion

Another thing that I will not forget as it is automated

One last issue that I had which you see only if you register to get info about failed build in TeamCity is the following

[TeamCity, LABELING FAILED] Staging - CI Trunk, Unit Tests, Deploy #1072

Jetbrains.buildServer.vcs.VcsException:

Labeling the path 'trunk' to 'tags/staging-1072' has failed with the error: svn: MKACTIVITY of '/svn/!svn/act/7caf50f8-2801-0010-9e80-1fedd46c5a33': 403 Forbidden

With this error message it was then easy to figure it out. I just had to modify the access right of the build user to have read/write access right and not only read.

Using Gmail as TeamCity smtp server

An article by Laurent Kempé No Comments

Some time ago when I had to reinstall our Jobping Continuous Integration server, which is Team City I also decided not to reinstall any smtp server but to use Gmail server.

Here is the configuration that I used, which worked perfectly for me

Use SMTP port 465 and TLS (SSL) !

NDepend v3 - now 100% integrated in Visual Studio

An article by Laurent Kempé No Comments

Patrick just announced on his blog the launch of the new NDepend v3. It is still in beta but very stable. I am testing it for a month now and enjoy very much it’s integration in Visual Studio 2008. I was using it and will continue to use it in our continuous integration server, TeamCity. But getting feedback right out of the developer environment is a very interesting feature.

Read more on Patrick’s blog post, “NDepend v3 is now 100% integrated in Visual Studio“

Even on large code base, made of hundreds of thousands of lines of code and dozens of VS projects, Visual Studio is not noticeably slow down by the NDepend v3 addin.

VisualStudio 2010, 2008 and 2005

Simply put, what NDepend v2 does in the Continuous Integration/Build process, NDepend v3 does it live at development-time inside Visual Studio

Multi VS solutions wide-analysis and collaboration

Rich Code Search in VS

Multi CQL Query Edition in VS

Code visualization in VS

Continuous comparison with a base line in VS

Reflector disassembly’s comparison

Deep VS Integration

NDepend Session state preserved

Well done Patrick!

ClickOnce ISignedCode::Sign returned error: 0x80880253

An article by Laurent Kempé No Comments

Tonight we got the following issue on our TeamCity build server which produce different ClickOnce setups :

c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3652, 9): error MSB3482: An error occurred while signing: Failed to sign ..\..\Tests\Output\bin\DeployClickOnce\app.publish\setup.exe. 
SignTool Error: ISignedCode::Sign returned error: 0x80880253
    The signer's certificate is not valid for signing.
SignTool Error: An error occurred while attempting to sign: ..\..\Tests\Output\bin\DeployClickOnce\app.publish\setup.exe

Checking the certificate used by our project I found that the expiration date was yesterday:

So I had first to create a new test certificate.

Then I had to re-install the certificate on the server, as described in “ClickOnce certificate and TeamCity”. Before installing I had to remove the old one using:

> Psexec.exe -i -s cmd.exe

then running

> mmc

and removing by hand the old certifcate.

TeamCity 5.0 '​Failed to collect changes error' issue

An article by Laurent Kempé No Comments

Tonight I was facing an issue with TeamCity 5.0 plugin in Visual Studio 2008.

I was getting the error message '​Failed to collect changes error' in the new Local changes window.

Searching on the bug tracking tool of JetBrains for TeamCity I found this issue "TW-10474 I can not make VS addin recollect changes after recieveing '​Failed to collect changes error'”

Has this issue breaks my way to work with pre-tested build I decided to search for a solution because I cannot work without this now!

So following the instruction "Logging in TeamCity Visual Studio plugin" : Reporting Issues

Looking at the produced logs I found this:

9:28:24 PM.987: Thread:31: svn.exe info "xml" "non-interactive" "p:\@projects\_handsup\portal"
9:28:24 PM.987: Thread:31: Failed to execute svn. code 1, error svn: Try 'svn help' for more info svn: Syntax error parsing revision 'projects\_handsup\portal' , output <?xml version="1.0"?> <info>
9:28:24 PM.991: Thread:31: EXCEPTION: svn: Try 'svn help' for more info
svn: Syntax error parsing revision 'projects\_handsup\portal'.
Svn has exited with code '1'.
SvnInfoUuidCommand failed

I tried then the svn command from the command prompt and got the same error!

I finally renamed the path to my project from p:\@projects\_handsup\portal to p:\projects\_handsup\portal

And now it works again! So forget strange characters in your path!

TeamCity 5.0 Released!

An article by Laurent Kempé No Comments

JetBrains just published TeamCity 5.

The wait is over, ladies and gentlemen! The release build is baked, tested, and put on the shelf. Tastes good, so go and grab it now!

Let us write down a short summary of what was accomplished since the TeamCity 4.5 release.

First of all, here’s the list of most noteworthy features:

• Support for Amazon EC2: Take advantage of cloud computing with TeamCity by putting build agents on Amazon EC2 cloud with on-demand image starting and on-idle stopping.
• Issue tracker integration with JetBrains YouTrack, JIRA and Bugzilla - out of the box, plus an API for the integration plugins for other systems.
• Maven support improvements, including simplified build configuration creation from POM file, and build triggering on Maven artifacts change.
• Build configuration templates for eliminating redundancy in build configurations settings.
• Project archiving for putting no-longer-active projects out of sight.
• Command line tool for running Personal builds on server without IDE integration.
• Backup & Restore were added to simplify TeamCity maintenance. Also, migration tool was re-implemented.

Other improvements:

• Now you can view the status of a change across all build configurations on a single page.
• Failure responsibility feature has been advanced to cover not only builds, but also individual test failures.
• Various actions performed by TeamCity users are now stored in the Audit log, which can be browsed from the web UI.
• Code coverage analysis has been significantly improved for both Java (based on IntelliJ IDEA coverage engine) and .NET (support for NCover and PartCover).
• And many more

New and improved integrations:

• Git & Mercurial support are now bundled with TeamCity.
• Remote Run now works for Git from IntelliJ IDEA & Eclipse.
• New support for Cucumber, Shoulda, Test-Spec in Rake runner.
• TeamCity IntelliJ IDEA plugin now works with IntelliJ IDEA Community Edition and RubyMine 2.0.

Of course, this is not an exhaustive list, so check What’s New to get a full overview of new features and improvements.

As always, TeamCity 5.0 Professional is available for FREE for all small- and middle-sized development teams and can be downloaded at http://www.jetbrains.com/teamcity/download.

TeamCity 5.0 Enterprise is available for a 60-day free trial download at http://www.jetbrains.com/teamcity/download.

New customers can purchase TeamCity 5.0 online at http://www.jetbrains.com/teamcity/buy/.

Existing customers can upgrade to version 5.0 after purchasing a 1-year subscription for software updates at http://www.jetbrains.com/teamcity/buy/.

TeamCity licenses bought after October 1, 2009, receive a 1-year subscription for software updates for free, and therefore will work fine with TeamCity version 5.0. If you have such licenses, you will soon receive an e-mail with the new keys and certificates.

Build safe!

The JetBrains TeamCity Team

ProjectReference with Condition in your MSBuild project files

An article by Laurent Kempé No Comments

Since some time I have the current scenario where I need to have conditional reference in a project. Basically the application must reference an assembly in one case in other it should reference another one. This was working correctly from an MSBuild point of view as the first implemented solution let me compile and run the application on my development machine and it was also working for our TeamCity build server. So everything was fine in this perfect word expect one thing!

The issue was the following; Visual Studio was showing two references of the ‘same assembly’ with different path. Not really an issue you would say because the correct one was used at compile time and at run time in all configurations. So the issue was that this had an impact of ReSharper. And this is I cannot accept because it affect my productivity.

So the other day I had a discussion with Ilya of JetBrains which gave me some idea but also told me that ReSharper reads project structure out of Visual Studio and that it doesn't provide lots of info, e.g. conditions on references. So this is why seeing two reference of the ‘same assembly’ was not a problem on Visual Studio itself and on the build server but was an issue to ReSharper because it was seeing two same reference, same namespace, same classes…

Today I had some time free and decided to see where I can come with this issue. And I found a solution.

My first solution, which had the explained issue was the same as the one on this post “Don't be afraid of your csproj-Files (III): We have a condition”, so having a Condition on the ItemGroup.

The solution I came to is to bring the Condition to one upper level than the ItemGroup, so I used Choose like this:

Reloading the project I had the surprise to see only one reference and that ReSharper was working again correctly!

For sure the build on TeamCity is also working perfectly.

Displaying application version on TeamCity home page

An article by Laurent Kempé No Comments

I wanted today to display the application version in front of our builds, something I already did on the past but never with the VCS version.

In fact I used the same BUILD_VCS_NUMBER_<simplified VCS root name> that I described here: Build multiple ClickOnce deployment packages using MSBuild and Team City

Go in the General Settings of your build and adapt as following:

When your software is built it will now display the version:

Automating Publish of ClickOnce with TeamCity

An article by Laurent Kempé No Comments

The other day I published different posts about the way I automated our build process at Innoveo Solutions to generate different ClickOnce setup using TeamCity:

Build multiple ClickOnce deployment packages using MSBuild and Team City
Building ClickOnce with TeamCity
ClickOnce certificate and TeamCity
Build ClickOnce deployment packages using MSBuild and Team City

Yesterday I was asked to solve one minor issue. At ClickOnce publishing time the publish.htm file was not generated so the ClickOnce version number on the web page wasn’t shown. The publish.htm file is a static file on the targeted deploy directory and IIS uses that file. The file contains a hard coded version 2.0.0.x.

So from a user perspective it was difficult to know if there were a new version. So I was asked to show the correct version.

I knew from past research a way to handle this from the following post: How To: Generate publish.htm with MSBuild

But I went to a more pragmatic solution, as I already had the MSBuild Community Tasks.

I made a copy of Publish.htm to Publish.htm.ori on each targeted deploy directory.

Then I modified my MSBuild script to do the following:

1. Copy Publish.html.ori to Publish.htm
2. Use FileUpdate of MSBuild Community Tasks to search the 2.0.0.x string and replace it with the version

and the FullVersion is defined as this, using TeamCity BUILD_VCS_NUMBER, which is Latest VCS revision:

And now the Publish webpage display the version correctly!

Watch Several TeamCity Servers With Windows Tray Notifier

An article by Laurent Kempé No Comments

Browsing TeamCity documentation this evening I discovered that it is possible to Watch Several TeamCity Servers With Windows Tray Notifier

TeamCity Tray Notifier is used normally to watch builds and receive notifications from a single TeamCity server.

In situations, when you have more than one TeamCity server, and want to monitor them with Windows Tray Notifier simultaneously, you need to start a separate instance of Tray Notifier for each of the servers from the command line with the /allowMultiple option:

• navigate to TeamCity Tray notifier installation folder (by default, it's C:\Program Files\JetBrains\TeamCity and run the command:

  JetBrains.TrayNotifier.exe /allowMultiple

  Optionally, for each of the Tray Notifier instances you can specify explicitly the URL of the the server to connect to with the /server option. Otherwise, for each further tray notifier instance you will need to log out and change server's URL via UI.

  JetBrains.TrayNotifier.exe /allowMultiple /server:http://myTeamCityServer

See also details in the issue tracker.

So now I am able to have two TeamCity Tray notifier open:

What I also like is to be able to start programs by typing the Windows key and then some text, here for example “te”

To achieve this I created three shortcuts with the different servers configuration and then I placed the shortcuts in my folder C:\Users\Laurent\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu in which it is indexed.

Nice!