Tag Archive for 'Tools'

Migrating from CruiseControl.NET to TeamCity 3.1

Published on June 2, 2008 in Coding. 0 Comments Tags: , , .

At my company, we’ve been using CruiseControl.NET as continuous integration system of choice for about one year now. Recently we switched from CC.NET to TeamCity, here are some points i noticed while migrating.

CC.NET offers lot’s of things and is very extendable, for instance we wrote a custom labeller to tag our continuous builds. One thing that was always pointed to by co-workers, is the fact, that everything is configured over XML files and for some people this was a mental barrier. The last CC.NET version was 1.3 which was released in June 07, since then there was no new release, imho this looked a bit like CC.NET stands on the holding track somehow.

As we migrated our Subversion repository to another server, we looked left and right for other CI solutions and then stumbled very soon upon TeamCity. TeamCity is a build management and continuous integration solution from JetBrains, supporting both Java and .NET developement teams. The professional edition is free up to 20 build projects, which is quite a bunch and probably enough for much small companies. And it’s completely configurable over a webinterface :-)

Our setup in CC.NET was the following: Per product we had one NAnt script and 2 CC.net projects. One of the CC.NET projects was used for continuous builds and was triggered with each commit to the SVN repository. The other project was triggered nightly and additionaly to the CI project all the AssemblyInfo.cs files in the project were updated with the current version number by the NAnt script, which resulted in dll’s being versioned. So these nightly builds we’re ready to be released as unstable versions to beta testing customers.

The versioning of the assemblies was quite dodgy in CC.NET and required some hacks. We used a similar approach for versioning as described in this post on bloggingabout.net. Stamping the files was actually not a problem, this can easily be done with a c# script task and some regexes within the NAnt file.

The more difficult point was, how do we get the version. We wanted a version number of the following format, major.minor.build.revision. The major and minor number were defined manually in the NAnt script.

Now for the buildnumber, we had a SVN repository containing a xml file with the purpose of containing always the next buildnumber to be used. In the NAnt script we defined a target called “extractbuildnumber” which made a svn checkout of that file into a temporary folder, xmlpeeked the buildnumber into an NAnt property, incremented the buildnumber by one and commited the XML file with the new buildnumber back to the repo.

To get the revision number we called svn log with the –xml parameter from our build script and xmlpeeked the revision number into a property.

This whole procedure got significant easier with TeamCity. For each build configuration in TeamCity you can define the build number format. Within this string you can reference the current build number(assigned by TeamCity itself) with {0} and the current revision number(read from SVN or whatever VCS you use by TeamCity) with {build.vcs.number.1}.

TeamCity Build Number

When running this build configuration, this string is evaluated and passed to the NAnt script (to Ant as well for sure) as a property named build.number. The whole process of extracting build and rev number like before with CC.NET gets obsolete with TeamCity. Another advantage of the configurable build number format is the labelling of the builds in TC. What had to be done in CC.NET with implementing ILabeller, can be done in one textbox in the webinterface using properties in TC.

Ah, one more thing to say! TeamCity has integrated diff. What we’ve done before with websvn and linking to it from CC.NET is all there in TeamCity.

All in all the migration was done within half a day and although we could do everything we wanted already with CC.NET, with TeamCity it’s just more fun :-P

HttpWebRequest over SSL with Fiddler running

Published on April 14, 2008 in Coding. 0 Comments Tags: , .

Fiddler is a very useful tool for capturing HTTP traffic. One can use it such as for figuring out what headers and POST-parameters are sent to a webserver when filling out a form. This information can then be used to programmatically create the same request to a webserver.

Fiddler is also able to decrypt SSL traffic. I used it recently to capture traffic over SSL sent by my browser and wanted then to use it again to check if my programmatic requests look the same as those from the browser. Because fiddler links itself as man-in-the-middle proxy between client and server, it also needs to provide a certificate for SSL requests. As this is not recognized as valid certificate, .NET throws an WebException at System.Net.HttpWebRequest.GetResponse() and no traffic shows up in fiddler.

To still be able to check accuracy of the programmatic requests with fiddler, it is possible to directly add a new delegate to ServicePointManager.ServerCertificateValidationCallback which always returns true:

//* Hack for debugging purposes to accept Fiddler certificate
ServicePointManager.ServerCertificateValidationCallback +=
delegate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors errors)
{
return true;
};
//*/

// Create request, write post parameters and so on..
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(“https://www.someurl.com”)