Rash thoughts about .NET, C#, F# and Dynamics NAV. » .NET

WPF Designer for F#

Steffen Forkmann — Thu, 22 Mar 2012 19:19:10 +0000

F# 3.0 brings the new type providers feature which enables a lot of different applications. Today I’m happy to announce that the FSharpx project brings you a WPF designer for F# in the Visual Studio 11 beta.

A big kudos to Johann Deneux for writing the underlying XAML type provider.

Create a new F# 3.0 Console application project
Set the output type to “Windows Application” in the project settings
Use nuget and install-package FSharpx.TypeProviders
Add references to WindowsBase.dll, PresentationFramework.dll, System.Xaml.dll and PresentationCore.dll
Add a Xaml file to your project. Something like this:
Now you can access the Xaml in a typed way:
Start the project

Enjoy!

BTW: No code generation needed is for this. No more nasty *.xaml.cs files.
BTW2: Try to change the name of Button1 in the Xaml and press save.

Why do we need partial application? – Part 2 of n – Simulating type classes in C# and F#

Steffen Forkmann — Tue, 31 Jan 2012 16:48:58 +0000

This is yet another blog post in my Currying and Partial application series. This is what I have posted so far:

In this post I want to show you a way to simulate type classes in C# and F#. Type classes are this wonderful feature in Haskell which allow you to specify constraints on your polymorphic types. We don’t have this in C# nor F#.

Let’s start with the following problem: We want to compute the sum of the squares of arbitrary numbers. We want to write something like this:

The problem is we don’t have a generic * function and of course we’d also need a generic + operator and maybe a generic zero. Obviously we need a constraint on the generic parameter T since + might not be defined for any type. So let’s define an interface for numbers:

Nothing special here, so let’s get straight to the implementation for integers and doubles:

So far so good. With this in our pocket we rewrite SumOfSquares() into this:

The trick is that we pass the concrete implementation as the first parameter into our function. This works exactly like a type constraint or as Simon Peyton-Jones would say: the vtable travels into the function. Notice that we don’t have access to the definition of in nor double. There is no way for us to express that int or double implement a number interface.

Now let’s try this out:

As you can see, this is perfectly type safe. We now have a way for poor man’s type classes in C#. Yay!

Now what has this to do with partial application? Let’s look at the same thing in F#:

We’re using a lot of partial application here. Exercise: Try to spot all the places.

Ok, you’re right. This post might be a little bit far away from the partial application stuff, but it’s still related. Somehow.

Currying and uncurrying in C# and F#

Steffen Forkmann — Mon, 30 Jan 2012 17:00:29 +0000

In the last couple of days I started to write some posts about Currying and Partial application:

This time I want to show you how we can write a higher-order function which allows us to curry another function. Remember the multiplication function from the first post and it’s curried form:

Currying

The question is: how can we automate this transformation process? Remember we want to have the curryied form for partial application:

Let’s look at the signature of the desired Curry-function: in our case it has to take Func and returns Func>.

If we generalize the ints to generic parameters and fix the signature then the implementation is trivial (Compiler Driven Programming). There is exactly one way to make this work:

The F# implementation does exactly the same, but without all the annoying the type hints:

Uncurrying

Of course you can undo the currying by applying a generic Uncurry-function:

And in F# this looks like this:

Libraries

Currying and Uncurrying are two very important concepts in functional programming so they are included in a couple of libraries:

You can find it at the top of the Prelude in FSharpx (read more).
You can find it in the Haskell Prelude.
You can find similar functions in Scalaz.
Adrian Lang wrote a library called partial-js which allows to do something similar in JavaScript.

Why do we need partial application? – Part 1 of n – Fluent interfaces and piping

Steffen Forkmann — Sun, 29 Jan 2012 10:34:35 +0000

My last blog post was yet another introduction to Currying and Partial application. Now I want to put the focus more on the why part. Why do we want to have our functions in curryied form most of the time? This is the first part of a small blog post series and shows partial application in F# pipelines.

Using “Fluent interfaces” is a popular technique to write code in a more readable form. In languages like C# they also provide a way to create the code much faster. On every . we get IntelliSense and this gives us a “fluid” way of writing.

