Bei ASP.NET Core ist Dependency Injection ein Feature das fester Bestandteil des Konzeptes ist. Wenn man sein Interface und die dazu gehörige Implementierung registrieren möchte, gibt es dafür eine einfache Möglichkeit.

services.AddScoped<Interface,Implementation>();

Möchte man nun ein generic Interface registrieren liegt das Folgende zunächst nahe:  

services.AddScoped<IGenericRepository<T>,Repository<T>>();

dieser Ansatz funktioniert aber nicht.

Für die Registrierung von generic Interfaces muss man folgenden Ansatz wählen:

services.AddScoped(typeof(IGenericRepository<>), typeof(GenericRepository<>));

ASP.NET Core Applicationen benötigen nicht mehr zwingend einen IIS - Internet Information Server - für den Betrieb / Hosting. Auf die vielfältigen Hosting-Möglichkeiten möchte ich hier und jetzt nicht weiter eingehen und mich zunächst auf den IIS fokusieren.

In vielen vorhanden .NET Umgebungen wird einen IIS betrieben und soll vielleicht auch weiter betreiben werden. Wenn man nun eine ASP.NET Core Web Application im hosten möchte, muss man folgende Punkte durchführen:

Installation

Installation der  .NET Core Windows Server Hosting bundle. Dabei wird die NET Core Runtime, .NET Core Library, und das ASP.NET Core Module installiert. Letztes arbeitet als reverse-proxy zwischen dem IIS und Kestrel.

Nach der Installation muss der Server neu gestartet werden oder die Befehle net stop was /y und anschließend net start w3svc ausgeführt werden.

Konfiguration

Nun kann man wie gewohnt im IIS eine Webseite hinzufügen und einen neuen Application-Pool anlegen. Bei Application Pool wählt man als  .NET CLR version dann No Managed Code aus, da es für ASP.NET Core nicht notwendig ist die CLR zu laden. 

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: