Fortuna Entwickler Blog

Für die Master Solution braucht es einen anderen Ablauf. Damit es manuell funktioniert müssen folgende Schritte erfolgen.

Vorbereitung

Bevor die eigentliche Analyse gestartet werden kann, müssen verschiedene Schritte vollzogen werden.

1. Herunterladen des Sonarscanners. 

Damit die Zeilen von Code analysiert werden können, brauchen wir den Client von SonarCloud dazu.

Dort sollte die net4.6 Version genommen werden, aufgrund des Mixes von C++ und C# in der Solution. 

Die .zip Datei nach dem Entpacken an einen geeigneten Platz legen (z.B. unter C:\\SonarCloud). Im späteren Schritt, werden wir den Pfad noch brauchen.

2. Herunterladen des Buildwrappers

Damit die Logdateien während der Analyse gefüllt werden, wird der Buildwrapper von SonarCloud benötigt.

Die .zip Datei nach dem Entpacken an einen geeigneten Platz legen (z.B. unter C:\\SonarCloud). Im späteren Schritt, werden wir den Pfad noch brauchen.

3. Setzen der Umgebungsvariablen

Damit verschiedene Einstellungen direkt gefunden werden müssen folgende Befehle in einer Powershell Konsole ausgeführt werden:

[Environment]::SetEnvironmentVariable("SONAR_SCANNER_OPTS", "-Dhttps.proxyHost=10.98.98.222 -Dhttps.proxyPort=8080",[System.EnvironmentVariableTarget]::Machine)

[Environment]::GetEnvironmentVariable("SONAR_SCANNER_OPTS", [System.EnvironmentVariableTarget]::Machine)

3. Herunterladen des aktuellen Java JDKs

Für den Scanner wird Java mindestens in der Version 11 benötigt.

Analyse - Routine

Token können innerhalb der SonarCloud Oberfläche als Administrator erzeugt werden:

Zum Starten der Analyse muss zuerst auf der Kommandozeile in das Verzeichnis navigiert werden in der die Master Solution liegt. Folgend werden die Befehle ausgeführt:

SonarScanner.MSBuild.exe begin /k:"Master_MyLife" /o:"mylife-leben" /d:sonar.host.url="https://sonarcloud.io" /d:sonar.login="bfe291ef26f056234f4782e8660fbefe541fc12f" /d:sonar.cfamily.build-wrapper-output="build_wrapper_output_directory"

build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_directory MSBuild.exe Master.sln /t:Rebuild /p:Configuration=Release /p:Platform=x64

SonarScanner.MSBuild.exe end /d:sonar.login="bfe291ef26f056234f4782e8660fbefe541fc12f" 

Sonarcloud ist eine Software zur statischen Codeanalyse. Statische Codeanalyse bedeutet, dass der Code nach gewissen Regeln basierend auf der jeweiligen Programmiersprache überprüft wird. Sonarcloud setzt diesen Prozess um, indem eine Auflistung aller Resultate der Analyse präsentiert wird und zusätzlich Verbesserungsvorschläge aufgezeigt werden. 

Damit wir im Unternehmen die Software vollumfänglich nutzen können wird in diesem Artikel beschrieben, wie die Software zu benutzen ist.

Einrichten von Azure DevOps

Sonarcloud wird bei uns über die Azure DevOps Pipeline genutzt. Diese ist so konfiguriert, dass sie am Sonntagabend einen automatischen Durchlauf auslöst. Für die Einrichtung würde ich auf den folgenden Artikel verweisen. Da dieser alles vollumfänglich und vernünftig erklärt. Wichtig für uns sind folgende Stichpunkte:

• Als Buildtool sollte MSBuild genutzt werden, da derzeit noch .NET Framework Anwendungen betrieben werden. Sollten diese irgendwann wegfallen, könnte über eine Analyse über dotnet nachgedacht werden
• Bei der Einrichtung der Pipeline darf nicht vergessen werden, dass verschiedene Packages aus anderen Quellen, wie z.B. Telerik kommen. Dazu muss unter dem Punkt NuGet restore die Abhängigkeit eingetragen werden
• Sollten verschiedene Dateitypen oder Ordner nicht mit in die Analyse einbezogen werden, dann kann dies über die Additional Properties konfiguriert werden. Um alle möglichen Parameter zu sehen, sollte die Sonarcloud Dokumentation angeschaut werden. 

Um in der Zukunft einen einheitlichen Aufbau aller Projekte zu haben, wird hier ein Beispielaufbau einer Anwendung erklärt. Alle Angaben beziehen sich auf .NET Core Web APIs.

Aufbau Struktur

Folgende Nuget-Pakete sollten in allen Anwendungen installiert sein:

• Swashbuckle.AspNetCore => Swagger - Dokumentation bzw. Testen der API
• NLog & NLog.Web.AspNetCore => Logging 
• Microsoft.AspNetCore.Mvc.NewtonsoftJson => Austauschen der System.Text.Json mit der NewtonsoftJson Libary, da die Microsoft Libary häufig Probleme hat mit dem serialisieren und deserialisieren von Dictionaries (Aufpassen auf richtige Version hier)

Swashbuckle.AspNetCore

Um Swagger nutzen zu können muss an zwei verschiedenen Stellen in der Startup.cs Datei Code eingefügt werden.

Zuerst in der ConfigureServices Methode nach der AddControllers Funktion muss Swagger hinzugefügt werden.

Danach muss Swagger noch aktiviert werden, dazu muss in der Configure Methode folgendes geschrieben werden.

Hier sind vor allem die Zeilen 35-39 wichtig. Der Aufbau der restlichen Zeilen kann aber übernommen werden. Hier gilt zu beachten, dass, dass der Name der API jeweils angepasst wird.

NLog & NLog.Web.AspNetCore

http://webentw4/Blog/post/2020/05/12/nlog-in-in-asp-net-core-einbinden

ContentTypes

Die ContentTypes werden zentral in der Startup.cs eingestellt. Die meiste Zeit wird nur application/json benötigt. Sollten weitere benötigt werden, muss geschaut werden, ob diese zentral eingestellt werden oder nur für eine bestimmte Funktion. Zu beachten ist, wenn die ContentTypes überschrieben werden müssen an der Funktion dann alle angegeben werden.

Aufbau des Controllers

Aufbau eines Endpoints

Alle Endpoints sollten folgenden Aufbau besitzen:

• Http Request Methode mit Pfad => Funktionsname bzw. Abwandlung angeben und jeweilige Parameter mit Datentypen
• Consume/Produces Types => Content-Types => In der Regel brauchen wir nur application/json (allgemein) => Diese werden vorher zentral in der Startup.cs eingestellt und nur genauer angegeben, wenn zusätzliche fehlen
• ProducesResponseType => Rein zu Dokumentationszwecken gedacht, aber sinnvoll zum testen => Alle Rückgabetypen mit Statuscodes eintragen
• Rückgabetyp => Sollte eigentlich immer IActionResult sein, da wir unterschiedliche Rückgabetypen haben wie unter ProducesResponseType zu sehen ist, außer bei asynchronen Aufrufen, dann sollte es Task<IActionResult> sein
• Funktionsname => Titel der Funktion, wenn asynchron an den Namen immer ein Async anhängen
• Try-Catch-HandleError => Für unerwartete Fehler wie z.B. in der Datenbank 

Um eine asp.net Core Anwendung hosten zu können, gibt es zwei Möglichkeiten. Zum einen InProcess und zum anderen OutOfProcess. Im Folgenden wird der Unterschied erklärt:

• InProcess: Das Hosting wird über den IIS-Server bereitgestellt.
• OutOfProcess: Das Hosting wird über den Kestrel Web Server bereitgestellt.

Wenn eine asp.net-Core Anwendung mit einem Frontend wie z.B. Angular geschrieben wird, müssen meist statische Dateien bereitgestellt werden. Im Folgenden wird eine Erklärung dafür gegeben:

• UseStaticFiles: Der Befehl gibt an, dass statische Dateien wie js, css, html usw. bereitgestellt werden. Typischerweise aus dem wwwrooot-Ordner, wobei dieser geändert werden kann. Die Dateien werden so wie sie erstellt worden sind dem Clienten zur Verfügung gestellt.
• UseSpaStaticFiles: Der Befehl registriert eine Middleware, die dafür sorgt, dass Dateien aus dem Ordner bereitgestellt werden. Der Pfad wird dafür in de Funktion ConfigureServices => AddSpaStaticFiles konfiguriert.
• UseSpa: Der Befehl registriert eine Middleware, welche alle Parameter enthält, um die Anwendung starten zu können. Z.B. aus welchem Ordner die Anwendung gestartet wird, in welcher Modus (Dev,Prod) und auch mit welchem Befehl die Anwendung gestartet wird (z.B. npm start).

Seit .NET Core 3.0 hat Microsoft eine eigene Libary (System.Text.Json) freigegeben, um Operationen im JSON-Format durchzuführen. Darunter fällt auch das serialisieren und deserialisieren von Requests & Respones an eine API.

Leider hat die Libary noch ein paar Schwierigkeiten (Stand 09.10.2020) komplexere Datentypen, wie Dictionaries zu verarbeiten. Teilweise treten System.NotSupportExceptions auf, da die Libary, die Datentypen nicht unterstützt.

Damit das Problem umgangen werden kann, gibt es weiterhin die alt bekannte Newtonsoft.Json-Libary, die genutzt werden kann und auch mit komplexeren Datentypen umgehen kann.

Folgende Schritte müssen durchgeführt werden, um die Libary einzubinden:

1. Newtonsoft.Json als Nuget Paket hinzufügen
2. Als nächstes abhängig davon was für ein Projekt vorliegt, muss in der Startup.cs-Datei folgende Zeile geändert/hinzugefügt werden:

Zunächst wählt man ein projekt aus, dass man auf .NET Standard umstellen möchte und wechselt im Datei Explorer zu diesem Projekt:

Jetzt legt man sich eine Sicherheitskopie irgendwo von diesem Ordner an, in dem man sich befindet und wechselt anschließend wieder ins Visual Studio.

Dort entfernt man das Projekt aus der Solution:

Jetzt kann man das Projekt auch auf Datei-Ebene löschen:

Als nächstes wird das Projekt neu in der Solution angelegt. Auch hier muss die selbe Stelle genommen werden, wo das alte Projekt lag:

Als Typ nimmt man die Class Library für .NET Standard. Natürlich mit der Sprache C#:

Der Name muss der selbe sein, den das Projekt auch schon früher hatte und der Ort muss der selbe sein, wo das alte Projekt vorher auch schon lag:

Jetzt ist das Projekt in der Solution. Die enthaltene Klasse "Class1.cs" kann man direkt einfach löschen:

Nun muss man den Code wieder in das Projekt packen. Dazu klickt man mit rechts auf das projekt und sagt "Add existing Item":

Im darauf folgenden Dialog wählt man aus seiner Sicherheitskopie sämtliche Code-Dateien aus (*.cs). Sollte das Projekt früher eine Ordnerstrukur gehabt haben, so muss man darauf achten, dass diese 1:1 nachgebildet wird. Sie muss auch wieder so vorhanden sein wie früher. Bitte jetzt nicht umstrukturieren!!!!:

Man sieht jetzt, dass die Dateien wieder im Projekt sind und die CS Dateien sind auch nicht ausgecheckt, sondern eingecheckt, weil sie den selben Namen haben wie vorher und die selbe Struktur und den selben Inhalt:

Nun kompiliert man zum ersten Mal das neue Projekt. Es wird dann möglichweise zu Fehlern kommen, da das alte Projekt Referenzen auf andere Fortuna Projekte hatte oder NuGet Packages eingebunden waren. Die muss man dann natürlich wieder hinzufügen. Man kann allerdings nur Fortuna Projekte referenzieren, die bereits auf .NET Standard umgestellt sind. Daher ist es hier sehr wichtig, dass man auf die Reihenfolge achtet, wenn man Fortuna Projekte auf .NET Standard umstellt!!!! Dies prüft man am besten am Anfang!!!!

Wenn sich das Projekt selbst kompilieren lässt, muss man prüfen, ob sich auch noch die Solution kompilieren lässt. Also macht man ein Build auf die Solution. Man wird dann wieder einige Fehler bekommen, denn durch das Entfernen des Projektes am Anfang aus der Solution, wurden bei vielen anderen Projektten auch die Referenz entfernt. Man erkennt dies in der Solution auch gut daran, dass diese Projekte in der Solution jetzt ausgecheckt sind (roter Haken).

Bei all diesen Projekten muss man nun die Referenzb auf dieses Projekt wieder reinnehmen.

Lässt sich die Solution anschließend wieder komplett durchkompilieren, geht es an die Feinheiten. Dazu klickt an doppelt auf das neue Projekt drauf, so dass man die Config des Projektes als XML sieht:

In der zweitenPropertyGroup fügt man nun noch folgende Zeile ein:

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

Sieht dann so aus:

Jetzt kann man alles einechecken in der Solution, also auch die Solution selber und die Projekte bei denen die Referenzen neu gesetzt werden mussten. Am besten hat man sich für die Umstellung des Projektes ein eigenes Workite angelegt.

Die Umstellung auf .NET Standard ist damit abgeschlossen.

Um NLog in einer ASP.NET Core Webanwendung oder Sevice zu verwenden, müssen zunächst die entsprechenden NuGet Packages installiert werden in der Anwendung. Dies sind die folgenden Packages

• NLog
• NLog.Web.AspNetCore

Als nächstes wird eine lokale Umgebungsvariable "IS_LOCAL" in der ASP.NET Core Anwendung angelegt. Der Wert wird auf "true" gesetzt:

Anschließend wird die "Program.cs" Datei angepasst. Diese sieht ursprünglich ungefähr so aus:

Die "main"-Methode (Kann von Fortuna.Web.Abschluss kopiert werden) muss so angepasst werden:

Und die "CreateWebHostBuilder"-Methode so:

Als nächstes müssen die CONFIG-Dateien für NLog hinzugefügt werden. Hier bietet es sich an, diese von einer anderen Fortuna Anwendung wie Fortuna.Web.Abschluss zu kopieren, damit das Logging in den Anwendungen einheitlich passiert. Es müssen dann lediglich die Pfade in den CONFIG Dateien angepasst werden. Ich habe die Dateien auch mal als Anhang an diesen Post gehangen: