Da in der Firma, für die ich arbeite, sehr viele Regular Expressions verwendet werden und wir auch sehr viele mit der Option “Compiled” versehen, ist es interessant zu wissen wie viele Regex denn gecached sind. Leider habe ich keine Möglichkeit gefunden, die Anzahl ohne Reflection zu ermitteln. Über diesen weg sollte es jedoch ziemlich performant sein:

               1:
              public
              static
              class RegexHelper

               2: {

               3:
              private
              static ICollection
_listFieldInfo;

               4:
              private
              static
              readonly
              object _lockObject
= newobject();

               5:  

               6:
              public
              static
              int GetCachedRegexCount()

               7: {

               8:
              if (_listFieldInfo
== null)

               9: {

               10:
              lock (_lockObject)

               11: {

               12:
              if (_listFieldInfo
== null)

               13: {

               14: _listFieldInfo
= (ICollection)typeof(Regex).GetField("livecode",
BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);

               15: }

               16: }

               17: }

               18:  

               19:
              return _listFieldInfo.Count;

               20: }

               21: }

Ist ganz nützlich, wenn man prüfen will ob die gewählte Cachsize sinnvoll ist.

Heut habe ich mir die Änderungen bezüglich branching und merging des kommenden Releases von Visual Studio und Team Foundation Server angesehen. Dafür habe ich ein altes Projekt zum TFS hinzugefügt und 2 Branches erstellt:

Wie man dem obigen Screenshot entnehmen kann, sind mit dem neuen Release nun Branches mit speziellen Icons versehen. Vor dem erstem Branchen sollte man jedoch den initialen Zweig extra in einen Branch konvertieren (erst dann sieht man das Icon und Changeset-Tracking ist möglich):

Ist dies getan, kann man nun z.Bsp. auf einzelne Changesets ein Tracking aktivieren. D.h. man kann nachvollziehen in welche Branches das Changeset gemerged wurde. In meinem Beispiel hab ich im Branch "SerializerTest" drei Changesets erzeugt und mache nun ein "View History" auf den Branch wo man bei jedem Changeset die Möglichkeit hat dieses zu tracken:

Man kann dort nun wählen an welchen Branches man interessiert ist und sieht in der Grafik rechts auch gleich deren Abhängigkeiten:

Man wird danach in den Timeline View geleitet, wo man sieht wann das Changeset (hier das Changeset 84) in welchen Branch gemerged wurde. Über den mit einen Pfeil markierten Toolbarbutton gelangt man in den "Hierarchy View" in dem man sehr schön sieht wie die Bäume von einander abhängig sind.

Timeline View	Hierarchy View

Man sieht, dass dieses Changeset noch nicht in die 2 anderen Branches gemerged wurde. In beiden Views hat man die Möglichkeit mit einem Rechtsklick auf das Changeset, dieses in einen anderen Branch zu mergen:

Nach dem Mergen in den Trunk ändern sich die Grafiken der beiden Views entsprechend:

Timeline View	Hierarchy View

Nach dem Merge in den finalen Freischaltungs Branch sieht es dann so aus:

Timeline View	Hierarchy View

Ein Blick auf die History der gemergten Datei im FirstRelease Branch zeigt, dass die History nun auch in der Lage ist die Branchvorgänge abzubilden:

Aber das war noch nicht alles, die für mich sinnvollste Sache ist, dass man das Tracking auch auf Workitemebene aktivieren kann. D.h. wenn man mehrere Checkins einem Workitem zugewiesen hat, kann man nach verfolgen welche Changesets sich in welchen Branches befinden und welche noch fehlen. Dazu kann man mit einem Klick auf "Track Work Item" die zuvor dargestellten Ansichten für alle Changesets anzeigen lassen die dem Workitem zugewiesen sind:

Hier die beiden Ansichten:

Timeline View	Hierarchy View

Soweit ich es sehe, sind Branches die hier grün hinterlegt sind vollständig gemerged, heißt alle Changesets sind in diesem Branch vorhanden. Branches die orange hinterlegt sind fehlt mind. 1 Changeset. Dem Aufmerksamen Leser sollte nun auffallen, dass in der Grafik oben im Text "Changset 84,85,86" steht, jedoch ist vom Changeset 86 nichts in beiden Grafiken zu sehen. Entweder versteh ich das Feature nicht komplett oder das Feature ist einfach noch buggy. Ich tippe darauf, dass das Feature noch buggy ist. Ich habe zum Testen das Changeset 86 vom Workitem entfernt, dann hätte eigentlich der Trunk-Branch auch grün sein müssen, war er jedoch auch nicht. Hier scheint noch etwas Nacharbeit nötig zu sein.

Man kann übrigens auch einfach per Drag & Drop ein Changeset von einem Branch in den anderen mergen, einfach ein Changeset in einen der beiden Views markieren und in den gewünschten Branch ziehen. Übrigens der Merge-Dialog ist nun nicht mehr modal und wurde in die Pending Chanages integriert und heißt dort nun "Pending Changes - Conflicts". Dateien die nicht automatisch gemerged werden konnten schlagen nun dort auf und man hat wesentlich mehr Möglichkeiten als vorher und bekommt auch wesentlich mehr Informationen zu den Problem geboten:

Leider hatte ich bei diesem einfachen Szenario keine Konflikte zu bewältigen, deshalb kann ich hier kein Beispiel zeigen. Dafür erstelle ich eventuell später noch ein extra Post.

Das war nun ein kleiner Ausblick was uns in Zukunft in Sachen Branching und Merging erwartet. Ich find die Änderungen super, da man nun viel besser verfolgen kann, welche Änderungen sich wo befinden.

Mit Visual Studio 2010 ist es nun endlich möglich den Team Foundation Server auch Shelvesets builden zu lassen.

Über "Queue New Build" ^^ kommt man in den veränderten Queue Build Dialog:

Dort hat man die Wahl zwischen 2 Optionen

• Latest source
• Latest source with shelveset

Mit der ersten Option wird der neueste Quellcodestand genommen und damit der Build ausgeführt (die einzigste Option früher). Mit der zweiten Option hat man die Möglichkeit ein bestimmtes Shelveset zu builden:

Wie man am obigen Screenshot sehen kann, hat man die Möglichkeit ein vorhandenes Shelveset über den Button "..." zu wählen oder mit Hilfe des Buttons "Create" ein neues Shelveset aus den Pending Changes zu erzeugen und dieses zu builden:

Mit Visual Studio 2008 war das Gleiche nur mit Hilfe von 3rd Party Lösungen möglich. Ein Beispiel hierfür ist:

• TFS Check-in Validation Tool

Ich find das neue Feature sehr sinnvoll, da ich oft an mehreren Task gleichzeitig arbeite und sehr oft bei einzelnen Checkins nicht weis ob diese den Build brechen würden oder nicht. In diesem Fall kann ich nun die einzelnen Dateien, welche ich einchecken möchte shelven und builden lassen. Bei erfolgreichen Build check ich diese dann wirklich ein.

Da ich jetzt mal ein wenig Zeit habe, nutze ich diese um mir das CTP Release von VS 2010 mal etwas näher anzusehen. Das erste was mir positiv auffällt ist, dass jetzt unter den Project-Alerts auch der Punkt "My build completes" aufgenommen wurde. Heißt: Man kann sich jetzt auch nur noch benachrichtigen lassen, wenn ein Build, den man selber z.Bsp. durch einen Checkin ausgelöst hat,  abgeschlossen bzw. fehlgeschlagen ist:

Ich hab mir schon einiges von VS 2010 angesehen und ich glaube das Release wird ein sehr gutes Release. In diesem Release scheint sehr viel auf Kundenfeedback gehört wurden zu sein. Sieht nach einem guten Usability-Release aus.

Da ich derzeit ein größeres Projekt plane und vor habe dieses Projekt mit ASP:Net MVC umzusetzen, stoße ich ab und zu auf Dinge die mir in der Default-Implementierung nicht so passen und versuche dann dafür Lösungen zu finden. Da ich in dem neuen Projekt ASP.Net MVC und ASP.Net WebForms kombinieren werde empfinde ich es als wichtig, dass es eine gute Projekt-Struktur gibt.

Die Standard-Struktur ist folgende:

Project-Root

• Controllers
• Models
• Views

 
Mein Ziel:

Project-Root

MVC

• Controllers
• Models
• Views

Was brauchen wir Dafür?:

• Eine eigene ControllerFactory
• Einen eigenen ViewLocator

ViewLocator-Source:

            using System.Web.Mvc;

            namespace PPM.BusinessLayer.Web.MVC

{

    publicclassPPMViewLocator : ViewLocator

    {

        public PPMViewLocator()

        {

            ViewLocationFormats = new[] 

            {

              "~/MVC/Views/{1}/{0}.aspx",

              "~/MVC/Views/{1}/{0}.ascx",

              "~/MVC/Views/Shared/{0}.aspx",

              "~/MVC/Views/Shared/{0}.ascx"

            };

            MasterLocationFormats = new[] 

            {

              "~/MVC/Views/{1}/{0}.master",

              "~/MVC/Views/Shared/{0}.master"

            };

        }

    }

}

            Der
Platzhalter {1} wird später durch den Controller-Name ersetzt und der Platzhalter
{0} wird später durch den View-Name ersetzt.
          

            
              ControllerFactory-Source:
            
          

            using System.Web.Mvc;

            using System.Web.Routing;

            namespace PPM.BusinessLayer.Web.MVC

{

    publicclassPPMControllerFactory : DefaultControllerFactory

    {

        protectedoverrideIController CreateController(RequestContext requestContext, string controllerName)

        {

            Controller controller
= (Controller)base.CreateController(requestContext,
controllerName);

            ((WebFormViewEngine)
controller.ViewEngine).ViewLocator = newPPMViewLocator();

            return controller;

        }

    }

}

Hier leiten wir von der DefaultControllerFactory ab und überschreiben die CreateController Methode. In der Methode lassen wir die Basis den Controller erzeugen und setzen bei der ViewEngine des erzeugten Controller den ViewLocator auf unseren eigenen ViewLocator. Nun fehlt nur noch der Code zum registrieren unser eigenen ControllerFactory. Dies erreicht man indem man in der Global.asax in der Methode Application_Start die neue ControllerFactory setzt:

              protected
              void Application_Start()

{

    RegisterRoutes(RouteTable.Routes);

    //
plug in our custom controller factory to replace the default view locator

    ControllerBuilder.Current.SetControllerFactory(typeof(PPMControllerFactory));

}

Das wars

Da bei meinem Server in den letzten Wochen immer mehr und mehr Probleme aufgetreten sind, hatte ich mich heute Morgen dazu entschlossen meinen Server neu zu installieren. Bei der Gelegenheit habe ich auch gleiche das Betriebssystem von Windows 2003 auf Windows 2008 gewechselt.

Leider ist durch die Probleme der letzten Zeit ein Problem untergegangen - Es wurden keine Datenbank-Backups mehr erstellt. Als ich nun freudestrahlend alles installiert hatte und meine Datenbank-Backups einspielen wollte, musste ich feststellen, dass alles  weg war .

Somit ist die Datenbank meines Community Servers dahin und ich steh ohne Blog da. Naja, sind zwar alle Blogposts weg, aber ich wollte eh zurück zu "DasBlog".

Ich hoffe mal nicht, dass ich noch mehr Überraschungen beim Wiederherstellen meines Server's erlebe .

Grüße,
Jens