Fortuna Entwickler Blog

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:

nuGet packages

Es ist nicht sinnvoll, nuGet Packages in unsere Release-Zyklen einzubinden; dies widerspricht dem eigentlichen Sinn der nuGet Packages.

In einem Package sollen Funktionen umgesetzt werden, welche Produktunabhängig sind und allgemein Verwendet werden können, z.B. Mailversand, PDF Erstellung und Ähnliches

Empfehlung Herr Schmidt: 

• Rückführung Produktspezifischer Packages in die jeweiligen Solutions

• Neustrukturierung der Ordnerstruktur für Solutions

• Alle Solutions in einem Ordner

• Alle Webanwendungen in einem eigenen Ordner in einem Unterordner (‚web‘)

• Alle Bibliotheken in einem eigenen Ordner in einigen wenigen Unterordnern (‚logic‘, ‚data‘)

• Damit dann Kombination aus nuGet und Bibliotheken

• Builds für Projekte automatisieren

• Builds für nuGet Packages erstellen Symbole für Debugging, welche vorgehalten werden

Branches, Merges, etc.

Der aktuelle Stand kann so weiter geführt werden.

Das Verschieben von Branches kann möglicherweise in Zukunft wieder verfügbar sein. Derzeit gibt es keine andere Möglichkeit, als es so zu tun, wie wir es derzeit machen.

Herr Schmitt hat uns Alternativen zur derzeitigen Vorgehensweise aufgezeigt. Diese wären gggf. Zu diskutieren.

Event- und Fehlerlogging

Das Logging, so wie wir es derzeit betreiben ist weder performant noch sonst zu empfehlen.

Empfehlung Herr Schmidt: 

• Einsatz von NLog

• Umstellung aller Anwendungen auf einen Asynchronen Logger

• Logging gegen einen WebService (in Azure)

• Archivierung von Logs in Azure Storage

• Ggf. Automatisiertes Herunterladen aus Azure Storage

Benutzer, Security

Eine eigene Benutzerverwaltung ist aufwendig, fehleranfällig und nur schwer abzusichern.

Empfehlung Herr Schmidt:

• Microsoft Azure Active Directory

• Vergleichsweise einfache Integration in bestehende Webanwendungen

• Keine Verwendung mit VENTA möglich

• Derzeit nur für Versicherungskunden

• Integration in Azure Service Management, um APIs abzusichern (myPension z.B.)

Swagger

Der Einsatz von Swagger, so wie es derzeit bei uns verwendet wird, entspricht vorgesehenen Verwendung. Keine ToDos.

Oracle / Entities

Oracle ODP.NET ist nicht empfehlenswert, weil vergleichsweise langsam und schlechte Tool-Unterstützung.

DevArt for Oracle ist das Tool der Wahl für den Zugriff auf Oracle Datenbanken via Entities. Der fehlende Service seitens DevArt muss selbst geleistet werden: Neue Versionen als nuGet zur Verfügung stellen, eigene Versionshistorie vorhalten.

Sonstiges

Herr Schmitt empfiehlt die Anbindung unseres AD an Azure AD.

C# 7.0/8.0 bringt wenig sinnvolles Neues, was wir nicht schon kennen

ASP.NET Core bringt für uns keine Vorteile, solange wir nicht mit Docker und/oder anderen Betriebssystemen arbeiten.

Angular.js (oder React.js oder Vue) sind Frameworks, die interessant sein können und gesondert betrachtet werden müssten.

TypeScript als Ersatz für JavaScript ist empfehlenswert.

JavaScript in Webseiten selbst sollte überhaupt nicht benutzt werden, sondern immer in eigene Dateien (dann auch als TypeScript) ausgelagert werden.

Fotos

Da wir meistens mit Entities arbeiten in unseren .NET-Anwendungen, kriegen wir hierbei gar nicht so mit, welche Statements eigentlich an die DB abgeschickt werden. Hierfür gibt es von DevArt ein sehr gutes Tool: DBMonitor

Mit dem DBMonitor hat man die Möglichkeit den gesamten Datenbank-Traffic, der innerhalb einer Anwendung läuft, zu beobachten.

Der DBMonitor kann ohne zusätzliche Kosten hier heruntergeladen werden:

https://www.devart.com/dbmonitor/download.html

Wenn das Tool heruntergeladen wurde, einfach lokal auf dem Entwicklungsrechner installieren und starten.

Nun muss noch der Anwendung, die man monitoren möchte, gesagt werden, dass die Daten an den DBMonitor geschickt werden. Dazu ist es erforderlich, dass man zwei Assemblies der Anwendung hinzufügt:

• Devart.Data
• Devart.Data.Oracle

var monti = new OracleMonitor() { IsActive = true };