Attic...

ASP.NET Skillscamp 2011–Der Tag danach

noreply@blogger.com (Jan Christian Selke) — Tue, 30 Aug 2011 12:40:00 +0000

Das war es also, das erste ASP.NET Skillscamp (@Skillscamp) 2011 in Köln und gleichzeitig das erste Community Event, an dem ich teilgenommen habe. Alles in allem kann ich, zumindest für mich, eine positive Bilanz ziehen: Ich durfte interessante Personen kennen lernen, deren Bilder und Artikel ich bisher nur kannte, und an vielen, zum Teil spannenden Gesprächen teilnehmen.

Hier folgt nun meine kurze, persönliche Zusammenfassung der Tage.

Freitag - Das Vorspiel

Der Freitag Abend begann um 19.00h in Peters Brauhaus in der Kölner Altstadt und Albert Weinert (seines Zeichens der Organisator) nahm die Teilnehmer in Empfang. Nach und nach (je nach Verspätung der öffentlichen Verkehrsmittel) trudelten die Meisten bis auf wenige Ausnahmen auch ein. Mit zunehmenden Kennenlernen (wobei sich viele der üblichen Verdächtigen bereits kannten), ersten Gesprächen und auch den ersten Kölsch kamen die Themen für den Open Space Samstag zusammen. Es kristallisierte sich relativ schnell heraus, dass ein großer Schwerpunkt auf Javascript und den verschiedenen Frameworks, vor allem Knockout.js, Backbone.js und Node.js, liegen würde. Nicht Fehlen durften natürlich auch Themen wie ASP.NET MVC, HTML5 und REST mit WCF.

Mein persönliches (Negativ-)Highlight des abends hatte allerdings nicht primär mit der Veranstaltung zu tun, sondern dem Chaos und Anarchie ÖPNV. Der hat dafür gesorgt, dass ich nachts die Strecke vom Kölner Bahnhof nach Bonn-Beuel im Fabelrekord von unglaublichen 2,75 Stunden (in Worten: zwei Stunden und fünfundvierzig Minuten) zurückgelegt habe. Vielen Dank noch an dieser Stelle für die unglaubliche Unterstützung des VRS, ohne den diese Leistung nie möglich gewesen wäre!

Samstag - Der Open Space

Samstag morgen standen wir erst einmal mit versammelter Mannschaft vor verschlossener Tür, weil irgendein Spaßvogel die Tür zufallen lassen hat. Macht nix, wir standen schließlich fast alle draußen .

Nach der Begrüßung und allgemeinen Vorrede zum Skillscamp durch Albert, wurde der Session Plan, vorerst nur für den Vormittag, zusammen gestellt. Aufgrund des allgemeinen Interesses und der relativ kleinen Zahl an Teilnehmern, gab es dann morgens auch nur eine erste Session zum Thema Javascript Frameworks - die auch gleich den größten der bereitstellten Räume der GFU sprengte. Diese erste Session war dann vor allem durch die Ausführungen von Albert geprägt.

Die zweite Session konnte auf zwei Slots aufgeteilt werden. Für die Einen gab es Node.js, für die Anderen Html5 (darüber kann ich leider nichts berichten). Der Versuch in der zweiten Session, unter der Schirmherrschaft von Daniel Fisher, IISNode.js auf dem IIS zum Laufen zu bringen, scheiterte leider. Es war zwar relativ schnell eine lauffähige Version anhand des Blogs von Tomek (der die letzten Tage ziemlich Kreise gelaufen hat) aufgesetzt, der Versuch eine eigene Seite anzuzeigen scheiterte jedoch. Und leider nicht nur das: Abgesehen davon, dass der Webserver einen 503er Fehler generierte, wurden zudem keinerlei brauchbare Loginformationen in die Logdatei oder das Eventlog geschrieben. Damit war relativ schnell (vorerst) der Stempel “noch nicht produktionstauglich” vergeben (Vielleicht war es aber auch nur die lang überfällige Zigarettenpause ! Mittlerweile ist ein Lösungsansatz von LennyBacon bei Scott Hanselman gefunden worden)…
Weiter ging es zur Lokalisation mit ASP.NET MVC in Session 3, der letzten vor dem Mittagessen. Hier war es mal wieder Daniel Fisher, der, auf eine konkrete Frage zur Lokalisation von Thomas Bandt hin, alle Möglichkeiten der Lokalisierung vom Server bis zum Client vorstellte.

Nach dem Mittagessen, wurde die Planung des Nachmittags vorgenommen. Schon etwas auffällig war, dass Daniel Fisher einen sehr unruhigen Arm hat, wenn es um die Frage geht, wer mit einer bestimmten Technologie/einem bestimmten Framework bereits Erfahrung hat und darüber auch berichten möchte/kann. Dementsprechend wurde der Nachmittag wieder vor allem durch Albert und Daniel geprägt, insgesamt fand aber viel mehr Interaktion statt als noch am Vormittag. Grund war sicherlich auch, dass das erste Thema nach dem Mittag “Best-Practices in MVC” war und fast jeder in Form von Erfahrungen oder aber konkreter Fragen dazu beitragen konnte.

Auf den Themenkomplex REST und WCF wurde bewusst verzichtet. Der einzige, der zu diesem Thema aktiv mitgestalten konnte/wollte, war, wie konnte es auch mal wieder anders sein: Daniel Fisher… Und da er seine Meinung als nicht unbedingt massenkompatibel bezeichnete und Alexander Zeitler kurzfristig abgesagt hatte, wurde das Thema fallen lassen (kleiner Wink mit dem Zaunpfahl an dieser Stelle an Alexander Zeitler!).

Den Abschluss des Tages bildete schließlich ein Rundflug durch das Javascript-Tooling und sämtliche Javascript Frameworks, die von den Teilnehmern schon einmal eingesetzt wurden (für besondere Erheiterung sorgte: raptorize your screen ) mit einer kleinen Vorstellung über Inhalt und Funktionsweise. Hier kam wirklich fast alles mal kurz auf den Tisch, ich könnte bestimmt nur noch die Hälfte nennen…

Das Nachspiel

Den abendlichen Nachgesang konnte ich dann aus persönlichen Gründen nicht mehr aktiv miterleben (gut unterrichteten Quellen war aber zu entnehmen, dass es bis spät in die Nacht ging). Ich habe mir aber für das nächste Mal vorgenommen auch hier dabei zu sein.

Zum Schluss bleibt mir nur noch anzumerken, dass es mir persönlich sehr gefallen hat. Allein schon deshalb, dass man Gesicherten und Texten reale Personen zuordnen und diese kennen lernen konnte. Organisatorisch hätte mir persönlich eine Aufteilung in kleinere Gruppen besser gefallen, da das mit Sicherheit eine intensivere, tiefer gehende Diskussion in der einzelnen Session erlaubt hätte, als es letztlich in den/der großen Gruppe möglich gewesen ist. Und ansonsten ließe sich sicher auch die eine oder Andere kleine Optimierung finden. Entgegen des häufig geäußerten Wunsches von Albert, dass sich alle in die Runde einbringen, lief es doch zu Teil zu sehr auf ein reines konsumieren hinaus. Alles in allem war es aber aus meiner Sicht ein gelungenes erstes (Wink an Albert!) Skillscamp und ich freue mich schon auf die Fortsetzung.

Sollte ich etwas vergessen haben, könnt ihr mich gerne anschreiben und ergänzen oder einfach selbst noch einmal etwas dazu schreiben.

Es bleibt mir nur noch einmal Albert Weinert herzlich für die Idee, Planung/Organisation und Durchführung zu Danken und ebenso allen Sponsoren, die das erste Skillscamp überhaupt möglich gemacht haben. Bis zum nächsten Mal!

jQuery auf Koffein

noreply@blogger.com (Jan Christian Selke) — Tue, 19 Jul 2011 19:35:00 +0000

Der Name CoffeeScript geistert schon eine Weile umher. Viele haben bereits in Verbindung mit Node.js damit gearbeitet. Da ich in letzter Zeit weder selbige noch große Lust hatte mir ein Ubuntu oder eine andere Linux Distribution meines Vertrauens zu installieren, habe ich es einfach vorerst ignoriert… Jetzt habe ich vor kurzem Mindscapes Web Workbench entdeckt.

Die Web Workbench ist eine Visual Studio 2010 Erweiterung zur Integration von LESS, SASS und Coffee Script. Und gerade das letzte, ohne die Notwendigkeit Node.js installieren zu müssen. Jetzt doch etwas neugierig habe ich es von Microsoft heruntergeladen, installiert und losgelegt.

Zum ersten Herumspielen musste einfach eine ASP.NET MVC Anwendung herhalten. Die Anwendung blieb soweit unverändert und gleich erstmal eine CoffeeScript Datei hinzufügen. Wie man in der folgenden Abbildung sehen kann, werden nun drei neue Dateitypen angeboten: sass SCSS Style Sheet, Less Style Sheet und CoffeeScript File.

Also letzteres hinzugefügt und es erscheinen in dem Projekt zwei neue Dateien. Eine Datei mit der Endung .coffee und eine mit der Endung .js. Die .coffee Datei ist natürlich die Datei, die das Coffee Script enthalten wird. Die .js Datei enthält den automatisch aus dem Coffee Script erzeugten Javascript Code.

Als einfaches, kurzes Beispiel wollte ich einfach eine Slideshow mit jQuery erstellen und laufen lassen. Meine Index.cshtml habe ich dazu um die für die Slideshow notwendigen Basis-Divs erweitert. Da ich erst einmal nur ein Gefühl dafür bekommen wollte, wurde ein div zu drei…

   1:  <div id="slideShow">

   2:      <div>

   3:          <img src="@Url.Content("~/public/images/SlideShowPicture.png")" width="200"

   4:              height="200" alt="Ein Park" />

   5:          <p>

   6:              Hier ist ein schönes Sommerbild</p>

   7:          <p>

   8:              Dieser Park war ein schöner Spielplatz für alle Kinder.

   9:          </p>

  10:      </div>

  11:      <div>

  12:          <img src="@Url.Content("~/public/images/SlideShowPicture.png")" width="200"

  13:              height="200" alt="Ein Park" />

  14:          <p>

  15:              Hier ist ein schönes Sommerbild</p>

  16:          <p>

  17:              Dieser Park war ein schöner Spielplatz für alle Kinder.

  18:          </p>

  19:      </div>

  20:      <div>

  21:          <img src="@Url.Content("~/public/images/SlideShowPicture.png")" width="200"

  22:              height="200" alt="Ein Park" />

  23:          <p>

  24:              Hier ist ein schönes Sommerbild</p>

  25:          <p>

  26:              Dieser Park war ein schöner Spielplatz für alle Kinder.

  27:          </p>

  28:      </div>

  29:  </div>

Jetzt nur noch das entsprechende Coffee Script für einen einfachen Slideshow Aufruf schreiben. Dabei habe ich mich wirklich nicht überfordert und den folgenden Einzeiler geschrieben.

   1:  $('#slideShow').cycle

   2:    fx:    'scrollRight',

   3:    delay: -2000

Meine Neugier trieb mich gleich in die Javascript Datei uns siehe da: es war bereits umgewandelt.

   1:  (function() {

   2:    $('#slideShow').cycle({

   3:      fx: 'scrollRight',

   4:      delay: -2000

   5:    });

   6:  }).call(this);

Nun noch schnell die Javascript Datei in die Webseite eingebunden und schnell F5 gedrückt. Nach einem kurzen Augenblick zeigte sich dann die Standard Webseite – aber um eine von links nach rechts durchschiebende Slideshow reicher…

Was kann man zu so einem Beispiel schon groß sagen? Es funktioniert einwandfrei und erfüllt in diesem Einfachstbeispiel seinen Zweck. Inwiefern komplexere Anwendungen damit entwickelt werden können, wird sich noch zeigen.

Es ist aber definitiv eine interessante Alternative… und ich kann endlich mit Coffee Script arbeiten. Mit Kaffee arbeitet es sich einfach besser .

Alles neu macht der Mai

noreply@blogger.com (Jan Christian Selke) — Mon, 04 Jul 2011 10:46:00 +0000

Es ist zwar nicht mehr Mai, aber die Schatten ziehen sich noch immer etwas.

Nachdem ich Ende Mai meinen Arbeitgeber gewechselt habe, hat sich auch meine berufliche Fokussierung etwas gewandelt. Damit einhergehend wird sich in Zukunft mein Schwerpunkt immer weiter weg von VSTO und OpenXml Themen verschieben.

Ich freue mich auch darauf, denn etwas von dem, was ich gelernt habe ist: Automatisierte Dokumentgenerierung mit einfachen, überschaubaren Dokumenten ist durchaus möglich – Aber komplexe Dokumentstrukturen auf Basis des Office OpenXml kann einen in den Wahnsinn treiben. Es ist schon schwer genug die Dokumentstruktur beherrschen zu wollen, aber die zum Teil sehr eigenen Verhaltensweisen von Word können für psychotische Schübe sorgen... Ich sage nur Fußnoten, Tabellen und/oder Abschnittswechsel (auch in Verbindung mit unsichtbarem Text).

Ich bin auf jeden Fall gespannt, was die nähere Zukunft mit sich bringt…

Alle Bälle in der Luft halten

noreply@blogger.com (Jan Christian Selke) — Sat, 09 Apr 2011 11:00:00 +0000

Die magischen Buchstaben, wenn es darum geht Anwendungen mit Benutzeroberflächen zu entwickeln, kennt wohl jeder: MVP. Und wer sie nicht kennt, sollte sich schnellstmöglich damit vertraut machen! Es gibt viele schöne Beispiele hierzu, eines ist sicherlich auch das von Stefan Kölle. Woran es, meiner Meinung nach, aber wie die meisten Beispiele auch krankt, ist die Steuerung zwischen den einzelnen Views/Presenters.

Besonders deutlich wurde mir dieser Mangel, als ich vor Kurzem folgenden Quellcodeauszug sah:

public class MyClass
{
   ...
   public void ShowOtherForm()
   {
      using(MyPresenter presenter = new MyPresenter())
      {
         presenter.Initialize();
      }
   }
}

public class MyPresenter()
{
   public void Initialize()
   {
      ...
      this.View.Show();
   }
}

Don’t do this at home, kids!

Den Presenter direkt im Code zu erzeugen bereitet mir schon ein Gefühl von Unbehagen, aber den View dann auch noch im Initialize anzuzeigen – das bereitet mir Magenschmerzen. Auf der Suche nach eleganteren Lösungen ist mir aufgefallen, dass viele Beispiele gerade in diesem Kontext Ihre Schwächen haben. Aber wie kann eine Lösung hierzu sehen?

Meine Antwort lautet: ApplicationController. Martin Fowler hats und Microsoft hat es auch.

Der ApplicationController enthält die Logik, welche View anzuzeigen ist, die vorher über die verschiedenen Presenter verteilt war. Zum Einen wird so die Logik zentralisiert zum Anderen werden damit aber auch etwaige Quellcode Dopplungen aufgehoben.

Wenn nun zwei Presenter die gleiche View anzeigen sollen, erhalten diese Presenter nur noch eine Abhängigkeit zum ApplicationController und rufen darauf eine gemeinsame Methode auf. So wird der anwendungsweite Ablauf nur noch über eine zentrale Komponente kontrolliert.

Ich habe eine Weile darüber nachgedacht, wie ich das Kind am besten beim Namen nennen kann. Dabei entstand u.a. die Idee ViewNavigator, aber letztlich trifft es der Name ViewConductor am besten. Und so sieht mein erster Versuch eines ViewConductors aus.

public class ViewConductor : IViewConductor
{
   private readonly IMainView _mainView;
   private readonly IMainViewService _mainViewService;
   private readonly IPresenterFactory _presenterFactory;

   public ViewConductor(IMainView mainView, IMainViewService mainViewService, IPresenterFactory   presenterFactory)
   {
      _mainView = mainView;
      _mainViewService = mainViewService;
      _presenterFactory = presenterFactory;
   }

   public void OpenView<TPresenterType>() where TPresenterType : IPresenter
   {
      var presenter = this._presenterFactory.CreatePresenter<TPresenterType>();
      presenter.Activate();
   }

   public void ShowPersonDetails()
   {
      this.OpenView<IPersonDetailPresenter>();
   }
}

public class PersonDetailPresenter : IPersonDetailPresenter
{
   private IPersonService _personService;

   public PersonDetailPresenter(IPersonDetailView personDetailView, IPersonService personService)
   {
      this._personService = personService;
      this.View = personDetailView;
   }

   public IPersonDetailView View { get; private set; }

   public void Activate()
   {
      this.View.Presenter = this;
      this.View.Show();
   }
}

Ja, es ist die Anwendung eines MVP Patterns, aber müssen deshalb die Komponenten auch danach benannt werden? Ich nenne meinen Hund auch nicht Hund (oder Mr. Hund ). Ist es vielleicht nicht sinnvoller die einzelnen Komponenten nach ihrer Verwendung zu benennen? Aus meiner Sicht unterstützt das zudem ein Presenter-First Vorgehen, weil der Ablauf dadurch offensichtlicher wird.

Hier werde ich mit meinem nächsten Beitrag wieder ansetzen.

Gedankengang zur IoC Container Registrierung

noreply@blogger.com (Jan Christian Selke) — Thu, 07 Apr 2011 14:03:00 +0000

Das folgenden Beispiel hat vermutlich (fast) jeder schon mal gesehen – so, oder so ähnlich zumindest, sieht eine landläufige Registrierung von Typen in einem IoC Container aus…

public TestRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   ForSingletonOf<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
   For<IMyView>().Use<MyDRYView>();
   For<IService>().Use<SuperService>();
   For<IRepository>().Use<WhatSoEverRepository>();
}

Es werden mehr oder viele Projekte angelegt, um eine saubere Trennung zwischen Schichten und Verantwortlichkeiten zu gewährleisten. Es dürfen alle Schichten nur über Kontrakte miteinander kommunizieren. Eine der typischen Abbildungen, die in diesem Zusammenhang häufig zu sehen ist, ist die schematische DIP Darstellung von Uncle Bob, die dem folgenden entspricht.

Jede Schicht kommuniziert mit der unterliegenden über Kontrakte, die Abhängigkeiten werden wasserfallartig nach unten durchgereicht. Was passiert aber durch eine solche Registrierung? Die Isolation der einzelnen Schichten wird dahin gehend konterkariert, dass wir eine Über-Topschicht haben, die ALLE unterliegenden kennt.

Die erste Frage, die sich mir stellt: Warum trenne ich dann überhaupt in verschiedene Projektdateien? Diese Trennung ist doch schließlich ohnehin nur eine logische, die durch die Aufteilung in verscheidene Projektdateien nur unterstützt werden soll. Interessant wird eine solche Trennung erst dann, wenn das Entwicklerteam groß genug ist, dass isoliert an verschiedenen Komponenten gearbeitet wird oder aber verteilt gearbeitet wird.

Ich aber habe diese Struktur nun schließlich gewählt, also warum dann nicht die Registrierung zumindest auf die Komponenten aufteilen. Jede Komponente registriert Typen der ihr untergeordneten Komponente. Es gilt ohnehin als best-practice die Registrierung inhaltlich auf verschiedene Teilregistrierungen aufzuteilen – warum dann nicht auch auf die Komponenten?

Die Mechanism-Schicht wird also sie Registrierung für die Utility-Schicht beinhalten, die Policy-Schicht enthält die Informationen über die Mechanism-Schicht. Aufgrund der auto-discovery Mechanismen der verschiedenen Container sollte dies damit keine großes Problem darstellen.

In Zukunft werden die Registrierungen dann anders aussehen - oder aber die Anzahl der Projekte einfach eingedampft.

public WebRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
      x.LookForRegistries();
   });

   ForSingletonOf<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
   For<IMyView>().Use<MyDRYView>();
}

public ServiceRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   For<IService>().Use<SuperService>();
}

public DataRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   For<IRepository>().Use<WhatSoEverRepository>();
}

Javascript aus WebParts für Sharepoint und Web Projekte registrieren

noreply@blogger.com (Jan Christian Selke) — Sun, 03 Apr 2011 16:58:00 +0000

Javascript, wie etwa JQuery, aus WebParts heraus zu rendern ist eine häufige Anforderung. Wie so etwas, beispielsweise mit Hilfe eines DelegateControls, gelöst werden kann, zeigt ein Artikel von Thorsten Hans.

Nun stand ich aber vor der Anforderung den WebPart in Sharepoint sowie eine WebForms Seite einzubinden. Grundsätzlich ist dies auch mit dem DelegateControl zu realisieren. Mein Vorgehen ist aber etwas Quellcode-zentrischer und ich möchte alles Renderverhalten in einem WebPart aus dem Quellcode heraus steuern.

Für Sharepoint gibt es hierfür die Klasse ScriptLink, in Web Projekten hingegen wird aber der ScriptManager verwendet. Um dennoch beide bedienen zu können habe ich einen Kontrakt IScriptRegistrar erstellt, der nur eine Methode RegisterScript beinhaltet.

public interface IScriptRegistrar
{
    void RegisterScript(IScriptRegistrationParameters registrationParameters);
}

Als Parameter wird eine Klasse erwartet, die die zur Registrierung des Skripts notwendigen Informationen beinhaltet. Der Kontrakt dazu sieht wie folgt aus.

public interface IScriptRegistrationParameters
{
    Page Page { get; set; }
    Type Type { get; set; }
    string Key { get; set; }
    string Url { get; set; }
    bool Localizable { get; set; }
}

In dem Sharepoint Projekt wird nun die konkrete Implementierung SharepointScriptRegistrar mit der Klasse ScriptLink hinzugefügt.

public class SharepointScriptRegistrar : IScriptRegistrar
{
    public void RegisterScript(IScriptRegistrationParameters registrationParameters)
    {
        ScriptLink.Register(
        registrationParameters.Page, 
        registrationParameters.Url, 
        registrationParameters.Localizable);
    }
}

Das Webprojekt dagegen erhält eine weitere Klasse WebScriptRegistrar, die das Skript mit Hilfe des ScriptManagers registriert.

public class WebScriptRegistrar : IScriptRegistrar
{
    public void RegisterScript(IScriptRegistrationParameters registrationParameters)
    {
        var scriptManager = registrationParameters.Page.ClientScript;
        scriptManager.RegisterClientScriptInclude(
        registrationParameters.Type,
        registrationParameters.Key,
        registrationParameters.Url);
    }
}

Der Aufruf des jeweiligen Registrars erfolgt kontextabhängig durch einen IoC Container. So halte ich das Wissen über die Implementierung aus dem WebPart raus und die Registrierung erfolgt nur in der Konfiguration des Containers. Als IoC Tool nutze ich in diesem Fall StructureMap.

So beschreibt der folgende Ein-Zeiler die Konfiguration innerhalb des Sharepoint Projekts.

For<IScriptRegistrar>().Use<SharepointScriptRegistrar>();

Die Registrierung für das Web Projekt sieht dem entsprechend angepaßt aus.

For<IScriptRegistrar>().Use<WebScriptRegistrar>();

Mit Hilfe eines ServiceLocators wird dann der registrierte IScriptRegistrar aus dem Container geholt und die Skriptregistrierung mit dem Aufruf RegisterScript ausgeführt.

var scriptRegistrar = ServiceLocator.Get<IScriptRegistrar>();
IScriptRegistrationParameters scriptRegistrationParameters = new ScriptRegistrationParameters
{
    Page = this.Page,
    Type = this.GetType(),
    Key = "javascript",
    Url = "necrtt/jsgantt.js",
    Localizable = false
};
scriptRegistrar.RegisterScript(scriptRegistrationParameters);

Falls es noch andere Ideen gibt, wie dieses Szenario auch umgesetzt werden könnte, bin ich immer daran interessiert…

Einfach mal abschalten

noreply@blogger.com (Jan Christian Selke) — Wed, 30 Mar 2011 10:03:00 +0000

Es gibt etwas sehr wichtiges, dass vor einiger Zeit von mir viel zu sträflich vernachlässigt wurde: disconnecting.

Rob Conery und Scott Hanselman berichten über Ihre “ungewöhnliche” Erfahrung in This Developers Life. Jeder, der es noch nicht kennt und/oder von sich der Meinung ist, er arbeite (zu) viel, sollte es sich mal anhören. Ich für meinen Teil konnte mich in einigem davon wiederfinden…

Meiner Meinung nach wertvolle, auf jeden Fall aber auch unterhaltsame 54 Minuten.

Den Standard Editierdialog des Sharepoint Servers nutzen

noreply@blogger.com (Jan Christian Selke) — Tue, 11 Jan 2011 15:57:00 +0000

Wer den Sharepoint Editierdialog anzupassen möchte hat Glück, denn dazu gibt es im Internet reichlich Quellen.
Schon etwas anders sieht es allerdings aus, möchte man den 0815-Standarddialog zur Bearbeitung von Listitems benutzen; allerdings den Popup Dialog - nicht den seitenfüllenden. Denn dazu gibt es schon nicht mehr so viel Informationen. Der Fall ist vermutlich so banal, dass er schon wieder exotisch ist...
Dennoch wollte ich vor Kurzem genau das!

Nach einigem Suchen fand ich dann doch schließlich etwas: Jomit'sBlog.

Hier wird beschrieben, was die neue Dialog Plattform ist und wie sie genutzt werden kann am - kurzer Trommelwirbel - Beispiel des Standard Editierdialogs.
Wenn man doch immer so einfach glücklich gemacht werden könnte ;-)

JQuery im Sharepoint Server 2010 für Dummies²

noreply@blogger.com (Jan Christian Selke) — Tue, 11 Jan 2011 13:07:00 +0000

Um JQuery in den Sharepoint Server 2010 einzubinden, gibt es verschiedene Möglichkeiten. Beschrieben wurden diese Möglichkeiten etwa von Jan Tielens, Voyta aber auch Anderen.

Als Anfänger in diesem Thema habe ich mich also Schritt für Schritt an deren Anleitung langgehangelt. Aber letztlich wollte nach dem Deployment in den Sharepoint einfach keine jquery-1.4.1.js Datei in dem Ordner JQuery innerhalb des Layouts Verzeichnis des Sharepoint Servers erscheinen.

Nach einigen Versuchen und etwas Internetrecherche stellte ich fest, dass nur eine Kleinigkeit fehlte damit die JQuery Datei, und damit auch jede andere Javascript Datei, in das /_layouts Verzeichnis verteilt wird. Die Lösung ist ebenso so schlagend wie einfach:

Einen zugeordneten Sharepoint-Ordner “Layouts” im Visual Studio hinzufügen.

In diesen Ordner wird die JQuery Datei aus dem Modulordner verschoben und die elements.xml entsprechend angepasst.

Die CustomAction bleibt unverändert und jetzt wird nach dem Deployment auch der Ordner /JQuery unterhalb des Ordners /Layouts angelegt und die Datei jquery-1.4.1.js dort abgelegt. Warum nicht gleich so?! ;-)

(m)Ein EA Versuch

noreply@blogger.com (Jan Christian Selke) — Mon, 20 Dec 2010 09:23:00 +0000

Im Zuge meiner ersten Gehversuche mit dem MVVM Light Framework von Laurant Bugnion, habe ich festgestellt, dass ich mit dem EventAggregator (EA) nicht ganz warm werde. Das hat sich zwar mittlerweile etwas relativiert (Hast Recht, André ;-)), jetzt bin ich vor Kurzem auf eine neue Implementierung eines EA von Glenn Block gestoßen. Diese Implementierung basiert auf dem in StoryTeller genutzten EA von Jeremy D Miller.

Alles in allem fand ich diese Version schon sehr spannend: Der EA nutzt WeakRefences, extrahiert selbst aus einem registrierten Objekt die notwendigen Events und entfernt sie auch so wieder…

Letztlich habe ich (in meinen Augen) ein bisschen cherry picking betrieben. Aus den verschiedenen Varianten habe ich versucht, mir einen eigenen “maßgeschneiderten” EA zu erstellen.

Im folgenden das vorläufige Ergebnis:

public class EventAggregator : IEventAggregator
{
   private readonly Dictionary<Type, List<WeakReference>> _eventSubscriberLists = new Dictionary<Type, List<WeakReference>>();
   private readonly SynchronizationContext _context;
   private object _lock = new object();

   public EventAggregator(SynchronizationContext context)
   {
      _context = context;
   }

   public void Subscribe(object subscriber)
   {
      Lock(() =>
      {
         var subscriptionTypes = subscriber.DissectSubscriptionTypes();
         subscriptionTypes.Select(SubscribersFor).Each(referenceList =>referenceList.Add(new WeakReference(subscriber)));
      });
   }

   public void RemoveSubscription(object subscriber)
   {
      Lock(() =>
      {
         var subscriberTypes = subscriber.DissectSubscriptionTypes();
         subscriberTypes.Select(SubscribersFor).Each(referenceList => referenceList
            .ForEach(weakReference =>
            {
               if (weakReference.Target == subscriber)
               referenceList.Remove(weakReference);
            }));
      });
   }

   public void Publish<T>() where T : class, new()
   {
      Publish(new T());
   }

   public void Publish<T>(T eventToPublish) where T : class
   {
      var subscribersToRemove = new List<WeakReference>();
      SubscribersFor(eventToPublish.ToClosedSubscriber<T>()).ForEach(weakSubscriber =>
      {
         if (!weakSubscriber.IsAlive)
         {
            subscribersToRemove.Add(weakSubscriber);
         }
         else
         {
            PublishingAction(() => weakSubscriber.AsSubscriber<T>().Handle(eventToPublish));
         }
      });

      if (subscribersToRemove.Any())
      {
         Lock(() => subscribersToRemove.ForEach(removableReference => 
SubscribersFor(referenceList.Target.ToClosedSubscriber<T>()).Remove(removableReference)));
      }
   }

   private void PublishingAction(Action action)
   {
      _context.Post(s => action(), null);
   }

   private List<WeakReference> SubscribersFor(Type subscriberType)
   {
      List<WeakReference> subscribers = null;
      Lock(() =>
      {
         var found = _eventSubscriberLists.TryGetValue(subscriberType, out subscribers);
         if (!found)
         {
            subscribers = new List<WeakReference>();
            _eventSubscriberLists.Add(subscriberType, subscribers);
         }
      });

      return subscribers;
   }

   private void Lock(Action action)
   {
      lock (_lock)
      {
         action();
      }
   }
}

Mir gefiel der Registrierungsansatz mit einem TypeInterceptor besonders sehr gut. Da ich ohnehin meist mit einem IoC Container arbeite, ist eine solche Verwendung naheliegend.

Also findet die Registrierung der Objekte nicht durch das Anmelden von sich selbst statt, wie in den Beispielen von MVVM Light oder dem EA Beispiel von Glenn Block, sondern mittels eines TypeInterceptors.

public class SubscriptionInterceptor : StructureMap.Interceptors.TypeInterceptor
{
   public object Process(object target, IContext context)
   {
      context.GetInstance<IEventAggregator>().Subscribe((target));            
      return target;
   }        

   public bool MatchesType(Type type)
   {
      return type.ImplementsInterfaceTemplate(typeof(ISubscribe<>));
   }       
}

Mal sehen, wie es weiter geht…

Eine ContentControl Id ist eine Id ist nicht immer die gleiche Id

noreply@blogger.com (Jan Christian Selke) — Fri, 17 Dec 2010 20:08:00 +0000

Heute wäre ich fast wieder auf eine kleine, alte Nicklichkeit von Word und dem OpenXml hereingefallen…
Innerhalb von Word habe ich ein Inhaltssteuerelement angelegt und dessen interne Id ermittelt. Diese wird von der Word API als String bereitgehalten. Die MSDN Auskunft dazu ist eindeutig:

Returns a String that represents the identification for a content control. Read-only.

Diese Id wird nun intern von uns als Zahl weiterverarbeitet. – Soweit kein Problem. Aus

long id = long.Parse(contentControl.Id);

erhalte ich die Id 2857609749.

Jetzt musste ich aber anhand dieser Id das Inhaltssteuerelement in der document.xml ermitteln. Zu meiner ersten großen Überraschung war aber keines mit dieser Id zu finden?! Nach etwas Suchen stellte sich heraus, dass das Inhaltssteuerelement anscheinend unter der Id –1437357547 in dem Dokument abgelegt war.

Innerhalb der Word API wird anscheinend die Darstellung als unsigned Wert, also ohne negative Vorzeichen bevorzugt, während innerhalb der Dokumentstruktur auch negative Vorzeichen verwendet werden.

Es bleibe also nichts andere übrig, als zwischen den verschiedenen Darstellungen zu konvertieren.

In meinem Fall lag der String-Wert ohnehin schon als long vor. Daher konnte ich folgenden Aufruf nutzen, um den Word API Wert, in den zu der document.xml zu konvertieren:

long ccid = Convert.ToInt64((int)id);

Der umgekehrte Weg, von der Darstellung aus der document.xml in den von Word bevorzugten Wert erfolgt dann folgendermaßen:

long ccid = Convert.ToInt64((uint)id);

Oder mit noch etwas mehr Konvertierungsaufwand lassen sich die Werte direkt aus dem String-Wert konvertieren:

long ccid = Convert.ToInt64((uint)long.Parse(contentControl.Id));

… Das bietet sicherlich auch noch Optimierungspotential…

Commands als MEF Plugins einbinden

noreply@blogger.com (Jan Christian Selke) — Wed, 15 Dec 2010 15:02:00 +0000

Bei der Nachlese zu meinem letzten Refactoring kam mir eine Idee: Wie wäre es denn das Ganze noch etwas generischer zu gestalten, um den Quellcode gar nicht mehr anfassen zu müssen?! Ich habe dabei daran gedacht, MEF einzusetzen und die Prozesslogik als Plugin einzubinden.
Gut, in der momentanen Form ist es eine Milchmädchenrechnung, da die Flags, anhand derer entschieden wird, sich zur Zeit auch noch im Zielprojekt befinden. Aber dass soll erst einmal nicht beachtet werden – das ist vielleicht eine spätere Baustelle.
Zuerst einmal muss das MEF von Codeplex herunter geladen werden und die Assembly System.ComponentModel.Composition.Codeplex.dll in das Projekt eingebunden werden.
Das Bereitstellen der Prozessor Klassen erfolgt über das Export Attribut. Als Export wird die Schnittstelle IItemProcessor genutzt, da auf diese Weise nur eine Referenz auf die Schnittstelle beinhaltende Assembly benötigt wird.

[Export(typeof(IItemProcessor))]
public class SimpleItemProcessor : IItemProcessor
{
    public void Process(WorkItem item)
    {
        throw new NotImplementedException();
    }
}

Der Import der Typen erfolgt über das Import Attribut. Da hier in eine Liste importiert wird, genauer genommen das ImportMany Attribut.

public class WorkItem
{
    public WorkItem()
    {
        this.Processors = new List<IItemProcessor>();
    }

    [ImportMany(typeof(IItemProcessor))]
    public IList<IItemProcessor> Processors { get; set; }
    ...
    public void Process()
    {
        this.processorList.Where(x => x.CanProcess(this)).Each(proc => proc.Process(this));
    }
}

Jetzt sind Quelle und Ziel vorbereitet, es fehlt nur noch die Konfiguration im Programmstart zum Auffinden der Plugins. Dazu werden die sogenannten Catalogs genutzt. Exporte können sich selbst in einem solchen Katalog registrieren. Dafür stehen verschiedene Typen von Catalogs zur Verfügung. Da in diesem Fall eine Assembly gesucht wird, die im selben Verzeichnis liegt, wie die auszuführende Assembly, nutze ich den DirectoryCatalog.

var catalog = new DirectoryCatalog(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
    var container = new CompositionContainer(catalog);
    var batch = new CompositionBatch();
    batch.AddPart(this);
    container.Compose(batch);

Der Aufruf der Compose Methode startet das Auffinden der Plugins in allen Assemblies des hinterlegten Verzeichnisses. Eine sehr einfache Möglichkeit solche Plugins zu nutzen…

Refactoring: Switch durch Commands ersetzen

noreply@blogger.com (Jan Christian Selke) — Tue, 14 Dec 2010 22:56:00 +0000

Vor Kurzem war es notwendig, bestehenden Quellcode zu erweitern. Eine der entscheidenden Änderungen bestand darin, Prozessablauflogik durch eine neue Variante zu erweitern. Dabei bestand die Möglichkeit eines meiner bevorzugten Refactorings durchzuführen: Das Ersetzen von Conditional Dispatch durch Commands.
Bei meinen Arbeiten bin ich auf ein Konstrukt gestoßen, das ich als nicht besonders hübsch und elegant erachte; Viel entscheidender aber, es fördert weder die Wartbarkeit noch die Erweiterbarkeit. Es handelte sich um einen switch-Block, der stark vereinfacht etwa dem Folgenden entsprach.

public class WorkItem
{
    private ItemSubType itemType;
    public ItemSubType SubType { get; private set; }
    …
    public void Process()
    {
        switch(this.itemType)
        {
            case ItemSubType.Simple:
                // do something simple
            break;
            case ItemSubType.Complex:
                // do something complex
            break;
            default:
                // just do something
        }
    }
}

Nicht nur, dass die Klasse bei jeder Erweiterung aufs Neue angefasst werden muss und damit dem OCP widerspricht, die Methode Process erfüllt damit auch noch mehrere Aufgaben. Also nutzte ich die Möglichkeit, um hier ein wenig zu entkoppeln. Zuerst war die Frage zu klären, spezialisierte WorkItem Klassen anlegen oder einfach die Prozesslogik auslagern. Da sich die Änderungen ausschließlich auf den switch-Block beschränkten, entschied ich mich für die Auslagerung.

Für jeden SubTyp wurde eine Prozessor Klasse angelegt, die die Schnittstelle IItemProcessor implementiert.

public interface IItemProcessor
{
    void Process(WorkItem item);
}

public class SimpleTypeProcessor : IItemProcessor
{
    public void Process(WorkItem item)
    {}
}

public class ComplexTypeProcessor : IItemProcessor
{
    public void Process(WorkItem item)
    {}
}

public class NulloProcessor : IItemProcessor
{
    public void Process(WorkItem item)
    {}
}

Der NulloProcessor entspricht hierbei der Implementierung des Null-Object-Patterns. Der nächste Schritt wäre das Zuweisen des richtigen Processors zur richtigen Zeit. Dazu wird in der Regel eine Factory Klasse genutzt.

public void Process()
{
    var processor = ProcessorFactory.GetProcessor(this.subType);
    processor.Process(this);
}

So hätte ich die Bedingungen zwar aus dem WorkItem heraus genommen, aber nur in die Factory ausgelagert und dort den switch-Block, der immer wieder erweitert werden müsste.

Wie wäre es also, der WorkItem Klasse die Prozessoren von außen herein zu geben und jeden Processor für sich selbst entscheiden lassen, ob er etwas zu tun hat?!

public class WorkItem
{
    IList<IItemProcessor> processorList;
    public WorkItem(IList<IItemProcessor processors, ...)
    {
        this.processorList = processors;
        // something more
    }
    ...
    public void Process()
    {
        this.processorList.Where(x => x.CanProcess(this)).Each(proc => proc.Process(this));
    }
}

public class SimpleTypeProcessor : IItemProcessor
{
    public bool CanProcess(WorkItem item)
    {
        return item.SubType == ItemSubType.Simple;
    }

    public void Process(WorkItem item)
    {
        // Do something simple
    }
}

Die Abfrage auf CanProcess empfand ich noch als zu viel Rauschen. Die einzelnen Prozessoren können doch bei Aufruf ihre Zuständigkeit selbst überprüfen.

public class SimpleTypeProcessor : IItemProcessor
{
    public void Process(WorkItem item)
    {
        if(item.SubType != ItemSubType.Simple) return;
        // Do something simple
    }
}

Innerhalb der WorkItem Klasse wird dann einfach an alle Prozessoren “ge-broadcastet”…

public void Process()
{
    processorList.Each(processor => processor.Process(this));
}

Auf diese Weise habe ich meine Anpassungen letztlich durchgeführt und bin (noch?) recht zufrieden damit.

Lazy loading von Abhängigkeiten mit StructureMap

noreply@blogger.com (Jan Christian Selke) — Thu, 04 Nov 2010 20:00:00 +0000

Das Offensichtliche

Vor kurzem beschäftigte mich die Überlegung: Wie kann ich mit StructureMap meine Abhängigkeiten quasi just-in-time holen? Es gibt ja durchaus Klassen, deren Abhängigkeiten nicht alle sofort und vor allem gemeinsam genutzt werden.

Als ob das nicht genug wäre, habe ich kurz darauf einen Beitrag in der Google-Group zu genau dieser Frage gelesen. Grund genug für mich, das nochmal genauer anzusehen und kompakt für mich zusammen zu fassen.

Wenn man mit StructureMap Lazy Loading realisieren möchte, dann kann ab Version 2.6 anstelle des abhängigen Typs eine Func<DependentType> als Parameter genutzt werden. Diese werden dann erst bei dem tatsächlichen Zugriff evaluiert. Beispielhaft könnte eine Klasse dann folgendermaßen aussehen.

    public class MyType : IMyType
    {
        private readonly Func<IDependency1> _dependency1;
        private readonly Func<IDependency2> _dependency2;

        public MyType(Func<IDependency1> dependency1, Func<IDependency2> dependency2)
        {
            _dependency1 = dependency1;
            _dependency2 = dependency2;
        }

        public void DoSomething()
        {
            var dependency1 = _dependency1();
            dependency1.DoSomething();
        }

        public void DoSomethingElse()
        {
            var dependency2 = _dependency2();
            dependency2.DoSomethingElse();
        }
    }

Eigentlich eine recht einfache Methode, eine einfache Variante des Lazy Loadings zu implementieren. Aber was mir bisher etwas zu kurz kam; funktioniert das wirklich so einfach? Muss ich etwas bei der Registrierung der Typen beachten/anders machen?
Kurz: Nein! Alles bleibt beim alt-bekannten :-).
Für dieses recht einfache Beispiel reicht bereits eine minimale Registrierung.

    ObjectFactory.Initialize(x => x.Scan(scan =>
    {
        scan.TheCallingAssembly();
        scan.WithDefaultConventions();
    }));

    myType = ObjectFactory.GetInstance<IMyType>();

Die Magie

Für alle, die etwas mehr Hintergrundinformation haben möchten - Die Magie dahinter verbirgt sich in der Anwendung des Typs LazyInstance<T> :

    public class LazyInstance<T> : Instance
    {
        protected override string getDescription()
        {
            return "Lazy construction of " + typeof (T).FullName;
        }

        protected override object build(Type pluginType, BuildSession session)
        {
            var container = session.GetInstance<IContainer>();
            Func<T> func = () => container.GetInstance<T>();

            return func;
        }
    }

Die Func<> Konstruktor Argumente werden von StructureMap als LazyInstance<> registriert. Lediglich die Typen müssen registriert sein (sei es wie oben durch DefaultConventions oder durch manuelle Registrierung), den Rest macht StructureMap.
Der Func<T> wird zugewiesen

() => container.GetInstance<T>()

Schon werden Abhängigkeiten bei Bedarf nachgeladen.
Registriert wird der Lazy-Typ übrigens im BuildUp des Containers…

    var funcInstance = new FactoryTemplate(typeof (LazyInstance<>));
    _pluginGraph.FindFamily(typeof(Func<>)).AddInstance(funcInstance);
    _pluginGraph.ProfileManager.SetDefault(typeof(Func<>), funcInstance);

Das FactoryTemplate hat wiederum eine Methode zum Schließen der offenen generischen Funcs… ;-)

Einstiegshürden mit Fluent NHibernate und dem Oracle Instant Client

noreply@blogger.com (Jan Christian Selke) — Sat, 25 Sep 2010 19:07:00 +0000

NHibernate kenne ich nun schon eine Weile, auch Fluent NHibernate ist mir – zumindest theoretisch – kein Unbekannter mehr. Außer einem sehr flüchtigen Versuch damit einen kleinen Prototypen zu entwickeln, gab es damit noch wenig Berührungspunkte. Jetzt habe ich es doch versucht und habe prompt die Eine oder Andere Fallgrube mitgenommen. Das gab mir Grund genug, etwas darüber zu schreiben.

Schon vor einiger Zeit habe ich einen sehr schönen Einstiegsartikel von Jürgen Gutsch gelesen. Eine willkommen Hilfe dabei, mich intensiver mit dem Thema zu beschäftigen. Also holte ich auf der einen Seite das Visual Studio 2010 heraus, auf der anderen Jürgens Artikel und es konnte los gehen (an dieser Stelle noch ein kleines Dankeschön für die gelungene Einstiegshilfe :-)).

Jetzt verwendete ich als Datenbank nicht den SQL Server und folglich nicht die SQL Server Client Verbindung, sondern Oracle Express und den Oracle Instant Client. Ich tat es erst einmal als Marginalie ab – ein Trugschluss, wie sich heraus stellte. Ich möchte damit nicht sagen, dass der Einstieg in dieser Kombination mit Fluent NHibernate schwierig ist. Es sind aber anfänglich schon die eine oder andere Hürde, die genommen werden möchten.

Genug der Vorrede, es kann losgehen. Zunächst habe ich die aktuellste Version von FluentNHibernate heruntergeladen und entpackt. Aus dem gesamten Verzeichnis habe ich die folgenden Assemblies in mein Testprojekt eingebunden:

FluentNHibernate.dll
NHibernate.dll
NHibernate.ByteCode.Castle.dll

Schon ein erstes Kompilieren war spontan nicht von Erfolg gekrönt :-(. In der Zusammenfassung hagelte es folgende Fehler:

The referenced assembly "NHibernate.ByteCode.Castle" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
The referenced assembly "NHibernate" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
The referenced assembly "FluentNHibernate" could not be resolved because it has a dependency on "System.Data.OracleClient, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".

Ok, die Meldung ist recht eindeutig –Mist, schon wieder vergessen... Also rein in die Projekteinstellungen und das Target framework entsprechen umsetzen.

Wunderbar – Jetzt baut es wenigstens schon einmal fehlerfrei. Es kann also weiter gehen. Jetzt muss der Datenbankzugriff konfiguriert werden. Ich habe den Zugriff erst einmal vollständig im Quellcode abgebildet. Es sah dann schließlich folgendermaßen aus:

ISession session = Fluently.Configure()
    .Database(OracleClientConfiguration.Oracle10.ConnectionString(cs =>
        cs.Instance("xe")
            .Server("localhost")
            .Port(1521)
            .Username("myuser")
            .Password("mypassword"))
        .ProxyFactoryFactory(typeof(NHibernate.ByteCode.Castle.ProxyFactoryFactory))
        .ShowSql())
    .Mappings(m => m.FluentMappings.AddFromAssemblyOf<IEntity>()).BuildSessionFactory().OpenSession();

Das Kompilieren funktionierte auch, also los - mit dem Test starten. Und schon fing ich mir die erste Laufzeit Ausnahme ein: OCIEnvCreate failed with return code -1 but error message text was not available.

Nach kurzer Suche hatte ich die Lösung. Ich habe den falschen Provider gewählt. Wenn der Instant Client statt des Microsoft Clients verwendet wird, ist nicht die Klasse OracleClientConfiguration zu verwenden, sondern OracleDataClientConfiguration. Gut zu wissen. Kurze Anpassung.

ISession session = Fluently.Configure()
    .Database(
        OracleDataClientConfiguration.Oracle10.ConnectionString(cs =>
            cs.Instance("xe")
                .Server("localhost")
                .Port(1521)
                .Username("myuser")
                .Password("mypassword"))
            .ProxyFactoryFactory(typeof(NHibernate.ByteCode.Castle.ProxyFactoryFactory))
        .ShowSql())
    .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Form1>()).BuildSessionFactory().OpenSession();

Kompiliert und weiter im Test. –Rumms! Die nächste Laufzeit Ausnahme – schon wieder… Immerhin ist schon in der vierten inneren Ausnahme die Lösung zu finden ;-).

Richtig, ich hatte nur die XCopy Installation des Instant Clients durchgeführt. Keine Installation in den GAC mit den mitgelieferten Skripten. In das Ausführungsverzeichnis hatte ich die Oracle.DataAccess.dll auch noch nicht kopiert. Kein Wunder also. Schnell die Assembly in das /bin Verzeichnis kopiert und sie da: Ich konnte endlich auf die Datenbank zugreifen! Nach all den kleinen Startschwierigkeiten funktionierte endlich mein Datenbankzugriff mit Fluent NHibernate.

Es fehlte nur eine Kleinigkeit; dass Auslagern der Zugriffsinformationen in einen ConnectionString. Gesagt, getan:

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="FNH.Properties.Settings.Lokal" connectionString="User Id=myuser;Password=mypassword;Data Source=localhost:1521"
        providerName="Oracle.DataAccess.Client" />
  </connectionStrings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

Dazu muss natürlich auch der Konfigurationsaufruf entsprechend angepasst werden:

ISession session = Fluently.Configure()
    .Database(OracleDataClientConfiguration.Oracle10.ConnectionString(cs =>
            cs.FromConnectionStringWithKey("FNH.Properties.Settings.Lokal"))
                .ProxyFactoryFactory(typeof(NHibernate.ByteCode.Castle.ProxyFactoryFactory))
        .ShowSql())
    .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Form1>()).BuildSessionFactory().OpenSession();

Was lange währt, … Schwierig war es letztlich wirklich nicht, aber ich habe anscheinend traumwandlerisch alles erwischt, was nicht funktionieren könnte. Das nächste Mal geht es mit Sicherheit deutlich schneller :-)

Tabellen in Word Dokumenten auf Vorlagenbasis erweitern - Reloaded

noreply@blogger.com (Jan Christian Selke) — Fri, 24 Sep 2010 20:07:00 +0000

Schon vor einiger Zeit habe ich über das vorlagenbasierte Erweitern von Tabellen geschrieben. Vor kurzem wurde in einem Kommentar um Hilfe gebeten, den Quellcode in VB.Net umzusetzen. Meine Neugier war nahezu sofort geweckt, wie es wohl tatsächlich in VB.Net aussehen könnte.

So habe ich mich daran gemacht, den Quellcode zu portieren. Die erste Lösung war eine nahe 1:1 Umsetzung des Quellcodes. Einige Änderungen waren notwendig, wie etwa der Aufruf von TypParametern. Aus MyType<MyTypeParamter> wurde unter VB.Net beispielsweise MyType(Of MyTypeParameter).

Das Ergebnis sieht nun wie folgt aus.

Using package As WordprocessingDocument = WordprocessingDocument.Open(fileName, True)
    Dim mainDocumentPart As MainDocumentPart = package.MainDocumentPart
    Dim document As Document = mainDocumentPart.Document
    Dim sdt As SdtBlock = document.Descendants(Of SdtBlock) _
        .Where(Function(sdtBLock) sdtBLock.GetFirstChild(Of SdtProperties) _
            .GetFirstChild(Of Tag).Val.Value = "Tabelle") _
        .First

    For i As Integer = 0 To 5

        Dim lastRow As DocumentFormat.OpenXml.Wordprocessing.TableRow = sdt.Descendants(Of Table).First.Descendants(Of TableRow).Last
        lastRow.InsertAfterSelf( _
            New DocumentFormat.OpenXml.Wordprocessing.TableRow( _
                New DocumentFormat.OpenXml.Wordprocessing.TableCell(New DocumentFormat.OpenXml.Wordprocessing.Paragraph(New DocumentFormat.OpenXml.Wordprocessing.Run(New DocumentFormat.OpenXml.Wordprocessing.Text(String.Format("Zeile {0}: Zelle 1", (i + 2)))))), _
                New DocumentFormat.OpenXml.Wordprocessing.TableCell(New DocumentFormat.OpenXml.Wordprocessing.Paragraph(New DocumentFormat.OpenXml.Wordprocessing.Run(New DocumentFormat.OpenXml.Wordprocessing.Text(String.Format("Zeile {0}: Zelle 2", (i + 2)))))), _
                New DocumentFormat.OpenXml.Wordprocessing.TableCell(New DocumentFormat.OpenXml.Wordprocessing.Paragraph(New DocumentFormat.OpenXml.Wordprocessing.Run(New DocumentFormat.OpenXml.Wordprocessing.Text(String.Format("Zeile {0}: Zelle 3", (i + 2))))))))
    Next
End Using

Das gefiel mir syntaktisch eigentlich nicht besonders gut. Besonders die LINQ Erweiterungsmethoden mit den anonymen Methoden waren mir ein Dorn im Auge. Also habe ich noch etwas weiter gesucht und mich schließlich für eine Version mit der LINQ Abfrage Syntax entschieden. Dies lässt sich nun meines Erachtens deutlich einfacher lesen. Bedauerlicherweise war ich hierbei nur bedingt erfolgreich.

Wer hier mehr Erfahrung hat und mehr Kürze in die Abfragen bringen kann, soll sich hiermit dazu aufgerufen fühlen! ;-)

Ich hoffe, das hilft fürs erste auch weiter. Ich freue mich immer über solche Anreize, wieder etwas Neues auszuprobieren. :-)

Erste Gehversuche mit MVVM Light

noreply@blogger.com (Jan Christian Selke) — Sun, 19 Sep 2010 22:44:00 +0000

Vor Kurzem habe ich mich dazu entschlossen, erste Schritte mit dem MVVM Light von Laurent Bugnion in der WPF Entwicklung zu versuchen. Eines muss man diesem Framework lassen, es ist wirklich einfach und schnell damit produktiv zu werden.

Kurzerhand habe ich die aktuelle Version 3 als ZIP Paket herunter geladen und entpackt. Der Anfang ist altbekannt: Neues WPF Projekt im Visual Studio angelegt, die WPF4 Assemblies in mein Prototypen Projekt eingebunden - los gings.

Meine erste Versuche beschäftigten sich mit dem Commanding. Innerhalb meines Prototypen fügte ich vorerst mal nur einen TreeView ein. Bei Doppelklick auf einzelne Elemente sollte ein kleines Fenster für Detailinformationen geöffnet werden. Da der TreeView eine solche Funktionalität nun mal nicht out-of-the-box liefert, habe ich mir das Command Binding des MVVM Light zunutze gemacht. Was soll ich sagen – es war klasse.

Als erstes habe ich den Commanding Namespace eingebunden.

using GalaSoft.MvvmLight.Command;

Dann in meinem ViewModel eine Eigenschaft vom Typ RelayCommand hinzugefügt, der im Konstruktor die Funktionalität zugewiesen wurde.

public DokumentViewModel(Dokument dokument)
{
    _dokument = dokument;
    ShowDokument = new RelayCommand(() => Messenger.Default.Send(new ShowDokument(Id)));
}

public RelayCommand ShowDokument { get; private set; }

Innerhalb des Xaml Codes habe ich dann das Command mit Hilfe eines Triggers an den TreeView gebunden: fertig! …Und es lief auf Anhieb.

<TreeView ItemsSource="{Binding Mappe}">
    <TreeView.Resources>
    …
        <DataTemplate DataType="{x:Type ViewModel:DokumentViewModel}">
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding Id}">
                    <i:Interaction.Triggers>
                        <i:EventTrigger EventName="MouseDoubleClick">
                            <cmd:EventToCommand Command="{Binding ShowDokument"/>
                        </i:EventTrigger>
                    </i:Interaction.Triggers>
                </TextBlock>
            </StackPanel>
        </DataTemplate>
    </TreeView.Resources>
</TreeView>

Wenn das nicht einfach ist. ;-) Zu diesem Zeitpunkt kannte meine Begeisterung keine Grenzen mehr. Wenn das so leicht weiter geht, dachte ich mir, ist das schon so gut wie fertig. :-)

Wie schon in der Command Zuweisung oben zu erkennen ist, habe ich mir direkt dabei bereits den Messenger angesehen und genutzt, der mit dem MVVM Light kommt. Dazu flugs den Namespace Messaging eingebunden.

using GalaSoft.MvvmLight.Messaging;

Auch hier war mein erster Eindruck hervorragend. Die gesendete Nachricht, aus dem obigen Codebeispiel, wird von einem registrierten Listener verarbeitet.

public class DokumentListener
{
    public DokumentListener()
    {
        Messenger.Default.Register<ShowDokument>(typeof(ShowDokument), x => Handle(x));
    }

    public void Handle(ShowDokument message)
    {
        ...
    }
}

Grundsätzlich gefällt mir dieser Messenger zum Einstieg auch noch immer, ein bisschen Bauschmerzen habe ich aber bekommen.

Was mir nicht gefällt, ist die Tatsache, dass die Listener Klasse den Messenger kennt. Dies ist eine Abhängigkeit, auf die ich gerne verzichten würde. Außerdem muss jede behandelbare Nachricht einzeln in der Klasse registriert werden, was bei zentralen Klassen mehr Aufwand bedeuten kann. Was mir ebenfalls nicht besonders gut gefällt, ist die Tatsache, dass Klassen, die Nachrichten behandeln können, nicht sofort durch ein Muster/Namensgebung erkennbar sind.

Da ohnehin mit DI Frameworks gearbeitet wird, halte ich eine eigene Interceptor Implementierung mit festen Konventionen in Kombination mit einem eigenen Messenger für die Registrierung von Listenern an einem Messenger für die bessere Variante.

Ich werde nach dem jüngsten Stand die Funktionalität zum Binden von Commands des MVVM nutzen. Den Messenger werde ich mir aber voraussichtlich maßschneidern und meinen Vorstellungen entsprechend anpassen. Vielleicht werde ich darüber ein anderes mal schreiben…

Interessante Word-Autokorrektur

noreply@blogger.com (Jan Christian Selke) — Fri, 06 Aug 2010 20:39:00 +0000

Das Microsoft Word nicht zuletzt auch aufgrund der Unterstützung des transienten Schemas recht fehlertolerant ist, ist bekannt. Einen besonders interessanten Effekt, der bei fehlerhafter Dokumentstruktur auftreten kann, habe ich vor Kurzem zu Augen bekommen.

Es begann damit, dass wir ein neues Dokument erzeugt haben. Dabei haben wir den Fehler begangen, dass der Inhalt eines ContentControls auf body Ebene vollständig geleert wurde.

Die Folge war nun, dass nach dem ersten Bearbeiten und Speichern des Dokuments, die Struktur innerhalb des Dokuments verschoben wurde. Der Unterschied kann bereits in der Entwicklungsansicht in Word ausgemacht werden.

Was genau passierte hier aber?

Word korrigierte das Dokument selbstständig, indem der nächst folgende Paragraf in das leere ContentControl verschoben wurde. In diesem Fall handelt es sich dabei um den Paragrafen mit dem Text Textparagraf nach dem leeren ContentControl.

Nach dem Speichern weist das Dokument jetzt folgende Struktur auf.

Fazit

Word ist in der Tat sehr Fehlertolerant, allerdings werden mit dem Speichern automatische Korrekturen vorgenommen, die zum Teil nur schwer erkannt werden können. Diese Korrekturen können aber erhebliche Veränderungen in der Dokumentstruktur nach sich ziehen, die eine automatische Weiterverarbeitung der Dokumente unter Umständen stark beeinträchtigen können.

Scrum Prozessvorlage für TFS

noreply@blogger.com (Jan Christian Selke) — Fri, 18 Jun 2010 08:25:00 +0000

Zwar nicht mehr brandaktuell, aber Microsoft bietet seit Anfang des Monats die Beta Version einer Scrum Prozessvorlage für den TFS zum kostenlosen Download an. Mehr dazu findet sich hier.

Folgende Punkte werden mit der Vorlage abgedeckt:

Work Item Types
- Product Backlog Item
- Bug
- Task
- Impediment
- Test Case
- Sprint
Reports
- Release Burndown
- Velocity
- Sprint Burndown
SharePoint Project Portal

Konstruktorinjektion unterschiedlicher Instanzen eines Typs mit StructureMap

noreply@blogger.com (Jan Christian Selke) — Thu, 17 Jun 2010 06:26:00 +0000

In einem Projekt, in dem wir StructureMap als DI Container nutzen, standen wir vor einem kleinen Rätsel. Wir hatten einen Typ, der im Konstruktor als Parameter zwei unterschiedliche Objekte des gleichen Typs erwartete.

public interface IMojo
{
    …
}
 

public class Mojo
{
    public Mojo(IFooBar fooBar1, IFooBar fooBar2)
    {
        …
    }
    ...
}

Zuerst haben wir hier die StructureMap Standardregistrierung genutzt.

For<IMojo>().Use<Mojo>();
For<IFooBar>().Use<FooBar>();

Das hatte aber zur Folge, dass nicht zwei Instanzen des Typs als Parameter injiziert wurden (was ich eigentlich aufgrund des transienten LifeCycles erwartet hatte), sondern zweimal die selbe Instanz. Ein andere Lösung musste also her.
Kurz gesagt: wir haben letztlich benannte Instanzen genutzt. Ich weiß, dass es unterschiedliche Ansichten über Sinn und Unsinn von benannten Instanzen gibt – in diesem Fall funktioniert es damit aber für uns. Falls jemand eine andere Idee hat, bin ich für Anregungen offen ;-).
Die Registrierung sieht zum Schluss nun wie folgt aus:

For<IFooBar>().Use<FooBar>().Named("foo1");
For<IFoorBar>().Use<FooBar>().Named("foo2");

For<IMojo>().Use<Mojo>()
    .Ctor<IFooBar>("fooBar1").Is(x => x.TheInstanceNamed("foo1"))
    .Ctor<IFooBar>("fooBar2").Is(x => x.TheInstanceNamed("foo2"));

Buildautomation mit Hudson in der dotnetpro

noreply@blogger.com (Jan Christian Selke) — Wed, 16 Jun 2010 19:11:00 +0000

Mit etwas stolz habe ich gesehen, dass der Artikel Bitte ein Build! Software automatisiert mit Hudson bauen, den ich gemeinsam mit meinem Kollegen André Krämer geschrieben habe, in der aktuellen Ausgabe 07/2010 der dotnetpro erschienen ist.

Wir stellen einen im .Net Umfeld eher unbekannten Vertreter der Buildserver vor: Hudson. Weit verbreitet in der Java Welt stellt er als OSS auch eine mächtige und kostengünstige Alternative zu Buildservern wie dem TFS oder CruiseControl.Net dar.

Also, lesen… ;-)

DI/IoC und StartUp in VSTO Projekten

noreply@blogger.com (Jan Christian Selke) — Tue, 04 May 2010 21:40:00 +0000

Vor einiger Zeit schrieb ich über einen Ansatz in VSTO Projekten das MVP Pattern einzusetzen und damit auch – zumindest mehr oder weniger indirekt – über Testbarkeit und DI. Zugegeben, damals fand ich den Ansatz schon recht gut. Recht gut finde ich den Ansatz noch immer, aber so richtig zufrieden war ich damit eigentlich nicht.

Als Konsequenz habe ich immer wieder darüber nachgedacht, wie der Ansatz weiter verfeinert werden könnte. Mittlerweile bin ich bei einer Variante angekommen, die ich noch wieder ein Stück weit besser finde.

Was mich an der ersten Variante besonders störte, war die Initialisierung des AddIns und das Anhängen des ersten Presenters an den Ribbon. Den passive view Ansatz halte ich mittlerweile auch nicht mehr für notwendig. Die Logik muss nicht maximal von der Oberfläche isoliert werden. Es kann also genauso gut ein anderes presentation pattern, etwa der supervising controller, angewandt werden. Hierbei handelt es sich aber eher um eine Frage des persönlichen Geschmacks.

Das eigentliche Thema ist also der Einstieg ins bzw. die Initialisierung des AddIns. Viele AddIns weisen sich durch komplexere Initialisierungslogik aus. Damit diese aber nicht etwa die Word Instanz vor weiterer Ausführung blockiert, sollte die Initialisierung asynchron im Hintergrund ablaufen. Zuerst dachte ich an den guten alten Backgroundworker: Nach einiger dieser erschien mir aber schnell als etwas zu umständlich, schwerfällig und unflexibel.

Die Lösung, für die ich mich letztlich entschieden habe, ist eine Variante des Command Executors. Der erste Aufruf erfolgt innerhalb der StartUp-Methode des AddIns.

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
    new BackgroundExecutor(new SynchronizationContext()).Execute(() =>
    {
        new Bootstrapper().BootstrapAddInDIContainer<IRibbonPresenter<IRibbonView>>();
        return () => this.Initialized = true;
    });
}

Die Rückmeldung an das AddIn erfolgt als continuation. Das Initialisierungsflag des AddIns wird gesetzt und damit erst die Funktionalität des AddIns zur Verfügung gestellt. So bleibt Word trotz möglicher aufwändiger Initialisierungslogik reaktionsfähig.

Bleibt die Frage, wie wird der Presenter zugewiesen? Dies steckt bereits im Bootstrapper des DI Containers. In meinem Beispiel verwende ich mal wieder StructureMap.

public STARTTYPE BootstrapAddInDIContainer<STARTUPTYPE>() where STARTUPTYPE : class
{
    var container = BuildUpContainer();
    return container.GetInstance<STARTUPTYPE>();
}

Nachdem der Container konfiguriert und aufgebaut ist, wird der Presenter ein Mal aus dem Container abgerufen. Aufgrund der Anweisung mit OnCreationForAll(Action<PLUGINTYPE>) wird ein TypeInterceptor registriert, der die hinterlegte Aktion gegen jede neu erstellte Instanz durchführt.

public class AddInRegistry : Registry
{
    public AddInRegistry()
    {
        For<IRibbonPresenter<IRibbonView>>().Use<RibbonPresenter>();
        For<IRibbonPresenter<IRibbonView>>().OnCreationForAll(x =>
            x.View = (IRibbonView) Globals.Ribbons.FirstOrDefault(y =>
                y is MvpDiSampleRibbon));
    }
}

Der AddIn Ribbon wird aus der Liste der Ribbons ausgelesen und als View für den Presenter übergeben. Und da diese Instanz nur einmal beim StartUp abgerufen wird und dabei an den Ribbon gebunden wird, muss man sich keine Sorgen über Mehrfachinstanziierungen machen.

Mal abwarten, an welchem Teil ich als nächstes weiter drehen werde…

Ist der Entwicklerspaß mit C# 2.0 vorbei?

noreply@blogger.com (Jan Christian Selke) — Mon, 03 May 2010 21:18:00 +0000

C# 4.0 und dynamics sind cool.

C# 3.5 mit extension methods, lamda-Ausdrücken und LINQ war fast noch spannender… was aber ist mit 2.0?

Leider hat man nicht immer die Chance in Projekten mit der neuesten Technologie zu arbeiten. Es gibt schließlich auch noch Pflege-Projekte, die auf einer älteren Version aufsetzen, aber auch betreut sein wollen. Ist dann der Spaß vorbei?!

Nein. Die Syntax wirkt vielleicht nicht mehr ganz so elegant; lambda-Ausdrücke und extension methods gibt es schließlich noch nicht. Dafür gibt es aber noch immer die anonymen Methoden. Diese werden, völlig zu unrecht, zu wenig beachtet.

Sicherlich, Entwicklung darf nicht allein auf den Spaß reduziert werden - aber es macht doch auch einen großen Anteil aus. Wer keinen Spaß hat, ist nicht kreativ. Wer allgemein keinen Spaß daran hat, sollte sich lieber überlegen, ob er wirklich das Richtige tut…

Zurück zum Thema. Anonyme Methoden bieten beachtliche Möglichkeiten. Mit dem 3.5er Framework wurde das Rad der Sprache nicht neu erfunden. Deutlich wird dies bereits an einem einfachen Quelltextauszug.

var liste = new List<string>{"Test", "Test2"};
liste.Any(x => x.Contains("Test"));

Schaut man sich nun das Kompilat in einem Reflektor an, stellt man fest: Es gibt nichts bedeutend neues.

List<string> <>g__initLocal0 = new List<string>();
<>g__initLocal0.Add("Test");
<>g__initLocal0.Add("Test2");
<>g__initLocal0.Any<string>(delegate (string x) {
    return x.Contains("Test");
});

Der Typ-Initialisierer wird in Einzelaufrufe ausgewertet und der lambda-Ausdruck in eine anonyme Methode übersetzt. Also sind lambdas im Endeffekt auch nichts anderes als hübsch verpackte anonyme Methoden und damit, mit Ausnahme der Anwendung in extension methods, auch in 2.0 umsetzbar.

Auf diesem Wissen aufbauend, habe ich vor kurzem eine FileService Klasse geschrieben. Dieser Service macht nichts anderes, als ein byte-Array in eine Datei zu schreiben. Der Kontrakt dieses Service ist relativ schmal gehalten. Auffällig sind nur die Methoden Write(…), die zum Einen einen Action delegate als Paramter erwarten, zum Anderen als Rückgabewert einen Typ von sich selbst übergeben. Alles bereits in Vorbereitung auf das method chaining im Stile einer fluent API.

public interface IFileService 
{ 
    void Write(Action<FileExpression> expression); 
    IFileService Write(byte[] bytes); 
    void ToFile(string path); 
}

Auch die Implementierung ist noch recht übersichtlich. Alles weder Hexenwerk noch Raketentechnik…

public class FileService : IFileService 
{ 
    private byte[] fileBytes; 

    public FileService() 
    { 
    } 

    public void Write(Action<FileExpression> expression) 
    { 
        expression(new FileExpression(this)); 
    } 

    public IFileService FileContent(byte[] bytes) 
    { 
        this.fileBytes = bytes; 
        return this; 
    } 

    public void ToFile(string path) 
    { 
        FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite); 
        using (BinaryWriter bw = new BinaryWriter(fs)) 
        { 
            bw.Write(this.fileBytes); 
        } 
    }
}

Über den fertigen Service habe ich dann einen Expression Builder gebaut. Als Einstiegspunkt dient die Methode Write(Action<FileNameExpression> expression). Der Expression Builder sieht wie folgt aus:

public class FileExpression 
{ 
    private readonly IFileService Service; 

    public FileExpression(IFileService service) 
    { 
        Service = service; 
    } 

    public FileExpression File(byte[] bytes) 
    { 
        this.Service.FileContent(bytes); 
        return this; 
    } 

    public FileSaveAction Named(string filename) 
    { 
        return new FileSaveAction(this.Service, filename); 
    } 
}

Der Expression Builder nimmt die spätere Datei als byte[] in der Methode File(byte[]) und den Dateinamen in der Methode Named(string) entgegen. Die Expression wird schließlich mit einer entsprechenden FileSaveAction beendet. Diese nimmt den vorher festgelegten Namen sowie das byte[] entgegen und schreibt es via ToDisc() mittels unterlegtem Service auf die Festplatte.

public class FileSaveAction 
{ 
    private readonly IFileService service; 

    private readonly string filename; 

    public FileSaveAction(IFileService service, string filename) 
    { 
        this.service = service; 
        this.filename = filename; 
    } 

    public void ToDisc() 
    { 
        this.service.ToFile(filename); 
    } 
}

Der Aufruf zum Speichern der Datei wird dann im Code folgendermaßen zusammengesetzt.

IFileService fileService = new FileService();
fileService.Write(delegate(FileExpression x) 
    { 
        x.File(queryResult.Content).Named(queryResult.SuggestedFileName)).ToDisc(); 
    });

An der einen oder anderen Stelle kann nochmal ein Refactoring angesetzt werden, aber hey! Jetzt soll noch einmal jemand sagen, dass C# unter .Net 2.0 nicht auch schon spannend wäre! :-)

Geplante Neuerungen in StructureMap 3.0

noreply@blogger.com (Jan Christian Selke) — Sun, 02 May 2010 12:38:00 +0000

Voraussichtlich noch diesen Monat wird es die Version 3.0 von StructureMap geben.

Jeremy D. Millers eigenem Bekunden zu folgen, sind die beiden Highlights der neuen Version

das Löschen aller obsoleten Methoden,
verbesserter Support für nested containers.

Dem möchte ich noch das verbesserte object tracking hinzufügen. Ebenfalls interessant klingen On StartUp Actions, auch wenn mir noch nicht ganz klar ist, was genau darunter zu verstehen ist…

Wer sich dafür interessiert, kann die vollständigen Release Plans bei github einsehen.

Artikel in der Visual Studio One

noreply@blogger.com (Jan Christian Selke) — Fri, 30 Apr 2010 19:55:00 +0000

Heute ist es soweit! Mein Artikel zum Thema Open Xml mit dem Titel “Word-Dokumente am laufenden Band” wurde in der aktuellen Ausgabe 03/2010 der Visual Studio One Ausgabe abgedruckt.

Ein kurzer Teaser meines Artikels kann hier eingesehen werden.

Alle, denen der Artikel gefallen hat, dürfen sich gerne an der laufenden Umfrage der Visual Studio One beteiligen und dafür abstimmen. ;-)