RavenDB, Docker and F#


Here is a little F# application which connects to a RaveDB database, adds an entry and reads them. I used this application to play with RavenDB running inside a Docker container.

open Raven.Client.Documents

type Customer = {
    FirstName: string
    LastName: string
}

[<EntryPoint>]
let main argv =
    printfn "Hello RaveDB!"

    use store = new DocumentStore ()
    store.Urls <-  [|"http://10.0.75.1:8080"|]
    store.Database <- "RavenDB1"
    use store = store.Initialize ()
    
    use session = store.OpenSession ()
    let customer1 = { FirstName = "Guy"; LastName = "Montag" }
    session.Store customer1
    session.SaveChanges ()

    let customers = query {
        for customer in session.Query<Customer>() do
        select customer
    }

    customers |> Seq.iter (printf "%A")

    printfn "Done!"
    0

You can download the full project from my GitHub repository.

https://github.com/chuchu/sandbox/tree/master/ravendb/raven1

From the code you can see that the database runs on 10.0.75.1 which is the IP address of my Docker bridge.

To execute a RavenDB Docker container you need to download the image first. You can do this by executing the command:

docker pull ravendb/ravendb

This will download the latest ubuntu based version. To run the image its best to use the run-ubuntu1604.ps1 powershell script which is provided by the RavenDB project.

ubuntu1604.ps1 -AuthenticationDisabled -PublicServerUrl "http://10.0.75.1:8080"

Disabling authentication is good for testing purposes. So there is no need to deal with certificates. Why it is necessary to provide the PublicServerUrl is something what I don’t really understand completely. But this article explains it a little bit.

https://ayende.com/blog/178819/bug-stories-how-do-i-call-myself

Now you can open your browser, go to http://10.0.75.1:8080 and create the database RavenDB1. When the database is up and running the application can be executed.

dotnet run

When everything works as expected the F# application can be deployed in a container too. Before the image can be created you need to make a release build.

dotnet publish -c release -o app

The docker file is available in the repository. So you just need to type

docker build -t hello-ravendb .

Have a look for the line

Successfully built 388344c214f3

Your ID is surely different, but you need it to run your image.

docker run 388344c214f3

You should see the same output as when the application was executed directly.

Avoid subscribing to events in constructors


While adopting a unit test I found a piece of code which looks pretty much like this one:

public Subscriber(Printer printer, string message)
{
    printer.Print += OnPrint;

    if (message == null)
    {
        throw new ArgumentNullException("message");
    }

    myMessage = message;
}

This is the constructor of a class called Subscriber. In the first statement it subscribes an external event. Afterwards it checks a message parameter and might throw an exception. The following question comes to my mind. What happens to the event when the exception is thrown? Is there some zombie object assigned to the Print multicast delegate? Indeed it is! When you have the following code:

var s = new Subscriber(printer, null);

You will get an exception, but the instance was created somehow. The assignment to the s variable did not happen because of the exception but it is there. Typically the instance would be deleted with the next garbage collector run, but not when someone keeps a reference. In case of the Subscriber the Printer class keeps a reference with its Print event and so it cannot be garbage collected. What makes it even worse is, that the event handler of the zombie instance is called when the Print event is raised.

So be very careful when subscribing to events in constructors. If anything they should appear as last statement.

File System Redirector


Wenn man aus einem 32 Bit Prozess heraus versucht eine Anwendung zu starten die unter C:\Windows\System32 liegt, wird der Pfad direkt zu C:\Windows\SysWOW64 übersetzt. Der Grund dafür ist, dass unter System32 die 64 Bit files liegen und unter SysWOW64 die 32 Bit Versionen. Für die Umleitung ist der File System Redirector verantwortlich. Das ist zwar alles ganz praktische, aber was wenn man aus dem 32 Bit Prozess wirklich die 64 Bit Anwendung starten möchte?

Dieses Problem hatte ich zum Beispiel mit Visual Studio. Ich wollte ein Powershell Script per external Tool einbinden, welches alle Prozesse beendet, die eine bestimmte DLL geladen haben. Die 32 Bit Powershell kann aber scheinbar nicht die Module eines 64 Bit Prozesses auflisten. Deshalb muss man die 64 Bit Version verwenden. Also habe ich im VS C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben. Seltsamerweise hat dann mein Script aber nicht funktioniert. Nach etwas Suchen habe ich im process explorer gesehen,  dass immer die 32 Bit Powershell gestartet wird. Obwohl ich extra die 64  Bit Version angegeben habe. Stackoverflow brachte mich dann auf den File System Redirector und die Lösung für mein Problem. Man muss %windir%\sysnative als system Pfad verwenden. Dieser wird dann auch nicht geändert. Es muss also %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben werden.

dodned Usergroup Franken


Gestern war ich zum ersten Mal auf einem Treffen der dotned Usergroup Franken und habe auch zum ersten Mal an einem coding dojo teilgenommen.

Es war wirklich sehr Witzig das FizzBuzz „Problem“ mittels TDD und mit pair programming zu lösen. Trotz der einfachen Natur der Aufgabenstellung ist es interessant wie viele Diskussionen es  über die Implementierung der Lösung gab. Das zeigt eines ganz deutlich: Kein Problem ist so einfach, als dass man es mit VHIT (vom Hirn ins Terminal) lösen sollte.

Beim nächsten Treffen bin ich auch wieder dabei 😉

Enumerations als bit fields verwenden


Als ich letztens einen Unittest schrieb, fiel mir auf, dass ich in vielen Tests immer wieder die selbe Methode des Testees aufrief. Alles was sich änderte waren die Stubs und die Mock Objekte. Das Ganze sah ziemlich schlecht aus. Es musste sich doch irgendwie vereinfachen lassen. Ich versuchte also den Code in eine neue Methode auszulagern. Diese könnte ich dann von meinen Tests aus aufrufen. Aber wie konnte ich die Parameter so gestalten, dass die Signatur übersichtlich blieb? Da fiel mir ein, dass ich schon mal irgendwo gesehen hatte wie man enumerations als bit fields verwenden kann:

Ausgangspunkt soll folgendes enum sein:

public enum Colors
{
    None,
    Red,
    Green,
    Blue
}

Da enumerations eine Art name/value pair collection sind, kann man jeden Eintrag auf eine Zahl mappen. Die folgende Schleife tut dies für die Werte 0 bis 7 und gibt den Namen aus:

for (int i = 0; i < 8; i++)
{
    Console.WriteLine("{0,3} - {1}", i, ((Colors)i).ToString());
}

Das enum von oben liefert folgendes Ergebnis:

0 – None
1 – Red
2 – Green
3 – Blue
4 – 4
5 – 5
6 – 6
7 – 7

Das ist recht unspektakulär. Der C# Compiler hat einfach für jeden Eintrag im enum einen Zahlenwert vergeben. Von 0 beginnend, bis 3. Wenn man die Enumeration um das Flags Attribut ergänzt, ändert sich die Ausgabe noch nicht wirklich. Eigentlich traurig, weil man das enum dann immer noch nicht als Bitfeld verwenden kann.

Bei einem binären wert von 0011 ist nicht klar ob hier Rot und Grün oder nur Blau gemein ist. Deshalb müssen wir das enum noch ein wenig ändern:

[Flags]
private enum Colors
{
    None = 0,
    Red = 1,
    Green = 2,
    Blue = 4
}

Hier wurden jetzt neben dem Flags Attribut noch die Nummern von Hand vergeben. Damit kann man verhindern, das Bau anstelle der 3 die 4 bekommt. Binär sieht das dann so aus:

0000 – None
0001 – Red
0010 – Green
0100 – Blue

Wenn nun wieder die Schleife von weiter oben ausgeführt wird, sieht das Ergebnis ganz anders aus:

0 – None
1 – Red
2 – Green
3 – Red, Green
4 – Blue
5 – Red, Blue
6 – Green, Blue
7 – Red, Green, Blue

Das liegt daran, dass zum Beispiel die 7 binär eine 111 ist. Es ist also das bit für Rot, Grün und Blau gesetzt.

Nun könnte man sich eine Methode mit folgender Signatur bauen:

public void SetColors( Colors color )

Das schöne ist jetzt das man nicht nur eine sondern mehrere Farben vergeben kann. Zum Beispiel Rot und Grün:

SetColors( Colors.Red | Colors.Green  )

Rot und Grün wird mit einem binären ODER verknüpft das ergibt dann den Wert: 0011. Dieser wird an die Methode übergeben.

Innerhalb von SetColors kann man dann mit folgendem Code prüfen, welche Farben aktiv sind:

public static void SetColors(Colors colors)
{
    if (IsColorSet(colors, Colors.Red))
    {
        //Do something
    }

     // ...
}

private bool IsColorSet(Colors colors, Colors colorToCheckFor)
{
    return (colors & colorToCheckFor) == colorToCheckFor;
}

Der kombinierte Wert wird also mit einem logischen UND mit dem zu prüfenden Wert verknüpft. Dadurch werden alle Bits gekippt, die nicht im zu prüfendem Wert 1 sind.
Bei Rot und Grün haben wir zum Beispiel 0011. Nur Rot ist die 0001. Und aus 0011 & 0001 wird 0001. Also wieder Rot.

Enumerations sind zusammen mit dem Flag Attribut also sehr gut geeignet um Optionen weiterzugeben, bei den auch verschieden Kombinationen möglich sind.

SQL Server Compact Edition


Vor kurzem habe ich die Compact Edition des SQL Servers ausprobiert. Diese gibt es ja schon länger, aber ich dachte immer sie währe nur für mobile Geräte nützlich. Doch weit gefehlt. Wenn man dem Nutzer seiner Anwendung das installieren eines SQL Servers ersparen will, kann man einfach die dll’s der CE Version mit deployen. Mehr ist nämlich nicht nötig und so muss nicht immer eine SQL Server Instance im Hintergrund laufen.

Wenn man eine Anwendung mit der CE Edition entwickeln möchte, muss man sich diese zuerst installieren. Dabei wird, wie gesagt, aber keine Instance angelegt. Es werden lediglich dll’s auf die Platte kopiert. Die Datenbank erstellt man am besten mit dem SQL Server Management Studio. Dazu bei Server type einfach SQL Server Compact Edition angeben und bei Database file „new Database“ wählen. Danach noch den Anweisungen folgen. Das Ganze funktioniert leider nur mit der 2008er Version des Management Studios. Was man, soweit ich weiß, nicht einzeln herunterladen kann.

Wenn man seine Datenbank erstellt hat, bedient man sie am besten mit Linq to SQL. Seinen Mapper Code kann man sich von sqlmetal erstellen lassen, dass beim Visual Studio und im .NET SDK dabei ist:

sqlmetal e:\TimeProofer.sdf /namespa ce:MyNamespace /password:mypass /code:TimeProofer.cs

Das erstellte Codefile kann man dann in sein Projekt einfügen und zum Beispiel so verwenden:

TimeProofer tp = new TimeProofer("Data Source=E:\\TimeProofer.sdf;Password=mypass");
Project project = new Project();
project.Proj_name = "My new Project";
project.Proj_description = "With this description";

tp.Project.InsertOnSubmit(project);
tp.SubmitChanges();

foreach (var projects in from p in tp.Project select p)
{
    Console.WriteLine(project.Proj_name);
}

Zuerst wir eine neue Instance der TimeProofer Klasse angelegt. Als Parameter wird ein ConnectionString verwendet. Nun kann ein neues Projekt angelegt werden. Project ist übrigens eine Tabelle in meiner Datenbank.  Das neue Projekt wird dann der Projekttabelle hinzugefügt und submitted. Abfragen kann man seine Tabelle mit der Linq typischen Syntax.

Alles in allem kommt man so ziemlich schnell zu einer einfachen Datenbankschicht, die für kleine Anwendungen vollkommen ausreichen ist.

Hier noch ein Link zu SQL Server CE:

http://www.microsoft.com/sqlserver/2005/en/us/compact.aspx

Neue Sprachfeatures in C# 3.0


Mit dem .NET Framework 3.5 kommt auch eine neue Version von C#, welche viele Neuerungen für uns bereit hält. Zum einen kann der Quellcode wesentlich verkürzt werden ohne dabei unleserlich zu werden,und zum anderen werden völlig neue Möglichkeiten eröffnet. Dieser Artikel soll einen kurzen Überblick über diese Features geben. Ich hoffe sie sind ebenso begeistert wie ich.

Automatically Implemented Properties

Ich habe es schon immer etwas störend empfunden, wenn man zu vielen Variablen immer die Properties per Hand eingeben musste. Später war mir da der ReSharper eine große Hilfe. Doch jetzt wird die Sache, auch ohne, deutlich einfacher. So sah ein privates Feld mit zugehörigem Property bis jetzt aus:

private string _Message;

public string Message

{

get { return _Message; }

set { _Message = value; }

}

Zuerst muss man seine Variable anlegen und dann muss das Property dafür geschrieben werden. Dies kann jetzt wie folgt vereinfacht werden:

public string Message { get; set; }

Natürlich könnte man jetzt sagen, dass man dafür auch einfach ein öffentliches Feld nehmen könnte. Aber man kann den Zugriff natürlich einschränken:

public string Message { get; private set; }

So kann auf die Variable nur innerhalb der Klasse schreibend zugegriffen werden. Zu beachten ist hierbei, dass immer ein get und set angegeben werden muss.Eine Variable, die auch innerhalb der Klasse nur gelesen oder geschrieben werden kann macht ja auch nicht viel Sinn. Dafür gibt es ja zum Beispiel Konstanten.

Object und Collection initializers

Diverse Properties einer Klasse können nun direkt bei ihrer Initialisierung mit Werten gefüllt werden.

Das ganze sieht dann so aus:

Email mail = new Email(“hans@xyz.de”) { Message = “Hello World”, From = “john@doe.de” }

Bei einem parameterlosen Konstruktor, kann man sogar die runden Klammern weg lassen.

Email mail = new Email() { From = “john@doe.de”, recipient = “hans@xy.de” }

Zu beachten ist hierbei, dass nicht alle Felder gefüllt werden müssen. Diese erhalten dann ihren normalen Wert, der ihnen in der Klasse zugewiesen wird.

Jede Klasse die System.Collections.Generic.IEnumerable<T> implementiert kann von Collection initializers profitieren. Dabei können die Collections gleich bei ihrer Erzeugung mit Werten gefüllt werden.Dieses Feature kann man wie folgt verwenden:

List<Email> myEmail = new List<Email>

{

new Email(“1@zwei.de”),

new Email(“2@zwei.de”),

new Email(“3@zwei.de”),

new Email(“4@zwei.de”)

};

Bei der Ausführung wird dann zuerst die Liste initialisiert und dann werden per Add(…) die Elemente hinzugefügt. Dafür muss die Add Methode natürlich public sein.

Implicitly typed local Variables

In C# 3.0 kann der Datentyp einer Variablen vom Compiler implizit festgelegt werden. Dazu dient das Schlüsselwort var, welches bereits aus diversen Scriptsprachen bekannt sein dürfte. Doch anders als bei diesen, kann der Datentyp einer mit var deklarierten Variablen sich nicht während der Laufzeit des Programms ändern. Ihr wird der Typ bei ihrer initialisierung vom Compiler zugewiesen. Deshalb ist es auch notwendig die Variable bei ihrer Deklaration zu initialisieren. Dies sieht dann so aus:

var number = 27;// number ist vom Typ int

var message = „Hallo“// message ist vom Typ string

Wenn sie diese Zeilen im Visual Studio in einer Klasse schreiben, können sie mit der Maus über eine Variable gehen und werden im Quickinfo den entsprechenden Typ sehen. Wenn sie ein Array mit var deklarieren wollen, müssen sie zusätzlich new[] verwenden.

var numbers = new[] { 1, 2, 3};

Wozu soll das nun gut sein? Mit Hilfe von var lässt sich wesentlich generischer Code schreiben. Egal was die Methode GetSomeData() im folgenden Beispiel liefert, in der foreach Schleife kann immer ihr Inhalt ausgegeben werden.

var dataList = GetSomeData();

foreach( var data in dataList)

Console.WriteLine(data);

Außerdem kommt var bei LINQ exzessiv zur Verwendung. Doch dazu später mehr.

Extension Methods

Extension Methods sind meiner Meinung nach, eine der ganz besonders praktischen Neuerungen in C# 3.0. Mit ihnen lassen sich Klassen um Methoden erweitern, ohne dass man die Klasse selbst ändern muss. Man muss also nicht einmal Zugriff auf den Quellcode der Klasse habe oder diese neu übersetzen. Konkret bedeutet das, dass man auch Klassen irgendeines Frameworks erweitern kann. Die Extension Method muss dazu in einer statischen Klasse als statische Methode deklariert werden. Außerdem muss der erste Parameter vom Typ der zu erweiternden Klasse sein und dem Schlüsselwort this folgen.

public static class ExtensionMethods

{

publicstatic bool IsSpam( this Email mail, List<string> blackList)

{

return blacklist.Contains(mail.Sender);

}

}

An einer anderen Stelle, kann dann diese Methode auf den Typ Email aufgerufen werden.

public static void Main(string[] args)

{

List<string> blackList = GetBlackList();

Email mail = GetNewMail();

If (mail.IsSpam(blackList))

mail.Delete();

}

Wichtig ist noch, dass die Extension Method nur zur Verfügung steht, wenn ihr Namespace inkludiert wurde.

Lambda Expressions

In C# 2.0 wurden anonyme Methoden eingeführt, die es erlauben Delegates, gleich bei ihrer Initialisierung mit einem Funktionsrumpf zu versehen. Das war und ist sehr praktisch, wenn man, zum Beispiel, in einer Liste nach einem bestimmten Element sucht.Lambda Expressions bieten nun eine wesentlich einfachere Syntax. Stellen sie sich zum Beispiel vor, sie suchen alle Emails von Hans@Maulswurf.de aus einer Liste von Emails.

var mail = mailList.FindAll(m => m.Sender == „Hans@Maulswurf.de“)

Eine Lambda Expression besteht aus einer Parameterliste, dem Zeichen => und einem Ausdruck. Dabei können die Typen der Parameterliste explizit oder implizit angegeben werden. Zur Suche der Emails hätten wir also auch folgendes schreiben können.

var mail = mailList.FindAll( (Email m) => m.Sender == „Hans@Maulswurf.de“)

Lamda Expressions werden sehr häufig bei der Verwendung von LINQ eingesetzt. Dazu soll aber noch ein extra Artikel folgen.

Falscher Debugger


Mit unter soll es vorkommen, dass sich in einer Anwendung ein Fehler eingeschlichen hat. Zumindest in denen, die man nicht selbst Programmiert hat. Stößt das Framework auf einen solchen Fehler erscheint, sofern das SDK installiert ist und Debug Symbols vorhanden sind, ein Fenster, in welchem man einen Debugger starten kann. Bei mir war nun das Problem das ich bei einer .NET 2.0 Anwendung nur die Debugger für das 1.1er Framework wählen konnte, die dann mit dem Prozess natürlich ganz und gar nicht zurecht kamen. Die Lösung des Problems lag in der Registry. Dort fand ich unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework] folgende zwei Schlüssel:

"DbgManagedDebugger"="\"C:\Programme\Gemeinsame Dateien\Microsoft Shared\VS7Debug\vs7jit.exe\" PID %d APPDOM %d EXTEXT \"%s\" EVTHDL %d"

"DbgJITDebugLaunchSetting"=dword:00000002

Wie man sieht, ist dort der Debugger von VS 7, sprich .NET 1.1, angegeben. Also kann das ja nicht gehen. Ändert man die Wete der beiden Schlüssel auf:

"DbgManagedDebugger"="\"C:\WINDOWS\system32\vsjitdebugger.exe\" PID %d APPDOM %d EXTEXT \"%s\" EVTHDL %d""DbgJITDebugLaunchSetting"=dword:00000010

sieht das Ganze schon besser aus. Offenbar lag der Fehler daran, dass ich VS 2005 vor der 2003er Version installiert habe. Wie auch immer. Jetzt funktioniert es wieder super. Wichtig war mir das Ganze um einen selbst geschriebenen Windows Service zu Debuggen. Das geht ja von Haus aus ziemlich schlecht. Schreibt man aber System.Diagnostics.Debugger.Launch(); wird in dieser Zeile der Debugger gestartet. Das kann sehr hilfreich sein.