CCNetConfig ist eine kostenlose UI für das Editieren der CruiseControl.NET config-Files.

Allerdings liefert CCNetConfig unter Windows x64 (egal ob Vista oder Windows 7) beim Öffnen eines Config-Files die Fehlermeldung:

System.ArgumentException: The path is not of a legal form.

Das Problem ist hier beschrieben:

http://ccnetconfig.codeplex.com/WorkItem/View.aspx?WorkItemId=10848

und soll angeblich bereits gefixt sein (was allerdings offensichtlich nicht der Fall ist).

Der Workaround ist relativ einfach:

Im Windows SDK Ordner (z.B. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin) muss die corflags.exe mit dem Parameter 32bit+ ausgeführt werden, also

corflags CCNetConfig.exe /32bit+

Danach läuft CCNetConfig auch unter x64.

“Welche Version verwenden Sie denn?”

Wenn man einen Fehler in einer .NET Assembly sucht, ist es natürlich wichtig zu wissen, welche Version der DLL man vor sich hat.

Mit gutem Beispiel vorangehen

Umso wichtiger ist es natürlich auch, dass man Assemblies, die man selbst erstellt, mit einer nachvollziehbaren Versionsnummer versieht.

Eine Versionsnummer besteht in der Regel aus einer Hauptversion, einer Nebenversion, einer Build-Nummer und einer Revisionsnummer und sieht z.B. so aus:

1.2.0.317

Die Versionsnummer von .NET Anwendungen befindet sich in der Datei Properties\AssemblyInfo.cs des jeweiligen Projekts.

Relevant für die Versions-Info der DLL ist der Eintrag

[assembly: AssemblyVersion( "1.0.0.0" )]

Dieser Eintrag kann von Hand gepflegt werden, z.B. nach jedem Commit in eine Versionsverwaltung wie Subversion.

“Sollen wir uns darum auch noch kümmern?”

Allerdings kommt man sehr schnell an den Punkt, an dem man die Aktualisierung vergisst oder bewußt unterlässt, da der Aufwand schnell wachsen kann.

Besonders bei der Entwicklung im Team ist die Pflege von Hand praktisch nicht praktikabel.

Außerdem möchte man z.B. die Versionsnummer nur erhöhen, wenn der Build erfolgreich war.

Die Automatisierung der Versionierung stellt allerdings kein Problem dar, wenn man Continuous Integration verwendet (siehe auch grüner Grad bei Clean Code Developer) – z.B. mit dem kostenlosen CI-Server CruiseControl.NET (CC.NET).

Für CC.NET gibt es sog. Labeller, die einen Build, der mit CC.NET erzeugt wurde, eindeutig kennzeichnen können.

Versionsnummern leicht gemacht mit svnrevisionlabeller

Verwendet man als Versionsveraltung Subversion (SVN) zusammen mit CC.NET, kann man o.g. Versionsnummernschema erzeugen, indem man den svnrevisionlabeller von David Keaveny verwendet.

Dieser generiert nach einem frei definierbaren Schema eine Versionsnummer, die er CC.NET übergibt, welcher den jeweiligen Build dann mit diesem Label versieht.

Wie kommt man nun zu einem solchen Label mit svnrevisionlabeller?

Nach dem Download der entsprechendenVersion(vor CC.NET 1.4.3 oder danach), kopiert man die

ccnet.SvnRevisionLabeller.plugin.dll in das Unterverzeichnis

server

der CC.NET-Installation.

Danach ergänzt man in der ccnet.config (nicht ccnet.exe.config) im gleichen Verzeichnis den <project />-Eintrag um einen Child-Node, der wie folgt aussieht:

<labeller type="svnRevisionLabeller">       <url>svn://svn.meinprojekt.de/meinprojekt/trunk/PfadZumCode</url>       <major>0</major>       <minor>0</minor>
  </labeller>

Nach einem Neustart der ccnet.exe oder des CC.NET-Dienstes, werden die Builds ab sofort mit dem neuen Versionsschema gekennzeichnet.

“Welche Version haben wir denn nun?”

Wirft man allerdings einen Blick auf die generierten Assemblies des Builds, stellt man fest, dass die Versionsinfo hier noch nicht erscheint.

Der Grund hierfür ist, dass der CC.NET-Versionslabel nur innerhalb von CC.NET verwendet wird.

Abhilfe schafft hier ein MSBuild-Task, der vor dem eigentlichen Build die Datei AssemblyInfo.cs mit den Infos aus dem CC.NET-Versionslabel aktualisiert.

Der besagte MSBuild-Task ist in den sog. MSBuild Community Tasks enthalten, die man z.B. in ein Verzeichnis

“Tools”

im Projekt-Baum kopiert.

Im Build-Skript wird die MSBuild Communit Tasks Assembly nun importiert ($(MSBuildCommunityTasksPath) verweist auf das Tools-Verzeichnis):

<Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets" />

Den AssemblyInfo-Task bindet man dann als Target in das Build-Skript ein und definiert die Parameter entsprechend:

<Target Name="BeforeBuild">   <AssemblyInfo Condition="'$(CCNetLabel)' != ''" CodeLanguage="CS" OutputFile="$(ProjectDir)\Properties\AssemblyInfo.cs" AssemblyTitle="Meine Assembly" AssemblyCompany="Meine Firma" AssemblyProduct="Mein Projekt" AssemblyCopyright="Copyright ©  2009" ComVisible="false" Guid="fb6d275e-96df-4ea5-b046-d77a3557c1a2" AssemblyVersion="$(CCNetLabel)" AssemblyFileVersion="$(CCNetLabel)" />

  </Target>

Wenn man nun das Target “BeforeBuild” noch entsprechend in die Reihenfolge des Builds (per CallTarget) integriert, stehen nach dem nächsten Build die aktuellen Informationen in den erzeugten Assemblies.

Wie bereits an verschiedenen Stellen berichtet wurde (siehe “Blogeinträge” am Schwarzen Brett), fand am vergangenen Wochenende vom 11. – 12. Juli der erste .NET Open Space Süd in Blaustein bei Ulm statt.

Für Thomas und mich als Veranstalter ist es schön zu sehen, dass wir mit der Form der Veranstaltung offenbar den Nerv der .NET Community getroffen haben und die angemeldeten Teilnehmer fast vollständig erschienen sind.

Bereits am Freitag Abend trafen mehr Teilnehmer als erwartet zum “Kennenlern-Treffen” im Schwarzbrenner ein und bereits hier enstanden interessante Diskussionen rund um .NET (fotografiert von Albert):

Am Samstag konnten wir fast pünktlich mit den von den Teilnehmern vorgeschlagenen Sessions starten, die da waren:

Nach der letzten Session wechselten wir wie bereits zum Mittagessen die Straßenseite zum Sportheim des SV Arnegg, der während der beiden Tage rundum reibungslos für unser leibliches Wohl sorgte.

Dank des trockenen Wetters konnte wie geplant die Grill-Party im Freien stattfinden.

Mit Einbruch der Dunkelheit wurden die Teilnehmer zunächst mit einem Bauchtanz unterhalten.

Im Anschluß daran fand eine imposante Feuershow statt, die offensichtlich jeden begeisterte (fotografiert von Peter):

Danach fanden im Sportheim selbst noch etliche interessante Diskussionen statt, die bis ca. 2 Uhr andauerten.

Am Sonntag starteten wir aufgrund der kurzen Nacht etwas später als geplant und behandelten folgende Themen:

Im Anschluß wurde noch Alberts Idee diskutiert, einen Code .NET Open Space zu veranstalten – man darf gespannt sein, wie sich das Thema entwickelt, denn das Feedback war durchwegs positiv.

Aufgrund vielen positiven Rückmeldungen seitens der Teilnehmer haben wir uns entschieden, auch im nächsten Jahr wieder einen .NET Open Space Süd zu veranstalten – hoffentlich wieder mit so vielen engagierten Teilnehmern und interessanten Themen wie am vergangenen Wochenende, ohne die diese Veranstaltung so nicht zustandegekommen wäre – danke hierfür.

Ausdrücklich bedanken möchten wir uns auch nochmals bei den Mitgliedern des SV Arnegg, die uns nicht nur in ihrem Sportheim mit regionalen Köstlichkeiten betreut haben, sondern auch in den Räumen der artiso AG, in denen die Veranstaltung stattfand, permanent mit Getränken, Snacks und natürlich Kaffee versorgten.

Ebenfalls gedankt sei an dieser Stelle nochmals Torsten und Alex für die Bereitstellung der Open Space Website und die Unterstützung während der Organisation.

Zu guter letzt möchten wir uns auch bei unseren Sponsoren bedanken, die diese Veranstaltung durch ihre finanzielle Unterstützung ermöglicht haben und die Preise für die Verlosung am Samstag gestiftet haben.

Vielleicht trifft man sich ja bereits beim .NET Open Space 2009 im Oktober in Leipzig wieder ;-)

Morgen, am 06.07.2009, findet um 21:00 Uhr das nächste European Virtual ALT.NET (EVAN) Meeting statt.

Alan Dean gibt eine Einführung in das Thema REST – wer sich damit bereits befasst und konkrete Fragen hat, kann diese in der E-VAN Google Group in diesem Thread posten.

Das Meeting dauert bis ca. 22:30 Uhr.

Die Teilnahme ist wie immer unter der URL http://snipr.com/virtualaltnet möglich.

Wer sich über die kommenden E-VANs informieren möchte, findet hier einen E-VAN Kalender.

Wie ich vor einigen Tagen bereits geschrieben hatte, gefallen mir die Libraries in Windows 7 sehr gut.

Allerdings haben die Libraries in Verbindung mit TortoiseSVN einen gravierenden Nachteil: TortoiseSVN oder genauer: die Integration von TortoiseSVN in den Windows Explorer funktioniert in Libraries nicht, d.h. die gewohnten Menü-Einträge wie z.B. “SVN Checkout...” fehlen im Kontextmenü:

Dieses Verhalten ist bei den TortoiseSVN-Entwicklern bekannt, wie man hier nachlesen kann.

Einzige Abhilfe, die ich bisher gefunden habe, um die Libraries weiterhin verwenden zu können:

Anstelle eines Rechtsklicks auf den leeren Bereich in einem Ordner, ruft man das Kontextmenü des Ordners auf, denn dort klappt die TortoiseSVN-Integration nach wie vor:

VisualSVN funktioniert übrigens problemlos mit den Libraries:

Die in Windows 7 eingeführten Libraries haben mich vom ersten Moment an begeistert:

Libraries erlauben es, mehrere Ordner zu einer logischen Einheit zusammenzufassen – bei mir sind in der Library “Development” z.B. sämtlicher Code, Dokumente (Docs) und Projekte (Projects) zusammengefasst.

Da ich diese Library sehr häufig verwende, habe ich mir diese in der Taskbar von Winodws abgelegt – allerdings ging das nicht ohne Umwege.

Wenn man eine exe-Datei rechtsklickt, hat man die Möglichkeit, diese direkt in die Taskbar zu docken:

Leider besteht diese Möglichkeit bei Ordnern und Libraries nicht.

Deshalb erstellt man sich zunächst z.B. auf dem Desktop eine neue Textdatei und benennt diese so um, wie die Library auf der Deskbar später heißen soll – mit dem Zusatz “.exe”:

Diese kann man nun über den oben gezeigten Rechtsklick an die Taskbar pinnen:

Allerdings startet ein Klick auf das Icon nun die vermeintliche exe-Datei und das Icon könnte auch aussagekräftiger sein…

Um dies zu ändern, hilft ein Rechtsklick auf das Symbol in der Taskbar und anschließend die Auswahl der Dateieigenschaften:

Um die die Verknüpfung zur exe-Datei zu lösen und durch den Aufruf der Library zu ersetzen, muß im Reiter “Shortcut” das “Target" durch den Pfad zu Library ersetzt werden.

Libraries werden in Windows 7 unter

C:\Users\%Username%\AppData\Roaming\Microsoft\Windows\Libraries

abgelegt.

Außerdem haben Libraries die Extension “.library-ms”, somit wäre der Pfad zu MyDockedLibrary

C:\Users\%Username%\AppData\Roaming\Microsoft\Windows\Libraries\MyDockedLibrary.library-ms

Das Icon kann man wie gewohnt über “Change Icon” anpassen.

Nach einem Klick auf OK muß man sich neu anmelden, damit das geänderte Icon übernommen wird: