Bei der Anbindung von externen http-basierten System ist es praktisch, wenn man für eigene Tests die Abhängigkeit des Fremdsystem durch einen Fake-Service ersetzen kann, der dann abhängig von Parametern die erwartet Antwort liefert. "Praktisch" ist ein  solcher Fake-Service aus folgenden Gründen:

• Das Ausführen von Tests ist somit unabhängig von externen Systemen ist. Der Test kann dann jederzeit den eigenen SourceCode, gegen das erwartet Verhalten des externen System prüfen
• Ein solcher Fake-Service ist deutlich schneller - Response Antwortzeit- und somit wird die Ausführungszeiten von Tests erhört
• Teilweise kommt es vor, dass externe Systeme gar keine Testumgebung zur Verfügung stellen oder das solche System immer wieder neu aufgesetzt werden, womit benötigte Konfigurationen verloren gehen.

Das birgt natürlich das Risko, dass Änderungen an externen Systemen nicht auffallen. Für diesen Fall sollte man wenige Tests haben, die das prüfen. Diese Integrations-Tests müssen aber nicht zwigend immer ausgeführt werden und behindern im Zweifel nicht das Erstellen von neuen Versionen.

Einen solchen Fake-Service - oder auch Stub genannt - kann man in .NET (und .NET CORE) mit Stubbery umsetzen.

Stubbery ist eine Library, mit der man sehr einfach einen Web-Server konfigurieren und starten kann, der dann auf bestimmte Routen mit konfigurierte Ergebnissen antwortet.

Wie auf der Webseite von Stubbery zu sehen, ist die Verwendung sehr einfach:

using (var stub = new ApiStub())
{
    stub.Get(
        "/get",
        (req, args) => "response");

    stub.Start();

    var result = await httpClient.GetAsync(new UriBuilder(new Uri(stub.Address)) { Path = "/get" }.Uri);

    // resultString will contain "response"
    var resultString = await result.Content.ReadAsStringAsync();
}

Für die Erstellung eines Stubs muss man eine neue Instanz der Klasse ApiStub erstellen, die Routen (Endpunkte) werden mit den Http-Verben Get, Post, Put und Delete definiert und anschließen wird durch den Aufruf der Methode Start() der Server gestartet. Der erzeugte Server ist über localhost und einem Zufallsport ansprechbar - die aktuelle Uri erhält man durch die Eigenschaft Address der erzeugten Instanz von ApiStub.

Die Instanz sollte entweder in einem using Block verwendet werden. Alternativ kann man auch durch den Aufruf von Dispose() den benutzten Port wieder freigeben.

In dem Github-Repro gibt es noch ein ausführlicheres Beispiel.

Manchmal ist es notwendig, dass man Dateien in das Output-Verzeichnis kopieren muss. Das können z.B. eigene Konfigurationsdateien sein.

Dieses Verhalten war bisher über die Projektdatei - bzw. durch einen Properties-Dialog in Visual Studio einfach zu konfigurieren:

Da der Buildprozess von .NET Core maßgeblich durch die project.json definiert wird, ist dieses Verhalten dort konfigurierbar.

"buildOptions": {
    "copyToOutput": [ "custom_config.json", “readme.md” ]
},

Die Dokumentation für den .NET Core buildOptions-Part der project.json Datei findet man online hier.

Abhängig von der MS SQL Server Version ist es keine einfache Aufgabe, eine existierende Tabelle als einzelne SQL INSERT Statements zu exportieren.

Für diese Aufgabe habe ich eine Stored Procedure gefunden, die es einem erlaubt sehr einfach eine Tabelle zu exportieren. Dafür muss man lediglich die Stored Procedure ausführen und als Parameter den Tabellennamen übergeben:

sp_generate_inserts 'Tablename'

 Die Stored Procedure findet man hier. Für den Fall das der Link nicht mehr erreichbar ist kann die Datei auch direkt von dieser Seite geladen werden sp_generate_inserts.sql (19,04 kb)

Neben dem Parameter Tabellenname gibt es eine Reihe weiterer Parameter, die im Script dokumentiert sind.
Mann kann z.B.

• Den Tabellenname angeben, indem die Datensätze eingefügt werden sollen
• Die zu exportierenden Felder
• Einschränkungen bzw. Filter (WHERE)

.

Die Beliebtheit und das Ökosystem des Microsoft open source Editor VS Code wächst täglich. Wer mit dem Microsoft SQL Server arbeitet kann dafür entweder das SQL Server Management Studio, Visual Studio oder mit "Fremd"-Software nutzen.

Für VS Code gibt es dafür mittlerweile auch ein Extension "mssql", die eine sehr komfortable Arbeitsweise - direkt in VS Code - erlaubt. Die Extension unterstützt:

• Microsoft SQL Server
• Azure SQL Database
• SQL Data Warehouse

Nach der Installation der Extension kann man mit den folgenden Schritten eine SQL Query ausführen:

1. Ein neues Dokument erstellen und als Sprache SQL auswählen F1 Change Language Mode => SQL
   
   
2. Anschließend kann man mit F1 MS SQL: Connect eine Connection zu einem MS SQL Server auswählen oder definieren.  
   
   
   
3. Nachdem die Connection aufgebaut wurde, bietet einem das Plugin auch Unterstützung (IntelliSense) während des Schreibens einer SQL Query an. Man erhält nicht nur eine Liste der SQL Keyword, auch Inhalte - z.B. Tabellen, Views - werden einem vorgeschlagen.
   
   
4. Um eine SQL Query auszuführen kann man entweder F1 MS SQL: Execute Query oder den Shortcut STR+UMSCHALT+E nutzen.
   Das Ergebnis wird dann wie folgt ausgegeben und kann direkt als JSON oder CSV exportiert werden.
   

Im Footer vom VS Code sieht man auch zu jederzeit welche Connection grade aktiv ist. Hier kann man auch die Connections schnell wechseln - Alternative dazu F1 MS SQL: Connection.

Erstellt man mit z.B. dotnet new ein neues Projekt und führt den Befehl dotnet build aus, kommt als Ergebnis eine Assembly mit dem Namen "src.dll" heraus. Genauer wird der Name der Assembly zunächst aus der Verzeichnisstruktur ermittelt. 

Den Namen der Assembly kann man sehr einfach in der project.json definieren. Dafür muss man lediglich im Bereich buildOptions eine neues Key-Value-Pair mit dem Key outputName und Value als gewünschter Assembly-Namen hinzufügen. 

Hier ein Beispiel:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "outputName": "dng.Sample"
  },
  "dependencies": {},
  "frameworks": {
    "netstandard1.6": {
      "dependencies": {
        "NETStandard.Library": "1.6.1-preview1-24530-04"
      }
    }
  }
}

Im Beitrag Neues DotNet Core Projekt auf der Komandozeile erzeugen habe ich gezeigt, wie man mit Hilfe der DotNet CLI ein neues Projekt erzeugen kann.      

Neben dem Tooling das einem Visual Studio bietet, gibt es als eine weitere plattformübergreifende Lösung den yeoman.io zu nutzen. Yeoman ist ein sehr beliebter und weit verbreiteter Generator - nicht nur für DotNet Core Projekte und beschreibt sich selbst wie folgt. "THE WEB'S SCAFFOLDING TOOL FOR MODERN WEBAPPS".

Installation

Für die Installation von YEOMAN wird folgende vorausgesetzt:

• GIT
• Node.JS v4 oder höher (und damit NPM)
  • Für  Mac OS mit dem Installer oder Homebrew
  • Für Windows mit dem Installer oder Chocolatey

Um zu überprüfen ob Node.JS in der min. notwendigen Version zur Verfügung steht, kann man in einer Kommandozeile folgenden Befehl eingeben:

node --version

Wenn die Voraussetzungen erfüllt sind, kann man einfach mit folgendem Befehl YEOMAN installieren

npm install --global yo

Ob die Installation erfolgreich war kann man folgenden Befehl nutzen:

yo --version

Nun benötigt man nur noch den "Generator" (das sind Templates in der YEOMAN Sprache) "Yeoman generator for ASP.NET Core apps". Auch diese lassen sich einfach per Kommandozeilen installieren:

npm install -g generator-aspnet

Erstellen eines .NET CORE Projektes

Für die eigentliche Erstellung eines neuen Projektes muss man nun nichts weiter machen als 

yo aspnet

in der Kommandozeile eingeben. Die Ausgabe sieht dann wie folgt aus:

Wie im Screenshot zu sehen, kann man kann zwischen den folgenden Templates wählen:

• Empty Web Application
• Empty Web Application(F#)
• Console Application
• Console Application (F#)
• Web Application
• Web Application Basic [without Membership and Authorization]
• Web Application Basic [without Membership and Authorization] (F#)
• Class Library
• Class Library (F#)
• Unit Test project (xUnit.net)

Anschließend kann man den Namen für das Projekt definieren und bekommt ein fertiges Grundgerüst erzeugt

Das man auch für eine ConsoleApp yo aspnet eingeben muss, sieht und fühlt sich vielleicht seltsam an, der Grund dafür ist recht simple. .NET Core hatte von Anfang an einen sehr starken web-lastigen Focus. 

Diese Auswahlmöglichkeiten können auch übersprungen werden, indem man die Aufruf mit Parameter erweitert

yo aspnet [projecttype [applicationname] [uiframework]]

Eine genaue Beschreibung findet man in der Dokumentation.

Gut Gründe für Yeoman

Warum sollte man Yeoman den überhaupt nutzen? Es gibt einige Einsatzgebiete für Yeoman:

Wenn man nicht das Tooling von Visual Studio zur Verfügung hat - z.B. weil man unter Mac OS entwickelt

Die Anpassung bzw. die Erstellung von eigenen Generatoren / Templates ist sehr simple, was einem in der täglichen Arbeit unterstützen kann.

Mit Yeoman werden viele Sub-Generatoren mit ausgeliefert um z.B. ein Dockerfile zu erzeugen

yo aspnet:dockerfile

Eine vollständige Auflistung findet man hier.

Microsoft hat für VS Code eine Sammlung von wirklich hilfreichen Tipps & Tricks zusammengestellt. Die beiden Autoren "Kay Giza und Tobias Kahlert gehören seit der ersten Stunde zu den täglichen Anwendern von Visual Studio Code." 

Ich empfehle jedem der VS Code einsetzt mal in dieses kostenlose eBook reinzuschauen. Das eBook ist hier erhältlich: Download eBook: Visual Studio Code - Tipps & Tricks Vol. 1    

.NET Core ist die neue Plattform für die schnelle und modulare Entwicklung von Server-Anwendungen, die auf Windows, Linux und Mac. Diese Betriebsysteme können nicht nur für die Entwicklung sondern auch der Betrieb / Hosting der Anwendung genutzt werden. Als Entwicklungsumgebung steht für .NET Core nicht nur das mächtigen Visual Studio (Express, Professional, ..)  sondern auch das Visual Studio Code zur Verfügung. Die Besonderheit an Visual Studio Code ist, dass diese Cross-Plattform lauffähig ist und somit auch auf Windows, Linux oder dem Mac zur Verfügung steht. Durch Erweiterungen erreicht man eine super Unterstützung für C# im Bezug auf IntelliSense oder auch Debugging. 

Benötigte Software

Um eine Anwendung - die man wie z.B. hier "Neues DotNet Core Projekt auf der Komandozeile erzeugen" beschrieben - zu bearbeiten, müssen folgende Komponenten installiert werden:

• .NET Core
• Visual Studio Code
• C# Extension vom VS Code Marketplace
• Node.JS (und damit NPM)
  • Für  Mac OS mit dem Installer oder Homebrew
  • Für Windows mit dem Installer oder Chocolatey

Start developing in VS Code

Öffnet man ein Projekt, dass auf der Kommandozeile erstellt wurde, zeigt VS Code folgende Meldung an:

Die untere Meldung "There are unresolved dependencies from 'project.json'. Please execute restore command' weißt einen darauf hin, dass in dem Verzeichnis noch kein dotnet restore aufgerufen wurde. Durch den blauen Button "Restore" erledigt VS Code diese Aufgabe - eine Alternative ist, dieses auf der Kommandozeile mit dem Befehl dotnet restore durchzuführen. 

Im Output Fenster sieht man dann folgende Ausgabe:

log  : Restoring packages for c:\dng\dng.sample\project.json...
log  : Writing lock file to disk. Path: c:\dng\dng.sample\project.lock.json
log  : c:\dng\dng.sample\project.json
log  : Restore completed in 2161ms.

Die Meldung "Required assets to build and debug are missing from your project." besagt das VS Code spezifische Konfigurationsdateien nicht vorhanden sind, um den Build- und Debug-Prozess auszuführen. Die dafür notwendigen Konfigurationsdateien Launch.json und Tasks.json werden im Ordner .vscode erzeugt. 

Die erzeugte launch.json Datei sieht wie folgt aus:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceRoot}\\bin\\Debug\\netcoreapp1.1\\dng.sample.dll",
            "args": [],
            "cwd": "${workspaceRoot}",
            "externalConsole": false,
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart"
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command.pickProcess}"
        }
    ]
}

Auf die Detail werden ich bestimmt später detailierte eingehen. Diese Variante reicht zumindest, um mit F5 das erzeugte Projekt zu debuggen. Der Debugger in VS Code sieht dann wie folgt aus:

Microsoft bietet mit DotNet Core die Möglichkeit wieder vieles auf der Command Line zu erledigen. Das konnte man natürlich auch bisher im "Full .NET Framework" - allerdings ist die Command Line mit DotNet Core diesmal von Anfang an im Fokus und wird nicht mehr so extrem hinter dem mächtigen Visual Studio versteckt.

Der aktuelle Trend ist, dass viele anstelle einer mächtigen IDE lieber ein CLI (Comand Line Interface) Tool nutzen. Diese Entwicklung halte ich auch für richtig, da man dadurch später die Automatisierung vom Prozessen deutlich schneller umsetzen kann. Nun beschäft man sich von Tag 0 mit der Command Line und erlernt direkt die Basics erlernen.

Da DotNet CLI auf den Plattformen Windows, Mac OS X und Linux verfügbar ist, muss man sich als Entwickler auch nicht umstellen, sollte man zwischen den Systemen wechseln. Dieses wird auch deutlich, wenn später Docker als Hosting Umgebung für DotNet Core genutzt wird, da man DotNet CLI nicht nur für die Entwicklung sondern auch für die Laufzeit nutzt. 

Öffnet man einen Command Prompt / Powershell / Terminal und tippt dort

dotnet --help

dann sieht man folgende Ausgabe:

Wenn man einfach nur

dotnet new

als Befehl eingibt, wird eine Konsolen Anwendung erzeugt. Mit dem Parameter -t kann man unter verschiedenen Projektvorlagen wählen. Aktuell stehen folgende zur Verfügung:

• Console
• Web (ASP.NET Core)
• Lib (Class library)
• xunittest (Unit test based on XUnit)

Möchte man also z.B. ein neues Web-Projekt erzeugen kann man das mit folgendem Befehl einfach durchführen:

dotnet new -t web

Neben dem verschiedenen Projektvorlagen, kann man mit dem Parameter -l auch die gewünschte Sprache definieren. Möchte man also z.B. in F# entwickeln, sieht der Befehl wie folgt aus:

dotnet new -t web -l F#

Im Jahre 2005 starte ich mein erstes Weblog unter www.dotnetnukeblog.de, dass ich in den darauffolgenden Jahren aktiv mit Inhalten rund um das OpenSource CMS DotNetNuke© fühlte. Neben DotNetNuke-Themen wurden auch viele Beiträge zu .NET und SQL veröffentlicht.  

Nachdem sich im Jahre 2010 mein Fokus geändert hat und DotNetNuke© bei mir persönlich an Bedeutung verlor, wurden auch die Beiträge immer seltener. Nun nach rund 3 Jahren der "Ruhe" habe ich beschlossen, dass es Zeit wird meine Erkenntnisse und Ideen wieder zu publizieren. Obwohl der Name vom Blog - DotNetGeek - darauf schließen lässt, dass es sich hier wohl um .NET relevante Themen handelt, werde ich auch weitere Buzzwords behandeln:

• Node.js®
• Go
• Continues Delivery
• Docker
• DevOps
• Microservices
• Self-Contained System
• ...

All diese Themen waren in den letzten 2 Jahre Bestandteil meiner täglichen Arbeit. Ich habe genug Eindrücke und Ideen, um hier in den nächsten Monaten (und hoffentlich Jahren) hilfreiche Beiträge zu schreiben.

Da das .NET Framework selbst schon sehr umfangreich ist, werde und kann ich mich nicht mit allen Bereichen beschäftigen. Wer Inhalte zu WinForms oder WPF sucht, wird vermutlich enttäuscht werden. Mein Fokus liegt ganz klar auf Web-Technologien und daher wird ASP.NET (Core) ganz eindeutig im Vordergrund stehen. 

Warum habe ich mich für die Domain www.dotnetgeek.de entschieden? Ganz einfach: Meine - nicht "blinde" -  Liebe zu .NET und die Tatsache das ich auf vielen Plattformen den Username dotnetgeek registriert habe z.B. bei:

• http://www.twitter.com/dotnetgeek
• http://www.github.com/dotnetgeek
• https://hub.docker.com/u/dotnetgeek/
• http://stackoverflow.com/users/1876278/dotnetgeek