Let’s consider the following task: we want to compute the sum of the square roots of all odd numbers between 1 and 100. In C# we can use the LINQ method chaining approach in order to do something like this:

Now how does this look in F#? It’s basically the same. We replace every . with the |> operator and use the analogous Seq.* functions:

Oups! What happened here? The F# compiler noticed a type error. Math.Sqrt needs a float as input but we gave it an int. C# uses implicit casts between int and float so we didn’t noticed the problem there. Implicit casts are a little bit problematic, at least if you want to have proper type inference so F# doesn’t have this feature. No problem, we are programmers so let’s add the conversion manually:

Notice that float is a function from int to float and not a cast.

Now you might ask: how does this all relate to partial application? The answer is simple: In every pipeline step we use a higher-order function (Seq.*) and apply the first parameter with a lambda. The second parameter is given via the |> operator from the line above.

By applying our rule of thumb from the last post were are able to remove the x parameters:

Now let’s step back to C#. Keeping this knowledge in mind we try to apply the same rule in order to get rid of the x parameters:

Oups again! Now we see same error in C#. In this case it doesn’t know how to apply the implicit cast. As I said they are “problematic”, but we know how to fix this:

CodingDojo in TDD – Die einfachste Lösung siegt

Steffen Forkmann — Sun, 20 Jun 2010 18:27:48 +0000

Auf dem .NET OpenSpace Süd in Karlsruhe hatte ich heute die Gelegenheit bei einem Coding Dojo mit Ilker Cetinkaya mitzumachen. Leider ist das Dojo nicht so richtig in Fahrt gekommen und wir haben es praktisch nicht geschafft auch nur eine einzige Regel der Kata.RomanNumerals zu implementieren. Der Grund dafür war (sicherlich nicht nur) aus meiner Sicht, dass es zwei starke Fraktionen innerhalb des Teams gab. Auf der einen Seite “Coder”, die sich tatsächlich von den Tests treiben lassen wollten und auf der anderen Seite eine Gruppe der “Knobler”, die sich nicht mit dem Test-first-Ansatz identifizieren können und lieber am Board einen Algorithmus entwickeln.

Aus meiner Sicht sind beide Ansätze für sich betrachtet auch völlig in Ordnung und können zu sehr guten Lösungen führen.

Wer z.B. nicht glaubt, dass der strikte Test-first-Ansatz für Kata.RomanNumerals funktioniert, der kann gern die Teilnehmer vom 2.ten Hamburger Coding Dojo fragen oder das github-Repository dazu durch browsen und die Entwicklung der Commits verfolgen.

Was aber offensichtlich überhaupt nicht funktioniert ist der Mittelweg. Wenn sich beide Gruppen nicht auf das Vorgehen einigen und im Zweifel immer nur der “lauteste” Änderungsvorschlag gewinnt, dann wird das Ergebnis mitunter unbefriedigend für beide Seiten. Beim Karlsruher-Dojo hatten wir am Ende nach einer gescheiterten Implementierungsphase und abrupten Abbruch sogar nur 7 rote und einen grünen Test vorzuweisen. Bei dem Grünen frage ich momentan sogar immer noch warum ausgerechnet dieser Test überhaupt gelaufen ist.

Um also eine solche Situation zu vermeiden sollte man sich also am Anfang entscheiden wie man sein Dojo gemeinsam durchziehen will. Im weiteren werde ich jetzt eher auf die von mir favorisierte Variante mit striktem TDD eingehen, auch wenn mich eine Knobler-Session mit ausgeprägter Analysephase auch mal als Vergleichswert interessieren würde.

Wie gesagt: Ich bin ausdrücklich davon überzeugt, dass beide Lösungswege funktionieren können – je nach Problem mal besser und mal schlechter.

Striktes TDD und der einfachste Lösungsvorschlag gewinnt

Ein oft genanntes Argument der “Knobler”-Fraktion am TDD-Ansatz ist, dass nicht vorrausschauend entwickelt wird. Hey Jungs – das ist doch genau der Trick. Solange ich keine Anforderung für irgendwelche Dinge habe (nicht im Kopf oder auf dem Papier, sondern als Test) wird keine Komplexität hinzugefügt. Es wird dann behauptet, dass bei Test-first am Anfang sinnfreie Implementierungen gewählt werden und dass man diesen Code am Ende ganz offensichtlich sowieso wieder wegschmeißen würde. Aber das stimmt einfach nicht. Auch wenn ich immer mehr Tests hinzunehme und meine Implementierung immer generischer wird, so wird die vorherige Lösung letztlich immer ein Spezialfall der generischen Variante sein und geht somit nie verloren.

Gerade der Fokus auf diese minimal mögliche Generalsierung der aktuellen Implementierung sorgt dafür, dass der Algorithmus am Ende korrekt herausfällt. Das Knobeln kommt an dieser Stelle natürlich wieder in den Ablauf herein. Allerdings knobeln wir so an wesentlich kleineren und damit leichteren Problemen – selbstverständlich nun viel öfter und in kürzeren Zyklen.

Bei zukünftigen Coding Dojos würde ich also gern als Regel sehen, dass der einfachste Vorschlag, der zu Grün führt implementiert wird.

Temposteigerung durch gruppenweises Anlegen von roten Tests

Zu bestimmten Zeitpunkten und insbesondere auch am Anfang von vielen Katas sieht man jedoch oft Implementierungsmuster die gleich eine ganze Klasse an Tests abdecken könnten. Wenn man so eine Idee hat, dann sollte man die natürlich auch nutzen und so das Tempo steigern. Anstatt aber diese Idee einfach zu programmieren würde ich erst die komplette Gruppe von Tests schreiben und sicherstellen, dass alle neuen Tests auch wirklich "rot sind. Dieser Shortcut ist aus meiner Sicht methodisch völlig unproblematisch, da zu diesem Zeitpunkt nur neue Anforderungen im System dokumentiert werden und diese dann als Begründung für neue Komplexität herangezogen werden können.

Aber auch hier sollte die selbe Regel gelten: Die leichteste Implementierung gewinnt. Wenn also ein Teilnehmer eine einfachere Lösung anbieten kann, dann wird die genommen.

Training durch Wiederholung

Wie Ilker in der Auswertung bereits gesagt hat, würde ich auch gern nochmal in der selben Truppe ein Dojo machen. Vielleicht ergibt sich das ja sogar beim nächsten OpenSpace. Denn selbstverständlich geht es beim Coding Dojo nicht nur um Code sondern auch um die beteiligten Menschen.
Obwohl wir am Ende keine Lösung vorweisen konnten, habe ich in der kurzen Zeit sehr viel über die Entwicklungsmethodik anderer Teilnehmer gelernt – ich denke das hat mir wirklich eine Menge gebracht.

Training durch Wiederholung – Reloaded

Da ein wichtiges Element bei Katas auch die Wiederholung ist (und mir im Zug langweilig ist), habe ich zusätzlich für mich selbst und andere noch eine aufgeräumtere Variante der Kata mit minimalen Commits in das Repository hochgeladen. Unter http://github.com/forki/DojoHamburg/commits/Karlsruhe kann man die Änderungen von unten nach oben genau nachvollziehen. Wenn jemand ein Stelle findet wo ich zu viel implementiert habe oder wo die Änderung nicht sinnvoll und einfach erscheint, dann würde ich mich freuen darüber diskutieren zu können.

Bericht vom 2.ten .NET Coding Dojo in Hamburg

Steffen Forkmann — Fri, 18 Jun 2010 18:52:37 +0000

Am Mittwoch hat die .NET User Group Hamburg das zweite .NET Coding Dojo in wunderbarer Lage im Neuen Wall durchgeführt. Der Dank gilt diesmal Computer Futures, die uns freundlicherweise Raum, Beamer und Getränke zur Verfügung gestellt haben.

Ablauf

Nach einer kurzen Reflektion des letzten Treffens und Klärung der aufgetretenen Syntaxprobleme hat sich das Team dafür entschieden, die Kata.RomanNumerals zu implementieren. Wie beim ersten Treffen haben wir diese relativ einfache Kata auch wieder im Randori-Stil durchgeführt. Da das Team relativ gleich geblieben ist, konnten wir den Ablauf jedoch leicht erweitern. Um etwas mehr Schwung in die Test-Phase zu bringen, habe ich vorgeschlagen immer in der Rot-Phase zu rotieren. Zusätzlich haben wir git als Versionskontrollsystem im Einsatz gehabt und bei jeder Grün-Phase sowie nach Refactorings commited. Das Ergebnis kann auf meinem Github-Account bewundert werden.

