Fortuna Entwickler Blog

Hier wird Ihnen geholfen

SonarCloud - Master Solution - Analyse

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)
Kontrolliert werden kann dies mit dem Befehl:

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

Setzen der Path Variable mit allen vorherigen Pfaden (anpassen der Pfade beachten):

[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\SonarCloud\build-wrapper-win-x86" + ";C:\SonarCloud\sonar-scanner-msbuild-5.3.1.36242-net46",[System.EnvironmentVariableTarget]::Machine)

Kontrolliert werden kann dies mit diesem Befehl:

[Environment]::GetEnvironmentVariable('Path', [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" 

Design Projekt .NET Core Web API

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

In jedem Projekt sollte es folgende Struktur geben:
  • Controllers => Beinhaltet jegliche Logik zu den Endpoints
  • Services => Beinhaltet jegliche Logik zur Verarbeitung der Daten (Anfragen an Datenbank, Manipulation von Daten, Anfrage an andere APIs usw.)
  • Mappings (wenn gebraucht) => Automapper Konfiguration Dateien
  • Resources (wenn gebraucht) => alle Projektspezifischen Ressourcen wie AppSettings Konfigurations Model 
  • Interfaces (wenn gebraucht) => Selbsterklärend
  • Extensions (wenn gebraucht) => Selbsterklärend
  • Models (wenn gebraucht)  => Selbsterklärend

Folgende Nuget-Pakete sollten in allen Anwendungen installiert sein:

Damit alle Pakete korrekt funktionieren müssen folgende Dinge in das Programm eingebaut werden.

Microsoft.AspNetCore.Mvc.NewtonsoftJson
Folgendes muss unter in der Startup.cs Datei in der Methode ConfigureServices reingeschrieben werden. Dies setzt die neue JSON Libary fest.


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

Ein Controller dient als Sammelstelle aller Endpoints. Hier ist nochmal zu erwähnen, jegliche Logik sollte in die Services geschrieben werden und nur der Zugriff auf die Services bzw. auf die Endpoints sollte im Controller beschrieben werden.

Im ersten Schritt sollte ein BaseController implementiert werden. Dieser beinhaltet alle allgemein gültigen Funktionen zur Verarbeitung von HTTP Requests bzw. Responses.


Der BaseController sollte zwingend die HandleError Methode besitzen, damit alle Fehler geloggt werden. Außerdem ist wichtig, dass der Controller mit dem Attribute ApiController ausgestattet wird, damit beim Kompilieren erkannt wird, dass alle zu erbenden Klassen bzw. Controller Teil der API sind.

Wird dann ein Blick auf die "richtigen" Controller geworfen, müssen ein paar Dinge erledigt werden. Zuerst muss die Route bestimmt werden. Diese wird mit api/[controller] angegeben. Daraus resultiert in dem Fall immer der Pfad api/vertrag/xxx. Dies hat den Vorteil, dass wir nicht in jeder Funktion gewisse Teile des Pfads doppelt schreiben müssen. 
Darüber hinaus muss der Logger und die benötigten Services per Dependency injection eingebunden werden.


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 

NPM Config - MSBuild Pfad & Version bearbeiten

Vor kurzem hat Microsoft .net Version 5 auf den Markt gebracht. Dadurch haben sich in der Verwaltung von Angular Anwendung in Bezug auf asp.net Core Anwendungen ein paar Einstellungen geändert. Beim ausführen der Paketinstallation in einer Angular Anwendung über npm mit "npm install" führte vermehrt zu dem Problem, dass die MSBuild.exe nicht gefunden werden konnte.
Um dieses Problem zu beheben muss npm mitgeteilt werden, wo die .exe liegt und welche Version es nutzen soll.

Um den Pfad einzustellen muss folgender Befehl ausgeführt werden (ggf. Pfad anpassen):

  • npm config set msbuild_path "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe"
Um die Version einzustellen muss folgender Befehl ausgeführt werden (ggf. Versionsnummer anpassen):

  • npm config set msvs_version 2017
Stand 01.12.2020 muss Version 2017 noch angegeben werden, da NPM 2019 als Keyword nicht registrieren kann.

Ggf. kommt dieses Problem auch durch das builden von dem Package node-gyp in Verbindung mit einer Node.js Version 12+.

Weitere Informationen:
  • https://github.com/nodejs/node-gyp/issues/1753

Umstellung einer Assembly von .NET Framework auf.NET Standard

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.