VS2010 Beta 2 und SharePoint 2010 Evaluation Guide verfügbar

Es gibt seit heute VS2010 Beta 2 zum Download in der MSDN. Einige Neuerung des .NET 4 im Blog von Scott Hanelman, unbedingt man vorbei schauen. Gut finde ich im neuen Studio, das der Multitargeting-Support auch für .NET 2 Apps erhalten bleibt, so kann man gerade für Silverlight-Projekte auf die neue Umgebung setzen, es lohnt sich sicherlich auch für andere Umgebungen.

Des Weiteren gibt es den SharePoint 2010 Eval Guide, der “kurz” über die Neuerungen im Sharepoint aufklären soll. Ich werde gleich mal drin rumstöbern.

Update: Ganz vergessen, seit heute steht auch das Release Datum für VS2010 fest – 2010-03-22.

Git – Konkurrent für SVN

Ich habe schon seit einigen Wochen, oder ist es schon Monate her, GIT neben SVN auf dem Rechner. Seit einigen Tagen nutze ich es intensiv beim Arbeiten mit unseren SVN-Repositories. Ich nutze GIT derzeit meist eher um auf die SVN-Repos zuzugreifen, aber es macht sich schon relative gut. Besonders gut gefällt mir, dass es trotz gesamter Historie, das Verzeichnis auf lokal viel kleiner ist. Apropos Historie, im Unterschied zu SVN ist bei GIT die gesamte Historie lokal verfügbar und man kann zwischen den Ständen hin und her springen.

Der Einstieg in GIT ist ziemlich holprig, zumindest für mich. Ich habe mir eine aktuelle Version von msysGIT gezogen und dann losgelegt. Ich habe zuerst viel über das GUI versucht, aber momentan bin ich der Meinung, dass man am besten mit der Shell arbeiten kann.

Den Einstieg findet man am besten, wenn man sich mit dem Tutorial Git - SVN Crash Course befasst. Danach gibt einen GIT-SVN noch viele Fragen auf, aber  man kommt mit Google schon recht weit. Bisher ist der SVN-Zugriff in GIT a manchen Stellen noch etwas holprig, und reportet öfter mal Fehler. Zurzeit geht der Zugriff auf SVN:EXTERNALS nicht, so dass man sich die Verzeichnisse herein kopiert oder ein weiteres Repository anlegt. Eine andere Stelle, an der ich lange gesucht habe, sind die Ignores. Um Ausschlüsse zu definieren, muss man im Root-Folder des Repository eine Datei “.gitignore” anlegen. In der Datei kann man anschließend mit Mustern die Verzeichnisse oder Dateien definieren. Hier ein Auszug meiner Exclude-Datei:

   1: bin/**/*

   2: obj/**/*

   3: bin/

   4: obj/

   5: *.bak 

   6: *.~?? 

   7: *.jar 

   8: *.[Tt]mp. 

   9: *.suo 

  10: *.vss* 

  11: *.scc 

  12: *.suo

  13: *.resharper.user

  14: *.csproj.user

  15: *.webinfo 

  16: *.pdb 

  17: thumbs.db

Zum Schluss noch der entscheidene Tip. Zur Vereinfachung der Arbeit einfach TortoiseGit installieren. Damit arbeitet sich fast alles wie mit TortoiseSvn. Einige Regeln von Git sollte man allerdings immer im Kopf haben.

CCNet 1.5 Security

Letzte Woche habe ich bestimmt 3-4h rumgefummelt um Security von einem CCNet-Server zu konfigurieren. Die Beschreibungen in der Dokumentation finde ich noch nicht so aussagekräftig.

Um Security zu nutzen ist es erst mal erforderlich, die Security auf Server-Ebene zu aktivieren, dies geschieht durch das internalSecurity-Attribute direkt unter dem Root-Node “cruisecontrol”.

   1: <internalSecurity>

   2:   <cache type="inMemoryCache" duration="20" mode="sliding"/>

   3:   <users>

   4:     <ldapUser name="*" domain="YOURDOMAIN.local"/>

   5:   </users>

   6:   <!--<audit>

   7:     <xmlFileAudit location="c:\ccnet_audit.log"/>

   8:   </audit>-->

   9:   <permissions>

  10:     <rolePermission name="SpecialPermission" forceBuild="Allow" viewProject="Allow" viewConfiguration="Allow" defaultRight="Deny">

  11:       <users>

  12:         <userName name="Special.User1"/>

  13:       </users>

  14:     </rolePermission>

  15:     <rolePermission name="ServerAdministrators" defaultRight="Allow">

  16:       <users>

  17:         <userName name="Special.User2"/>

  18:       </users>

  19:     </rolePermission>

  20:     <rolePermission name="general" forceBuild="Deny">

  21:       <users>

  22:         <userName name="*"/>

  23:       </users>

  24:     </rolePermission>

  25:   </permissions>

  26: </internalSecurity>

Da ich nicht extra Benutzer und ggf. Passwörter definieren, verwalten und sichern möchte, muss unser Active Directory dafür herhalten. Hierfür gibt es bei ccnet das “ldapUser”-Element. In meinem Build von 08.10.2009 funktionierte es nicht richtig in unserer Domaine, ich habe dazu einen Bug entsprechend angelegt. Es scheint als muss der Ldap-Helper für komplettes durchsuchen des ADs konfiguriert werden. Zu dem ist vermutlich der Zugriff über den Global Catalog (GC) schneller.

Anschließend ist für den Server die Security aktiviert. Nun kann man mit der “defaultProjectSecurity” die Rechte für das aktuelle Projekt definieren. Da die Security für ein Projekt ist, muss dieses auch unterhalb eines “project”-Tags folgen. Man kann bei der Permission des Projects  auf die Permissions des Servers referenzieren. Ich habe direkt die Permission zu spezifizieren nicht ausprobiert, kann aber noch kommen.

   1: <security type="defaultProjectSecurity">

   2:   <permissions>

   3:     <rolePermission  name="Administrators" ref="ServerAdministrators"/>

   4:     <rolePermission  name="Testers" ref="SpecialPermission"/>

   5:   </permissions>

   6: </security>

Nach der Aktivierung der Security sieht man auf der Startseite von CCNet nichts mehr, sofern nicht jeder Berechtigt ist.

Erst durch Auswahl des Servers, zumeist auf der linken Seite, und anschließendem Login, bekommt man die Projekte zu sehen.

Schade ist, dass man sich separate anmelden muss um Zugang zu bekommen, allerdings ist das nachvollziehbar, da die Security nicht durch die Web-App geprüft und verwaltet wird, sondern durch den CC-Server, der über Remoting mit der Web-App redet. Vorteil ist allerdings, dass so viele verschiedene CCNet-Server durch eine WebApp verwaltet werden können und unterschiedliche Berechtigungskonfigurationen aufweisen können.

Größtes Hinderniss war der oben erwähnte Bug, mal schauen, ob die Änderung in das Release noch hereinkommt. Aber nun funktioniert es sauber und ich kann alle auf das Web-Interface loslassen, da jeder nur seinen Teil sieht. :)

Vielleicht kommt demnächst noch etwas zu Parametern, die ebenfalls neu in 1.5 sind und etwas Dynamic in der CCNet-Prozess bringen.

Zum Schluß noch ein kleiner Verweis auf einen ineressanten Blog-Post zum Thema “Bootstrap your build – good practice for CruiseControl.Net”. Projektbestandteile oder ganze Bereiche auszulagern, ist super interessant.

CCNet 1.5 – Security für Multi-Projektumgebungen

Wow, ich bin Ende der letzten Woche auf die aktuelle Pre-Release von CCNet gestoßen. Das nächste Release wird Security enthalten, so dass man super in Multi-Projekt-Umgebungen regeln kann, was wer darf. Der Download ist auf der WebSite bzw. CCNet LIVE. Die neuen Security Features sind sehr interessant, leider auch noch etwas sporadisch in der Dokumentation und daher auch nicht ganz so leicht zu verstehen.

Ich bin gerade mal wieder dabei eine Projekt-Build-Umgebung bereitzustellen, mal schauen, was dort wieder an Tasks/Tipps abfällt.

Es ist schön, wenn sich der Vorteil eines Build-Systems im Projekt deutlich bemerkbar macht. Wir haben vor einem Jahr ein Build-System in einem Projekt aufgesetzt und ich glaube es bereits zweistellig Projekttage gespart, die nur durch das Aktualisieren von Entwicklungs- und Testumgebung verbraucht worden wären. Wir haben zu dem Unit-Tests im Build-Vorgang integriert, die uns an kritischen Stellen auf Veränderungen hinweisen und einie minimale Build-Qualität sicherstellen.

To be continued …