Kata

Aus meiner Sicht bildet die Kata.RomanNumerals eine ideale Fortsetzung zur Kata.StringReplacer, die wir beim ersten Treffen hatten und ist praktisch perfekt mit Test-Driven Development lösbar. Insbesondere das nachträgliche Implementieren der scheinbar komplizierten Subtraktionsregel ist wunderbar anhand von wenigen Sonderfällen (= UnitTests) lösbar.

Was lief gut?

Die Rotation der Teilnehmer klappte wieder problemlos – Danke Jungs
TDD wurde als sehr erfolgreich für die Kata angesehen
Nahezu alle Teilnehmer waren überrascht wie einfach sich die Subtraktionsregel in TDD implementieren lässt
Die Randori-Form mit Rotation bei Rot sorgt für Aktivität
Es wurde immer versuchen die einfachste Lösung zu wählen
Die Rollen Driver, Co-Pilot und Publikum wurden klarer getrennt
Es wurde nach jedem implementierten Test in das git Repository commited
Ganz wichtig: Es hat wieder viel Spaß gemacht!

Was wollen wir besser machen?

Noch mehr Wert auf das Naming legen

Überraschenderweise hat sich kein Team getraut die Namenskonvention des ersten Teams zu verbessern
Insbesondere auch die Commit-Kommentare sind noch nicht sehr aussagekräftig

In den Refactoring-Phasen sollten die Tools (Resharper) besser genutzt werden
Die Refactorings könnten noch ausführlicher diskutiert werden
Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
Internetverbindung um Syntaxfrage schneller klären zu können
Parametrisierte Tests benutzen um weniger Test-Codierungsaufwand zu haben

Vielen Dank an alle Teilnehmer – wir sehen uns dann beim nächsten Dojo.

Bericht vom Ersten .NET Coding Dojo in Hamburg

Steffen Forkmann — Thu, 20 May 2010 06:37:06 +0000

Gestern fand das erste .NET Coding Dojo in Hamburg statt und es war aus meiner Sicht ein voller Erfolg. Als erstes möchte ich mich an dieser Stelle bei der Firma masters of arts für die Räumlichkeit und natürlich bei allen Teilnehmer für die aktive Mitarbeit bedanken.

Durchgeführt haben wir das Dojo im Randori-Stil, d.h. es gab einen Entwickler, einen “Co-Piloten” und das Publikum. Nach jeweils 5 Minuten bzw. jedem neuen Testfall wurden die Positionen mit neuen Teilnehmer aus dem Publikum getauscht.

Nach einer kurzen allgemeinen Einführung in das Thema “Coding Dojo” habe ich die Aufgabenstellungen der Kata.FizzBuzz und Kata.DictionaryReplacer vorgestellt. Durch kurze Abstimmung haben wir dann (vermutlich durch meine Wortwahl beeinflusst) die Kata.DictionaryReplacer gewählt.

Mit der Wahl dieser Kata war ich nicht ganz unglücklich, da wir DictionaryReplacer schon im Online Dojo durchgenommen haben und ich deshalb die Fallstricke schon etwas einschätzen konnte.

Kata.DictionaryReplacer

Create a method that takes a string and a dictionary,
and replaces every key in the dictionary pre and suffixed with a dollar sign,
with the corresponding value from the Dictionary.

Tests

input : "",
          dict empty
output: ""

input : "$temp$",
           dict ["temp", "temporary"]
output: "temporary"

input : "$temp$ here comes the name $name$",
           dict ["temp", "temporary"] ["name", "John Doe"]
output : "temporary here comes the name John Doe"

[codingdojo.org]

Nach kurzer Einführung in die Vorgehensweise des Test-Driven Developments (TDD) und Diskussion über sinnvolles Naming ging es dann auch richtig in die Entwicklung. Die Kata eignet sich in dieser Form auch sehr schön um tatsächlich “Test first” zu arbeiten. Die Implementierung folgt quasi als logische Konsequenz.

Interessant und ungleich komplizierter wurde es dann als wir eine zusätzliche Anforderung eingebaut haben. Da es sich bei der Kata um eine Art Templatesystem handelt liegt es nahe auch in den Values des Wörterbuchs neue Keys zu erlauben und somit eine beliebige Ersetzungstiefe zu erreichen. Diese Anforderung ist ein wunderbares Beispiel dafür wie sehr man mit Aufwandsabschätzungen daneben liegen kann.

Die rekursive Ersetzung wurde noch sehr schnell gelöst, aber richtig schwer haben wir uns dann mit der Erkennung von zyklischen Ersetzungen und der daraus folgenden Endlosschleife getan. Nach und nach wurden immer kompliziertere Lösungsmöglichkeiten genannt, die aber in der gegebenen Zeit nicht fehlerfrei umgesetzt werden konnten. Als Folge haben wir immer noch einen Test “rot”. Wer Lust hat kann sich also die Quellen vom github Repository ziehen und als Hausaufgabe den verbleibenden Test “grün” machen.

In der Nachbetrachtung haben wir noch einige Sachen festgestellt:

Was lief gut?

Die Rotation der Teilnehmer klappte problemlos
Lösungsideen sprudelten förmlich aus dem Publikum
Interessante Edge-Cases wurden gefunden
Viele kleine Tipps (z.B. Resharper Shortcuts) wurden ausgetauscht
TDD wurde als erfolgreich für die Kata angesehen
Die Randori-Form sorgt für Aktivität
Ganz wichtig: Es hat Spaß gemacht!

Was wollen wir besser machen?

Schneller den ersten Test schreiben
Intensivere Diskussion des Interfaces
Noch mehr Wert auf das Naming legen
Versuchen die einfachste Lösung zu wählen
Mehr Wert auf Refactoring legen
- wurde etwas vernachlässigt, da wir viel Zeit an der Endlosschleife verbraucht haben
Die Rollen Driver, Co-Pilot und Publikum klarer trennen
Nach jedem implementierten Testcase bzw. jeder Rotation der Teilnehmer in das git Repository einchecken
Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
Internetverbindung um Syntaxfrage schneller klären zu können

Als möglichen Termin für das Dojo haben wir jetzt grob jeweils den 3. Mittwoch im Monat vorgeschlagen. Über die Xing-Gruppe der .NET User Group Hamburg werden wir natürlich auch wieder entsprechende Einladungen verschicken.

“FAKE – F# Make” and NaturalSpec released

Steffen Forkmann — Tue, 13 Apr 2010 08:06:46 +0000

Yesterday Microsoft released the RTM versions of Visual Studio 2010, .NET Framework 4.0 and F# 2.0.0.0 and so it is time to announce the first official releases of “Fake – F# Make” and NaturalSpec. Both projects are now compatible with Visual Studio 2010 RC and RTM and the corresponding F# versions.

Fake – F# Make version 1.0.0

"FAKE – F# Make" is a build automation system, which is intended to provide a much better tooling support than XML-based build languages like MSBuild or NAnt. Due to its integration in F#, all benefits of the .NET Framework and functional programming can be used, including the extensive class library, powerful debuggers and integrated development environments like Visual Studio 2008, Visual Studio 2010 or SharpDevelop, which provide syntax highlighting and code completion.

Like F# itself the new build language was designed to be succinct, typed, declarative, extensible and easy to use.

Project page with samples and articles
Download page
Github repository

NaturalSpec version 1.0.0

NaturalSpec is a UnitTest framework based on NUnit and completely written in F# – but you don’t have to learn F# to use it. The idea is that you can write your spec mostly in a natural language like in the following sample:

[]
let “When removing an element from a list it should not contain the element“() =
  Given [1;2;3;4;5]                 // "Arrange" test context
    |> When removing 3              // "Act"
    |> It shouldn’t contain 3       // "Assert"
    |> It should contain 4          // another assertion
    |> It should have (Length 4)    // Assertion for length
    |> It shouldn’t have Duplicates // it contains duplicates ?
    |> Verify                       // Verify scenario

Project page with samples and articles
Download page
Github repository

If you have any questions about the projects feel free to contact me.

"Getting started" with NaturalSpec – (Updated 08.11.2009)

Steffen Forkmann — Sun, 08 Nov 2009 09:48:00 +0000

In my last article (Introducing NaturalSpec – A Domain-specific language (DSL) for testing) I used NaturalSpec in two small samples. This time I will show how we can set up a NaturalSpec environment to write our first automatically testable scenarios.

1. Choosing an IDE

The first step is to choose an integrated development environment for NaturalSpec. At the current project status you should be able to use NaturalSpec with Visual Studio 2008, Visual Studio 2010 beta 2, the freely available Visual Studio 2008 Shell or the free IDE SharpDevelop 3.0.

2. Installing the testing framework

As NaturalSpec uses NUnit as the underlying testing framework we have to install NUnit 2.5. I also recommend installing TestDriven.Net in order to get a Unit Test runner within Visual Studio.

3. Installing F#

NaturalSpec is completely written in F# and all specs will also be written in F#. This doesn’t imply you have to learn programming in F# but we need the F# compiler to get things working. You can download the F# October 2009 CTP from the Microsoft F# Developer Center.

4. Downloading the latest version of NaturalSpec

You can download a .zip with the latest NaturalSpec libraries from GoogleCode.

5. Creating a spec

This part is written for using Visual Studio 2008. If you use SharpDevelop or Visual Studio 2008 Shell this might differ in some detail.

Start Visual Studio 2008 and create a new F# class library.

Rename Module1.fs in ListSpec.fs and delete script.fsx from the project:

Create a folder “Lib” and unzip the NaturalSpec libraries into it.

Add NaturalSpec.dll and nunit.framework.dll as references to your project:

Copy the following code into ListSpec.fs:

module ListSpec

open NaturalSpec

[]
let When_removing_an_3_from_a_small_list_it_should_not_contain_3() =
  Given [1;2;3;4;5]
    |> When removing 3
    |> It shouldn't contain 3
    |> Verify

If you have TestDriven.Net installed you can run your spec via right click in the solution explorer:

If you don’t like the TestDriven.Net test runner you might want to use the NUnit GUI runner. The output should look like:

In addition the test runner should produce a Spec output file with the name “Spec.txt” within the same folder.

Summary

In a minimal environment you need SharpDevelop, the F# compiler, NUnit and the NaturalSpec libraries for using NaturalSpec.

In the next post I will show how you can use NaturalSpec to create a spec for C# projects.

Observing global hotkeys in C# / F#

Steffen Forkmann — Fri, 06 Nov 2009 10:08:05 +0000

I recently had the problem to register a global hotkey, but my “old” Win32-API calls didn’t work with WPF. I looked around the web and found the “Managed Windows API”, but I didn’t want to add another external dependency to my project, so I extracted the core functions for registering hotkeys and condensed the code to a new version.

As the original “Managed Windows API” is licensed by the GNU Lesser General Public License (LGPL) I want to provide my modifications here.

First we need a Window which can dispatch the window messages to our event handlers:

/// 
/// A Win32 native window that delegates window messages to 
/// handlers. So several
/// components can use the same native window to save 
/// "USER resources". This class
/// is useful when writing your own components.
/// 
public sealed class EventDispatchingNativeWindow : NativeWindow
{
    private static readonly Object MyLock = new Object();
    private static EventDispatchingNativeWindow _instance;
 
    /// 
    /// Create your own event dispatching window.
    /// 
    public EventDispatchingNativeWindow()
    {
        CreateHandle(new CreateParams());
    }
 
    /// 
    /// A global instance which can be used by components 
    /// that do not need their own window.
    /// 
    public static EventDispatchingNativeWindow Instance
    {
        get
        {
            lock (MyLock)
            {
                return 
                  _instance ?? 
                     (_instance = 
                       new EventDispatchingNativeWindow());
            }
        }
    }
 
    /// 
    /// Attach your event handlers here.
    /// 
    public event WndProcEventHandler EventHandler;
 
    /// 
    /// Parse messages passed to this window and send 
    /// them to the event handlers.
    /// 
    /// A System.Windows.Forms.Message 
    /// that is associated with the 
    /// current Windows message.
    protected override void WndProc(ref Message m)
    {
        bool handled = false;
        if (EventHandler != null)
            EventHandler(ref m, ref handled);
        if (!handled)
            base.WndProc(ref m);
    }
}

Now we can write our global hotkey handler class:

/// 
/// Specifies a class that creates a global keyboard hotkey.
/// 
public class GlobalHotkey
{
    private static readonly Object MyStaticLock = new Object();
    private static int _hotkeyCounter = 0xA000;
 
    private readonly int _hotkeyIndex;
    private readonly IntPtr _hWnd;
 
    /// 
    /// Initializes a new instance of this class.
    /// 
    /// The keys.
    /// if true [CTRL].
    /// if true [alt].
    /// if true [shift].
    /// if true [win key].
    public GlobalHotkey(Keys keys, bool ctrl, 
               bool alt, bool shift, bool winKey)
    {
        KeyCode = keys;
        Ctrl = ctrl;
        Alt = alt;
        Shift = shift;
        WindowsKey = winKey;
        EventDispatchingNativeWindow.Instance.EventHandler 
                += NwEventHandler;
        lock (MyStaticLock)
        {
            _hotkeyIndex = ++_hotkeyCounter;
        }
        _hWnd = EventDispatchingNativeWindow.Instance.Handle;
        Enable();
    }
 
    /// 
    /// The key code of the hotkey.
    /// 
    public Keys KeyCode { get; private set; }
 
    /// 
    /// Whether the shortcut includes the Control modifier.
    /// 
    public bool Ctrl { get; private set; }
 
    /// 
    /// Whether this shortcut includes the Alt modifier.
    /// 
    public bool Alt { get; private set; }
 
    /// 
    /// Whether this shortcut includes the shift modifier.
    /// 
    public bool Shift { get; private set; }
 
    /// 
    /// Whether this shortcut includes the Windows key modifier.

      /// 
    public bool WindowsKey { get; private set; }
 
    ~GlobalHotkey()
    {
        Disable();
        EventDispatchingNativeWindow.Instance.EventHandler 
            -= NwEventHandler;
    }
 
    /// 
    /// Enables the hotkey. When the hotkey is enabled, 
    /// pressing it causes a
    /// HotkeyPressed event instead of being 
    /// handled by the active application.
    /// 
    private void Enable()
    {
        // register hotkey
        int fsModifiers = 0;
        if (Shift) fsModifiers += ModShift;
        if (Ctrl) fsModifiers += ModControl;
        if (Alt) fsModifiers += ModAlt;
        if (WindowsKey) fsModifiers += ModWin;
        bool success = 
           RegisterHotKey(_hWnd, _hotkeyIndex, 
                fsModifiers, (int) KeyCode);
 
        if (!success)
            throw new 
              Exception(
                "Could not register hotkey (already in use).");
    }
 
    /// 
    /// Disables this instance.
    /// 
    private void Disable()
    {
        // unregister hotkey
        UnregisterHotKey(_hWnd, _hotkeyIndex);
    }
 
    /// 
    /// Occurs when the hotkey is pressed.
    /// 
    public event EventHandler HotkeyPressed;
 
    private void NwEventHandler(ref Message m, ref bool handled)
    {
        if (handled) return;
        if (m.Msg != WmHotkey || 
                m.WParam.ToInt32() != _hotkeyIndex)
            return;
        if (HotkeyPressed != null)
            HotkeyPressed(this, EventArgs.Empty);
        handled = true;
    }
 
    #region PInvoke Declarations
 
    private const int ModAlt = 0×0001;
    private const int ModControl = 0×0002;
    private const int ModShift = 0×0004;
    private const int ModWin = 0×0008;
    private const int WmHotkey = 0×0312;
 
    [DllImport("user32.dll", SetLastError = true)]
    private static extern bool RegisterHotKey(IntPtr hWnd, 
          int id, int fsModifiers, int vlc);
 
    [DllImport("user32.dll", SetLastError = true)]
    private static extern bool UnregisterHotKey(IntPtr hWnd, 
          int id);
 
    #endregion
}

Now we can easily register a global hotkey or use it as an observable in F#:

/// system-wide keyboard hook
let hotkey = new GlobalHotkey(Keys.Q,true,false,false,false)
let hookObserver =
  hotkey.HotkeyPressed  
    |> Observable.subscribe (fun _ -> printfn "Hotkey pressed")