Inspired by a blog post from Roy Osherove – I wanted to be able to fire up additional build agents for peak times.
Yesterday Mario from Codeforce joined me to consult us on how to move Teamcity Agents into Amazon EC2. It took us two hours including lunch 
After our session Mario made a nice blog post on the Topic:
How to run the Build Process in the Cloud with Teamcity and Amazon EC2 « All about Cloud Computing
Now we can build LieberLieber AMUSE even faster
Just a found a tool that was missing in my Toolchain: Microsoft Build Sidekick from Attrice Corporation. Finally a nice and convenient tool to edit and debug MSBuild files that I use for my Teamcity work. It also supports the MSBuild Extension Pack.
If you choose to run Teamcity with a .sln you have an almost automatic integration into Teamcity that can be configured from the web interface.
For most stuff I end up needing a MsBuild Script to get all the Tasks done required for our Builds. If you choose MsBuild as a buildrunner in Teamcity you lose the nice GUI for configurating MsTest . So you need to run the tests by yourself with a simple target in an MsBuild script:
<Target Name=”MsTest”>
<Exec IgnoreExitCode=”true” Command=”"$(VS2008_Path)\mstest.exe" /testcontainer:BridgeTest.dll /resultsfile:BridgeTest.trx” />
<Message Text=”##teamcity[importData type='mstest' path='BridgeTest.trx']“/>
</Target>
The Trick is the Second Task which serves as a Service Message and tells Teamcity to Import the results from MsTest.
Other versions of running MsTest from MsBuild can be found in my previous post.
Mostly the same applies for Nunit Tests – yet you don’t need the Service Message because Teamcity can import Nunit reports from the gui.
Auf Nati Dobkin’s Blog habe ich heute einen Task für MSTest und eine super Aufstellung über die verschiedenen Varianten gefunden: MSTest task for MSBuild
Wenn man sich für die Commandline Variante entscheidet, sind auch noch die folgenden 2 Links interessant:
http://harriyott.com/2005/07/running-mstest-from-msbuild.aspx
http://geekswithblogs.net/michaelstephenson/archive/2007/04/27/112031.aspx
Buildserver und Continuous Integration sind nichts vor dem man Angst haben muß!! Es gibt auch komfortable Tools! ;)
Im letzten halben Jahr habe ich sehr intensiv mit Teamcity 4x von Jetbrains gearbeitet. Diesen BuildServer gibt es in einer kostenlosen und einer kostenpflichtigen Version. Ich finde dieses Tool einfach nur genial – vor allem wenn man sich über die Konfiguration von CruiseControl.Net geärgert hat.
Von der kommenden Version Teamcity 5 gibt es jetzt eine Preview im “Early Access Program” von Jetbrains! – Ich habe es schon auf einem Server in Betrieb und bin begeistert! Zum Beispiel kann man jetzt sogar eigenen HTML Reports integrieren ohne in XML Files editieren zu müsssen!
Ich hoffe mich endlich motivieren zu können mehr über Teamcity und MSBuild zu bloggen.
Heute hab ich was Lustiges/Ärgerliches entdeckt. Für alle, die Deployment Projecte und Buildscripts gemeinsam benutzen, folgender kleiner Hinweis auf eine potentielle Fehlerquelle. Wenn ihr den Productcode ändert und die Productversion erhöht, um ein Setup für eine neue Version zu bekommen, solltet Ihr auf das Guidformat aufpassen.
Es sieht vielleicht nur so aus aber, diese Guid:
{a50e0545-b0da-4a27-a832-93245837ee11}
entspricht nicht dem vom Deploymentproject gewünschten format von:
{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Zum besseren Verständnis das Deployment project file ist case sensitive und alle Guids sollten immer UpperCase sein also:
{A50E0545-B0DA-4A27-A832-93245837EE11}
Hoffe das hilft einigen weiter.
English:
Today I found something funny/annoying. For all who use Deployment prjects and Buildscripts, is the following little hint of a potential error. When you update the product code and increase the product version to get a setup file for you new version you should watch for the guid format.
It doesn’t look like it but this Guid:
{a50e0545-b0da-4a27-a832-93245837ee11}
does not match the expected format of the deployment project of:
{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
To assist in the understanding the deployment project file is case sensitive and all guid’s have to be UpperCase, therefore:
{A50E0545-B0DA-4A27-A832-93245837EE11}
Hope this will help some of you.
Wie bereits angekündigt habe ich eine MSBuild Integration für EA gebaut.
Dieses Addin bietet die Möglichkeit MSBuild Dateien in EA zu importieren und mit Hilfe der dazugehörigen MDG Technology, dessen Konfigurationen graphisch darzustellen. Als weiteres Feature wurde ein “Element type choose” Dialog eingebaut, mit dem man einfach aus einer Liste z.B.: MSBuild Task Types auswählen kann (Copy, Delete,…). Auch werden alle “required attributes” automatisch angefügt und mit Hilfe des “Attribute” Features können weitere “optional attributes” ausgewählt werden.
Natürlich gibt es auch eine Export funktion, um wieder ein MSBuild File erstellen zu können.
(Alle MSBuild Types und Attribute werden aus der MSBuild Schemadatei ausgelesen)
Und nun zur MSBuild Demo bzw. zum Download …. MSBuild Integration
English:
As announced in a previous entry I developed a MSBuild Integration for EA.
This addin gives you the possibility of importing MSBuid files into EA and with the appendant MDG Technology EA can visualize the MSBuild configurations. As an additional feature I implemented an “Element type choose” dialog, so you can easily choose from a list of e.g. MSBuild Task Types (copy, delete,…). Also all “required attributes are automatically added and with the “Attribute” feature you even can choose “optional attributes”.
Of course there is an export function, to get your MSBuild file again.
(All MSBuild types and attributes are taken from the MSBuild schema file.)
And now for the MSBuild Demo and respectively the Download …. MSBuild Integration