Fortuna Entwickler Blog

Hier wird Ihnen geholfen

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.


NLog in in ASP.NET Core einbinden

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
Hierbei bitte darauf achten, dass die Versionen verwendet werden, die auch bereits bei anderen Fortuna Anwendungen verwendet werden, damit es einheitlich bleibt.

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:

nlog.config (1,5KB)nlog.Development.config (1,9KB)nlog.Production.config (1,9KB)nlog.Test.config (1,9KB)

Nun benötigt man noch auf den Servern Ordner, wo die Logs hingeschrieben werden sollen (aktuell machen wir mit NLog File Logging).

Man findet den allgemeinen Log-order wie folgt:
  • \\webentw4\Logs
  • \\webtest4\Logs
  • \\web4\Logs
Jede Anwendung bekommt dort drin einen eigenen Unterordner (z.B. Dashboard). Außerdem befindet sich in den Logs-Ordnern ein "_Archive"-Ordner, wo auch jede Anwendung einen eigenen Unterordner drin besitzt.

Um nun die neuen Ordner anzulegen muss man sich per RDP auf die einzelnen Server connecten und die Unterordner in Logs und _Archive anlegen, da nur der Admin Schreibrechte hat und die IT-User lediglich Leserechte. Das Anlegen der Unterordner sollte so gemacht werden, wie die bereits vorhanden Ordner, damit diese Struktur beibehalten wird. Die Pfade zu den Ordnern müssen dann in den NLog CONFIG-Files eingetragen werden.

Nun ist alles fertig konfiguriert und der Logger kann im Controller der ASP.NET Core Anwendung verwendet werden. Da durch die Anpassung der main-Methode die Dependency Injection aktiviert wurde, kann der Logger ganz einfach im Konstruktor des Controllers verwendet werden:


Man benötigt einfach eine globale Variable vom Typ ILogger im Controller und man nimmt den ILogger auch im Kopf des Konstruktors vom Controller mit auf. Falls es noch keinen Konstruktor gibt im Controller, leget man einfach einen an. Im Konstruktor selbst weist man nur der globalen Variable die lokale Konstruktor-Variable zu. Nun kann man den Logger überall im Controller verwenden. Dies macht man für jeden Controller der Anwendung:


Das Ergebnis des File Logging sieht dann wie folgt aus:



Scheduler updaten

Allgemein

Im derzeitigen System existieren zwei Scheduler Services, die für Web-Tasks auf dem Server WEB3 und für VWS-Tasks auf IASPROD2 laufen. Beide Scheduler Programme sind Windows Services und befinden sich in der selben Solution:

Fortuna Scheduler updaten

Um den Fortuna Scheduler zu updaten, muss man zunächst die Solution öffnen. Anschließend stellt man sicher, dass die Build-Configuration auf RELEASE steht für eine Produktivübergabe (Testübergaben finden bei Scheduler in der Regel nicht statt).

Anschließend die gesamte Solution builden. Ist dies erfolgreich, so wechselt man in das Release-Verzeichnis des Projektes "Fortuna.Scheduler.Service". Von hier kopiert man alle DLL-Dateien und die "Fortuna.Scheduler.Service.exe" in ein TEMP-Verzeichnis auf dem Server WEB3.

Nun muss man sich per Remote Desktop auf WEB3 anmelden und den Dienst zunächst stoppen


Wenn dies erledigt ist, können die DLL-Dateien aus dem TEMP-Verzeichnis in das Arbeitsverzeichnis des Scheduler Service kopiert und die vorhandenen Dateien überschrieben werden (Sicherung vorher bietet sich an). Das Arbeitsverzeichnis befindet sich auf WEB3 hier: "C:\Program Files\Fortuna Scheduler"

Sind neue Jobs hinzugekommen oder muss die Konfiguration bestehender Jobs angepasst werden, so muss dies in der Datei "jobconfig.xml" durchgeführt werden. Anschließend kann der Service wieder gestartet werden. Über das Ereignisprotokoll des Betriebssystems kann festgestellt werden, ob der Dienst fehlerfrei gestartet wurde, oder ob Fehler aufgetreten sind. Einige Fehler stellen sich aber auch erst heraus, wenn die ersten Jobs zum ersten Mal ausgeführt werden.

VWS Scheduler updaten

Bei dem VWS Scheduler läuft es ähnlich ab. Nach dem lokalen Builden auf RELEASE-Config, wechselt man in das Release-Verzeichnis des Projekts "Fortuna.Scheduler.VWS". Auch hier nimmt man alle DLL-Dateien und die "Fortuna.VWS.Scheduler.Service.exe" und kopiert sie zunächst in ein TEMP-Verzeichnis auf der Maschine IASPROD2.

Auch hier muss man sich per Remotedesktop anmelden und als erstes den Dienst stoppen. 

Nun werden die DLL-Dateien aus dem TEMP-Verzeichnis in das Arbeitsverzeichnis des Scheduler kopiert (Sicherung vorher). Das Arbeitsverzeichnis ist hier: "C:\myLife\Tools\Scheduler". Wenn Anpassungen an den Jobs durchzuführen sind, dann wird dies ebenfalls in der "jobconfig.xml" gemacht. Nun kann auch dieser Service wieder gestartet werden. Fehler werden im Ereignisprotokoll festgehalten.

Probleme mit DevArt

Hin und wieder kann es bei einer Produktivübergabe zu Problemen mit DevArt kommen. Die äußern sich dadurch, dass es bei der ersten Ausführung eines Jobs nach einer Übergabe zu Fehlern beim Zugriff auf die DB kommt:


Dies liegt daran, dass die Lizenz nicht korrekt in die Anwendung integriert wurde. Um dies zu beheben, muss man im Visual Studio in der Scheduler Solution die Lizenz neu in die Anwendung integrieren:

Bei allen fehlerhaften Assemblies muss der "Fix-Button" gedrückt werden:


Anschließend muss die Solution erneut kompiliert werden und die Dateien im Arbeitsverzeichnis des Scheduler auf WEB3 oder IASPROD2 noch einmal ausgetauscht werden (Dienst vorher beenden und nach dem Kopieren neustarten). 

TabletWorld Showroom aufsetzen

Was ist bereits vorhanden:

TWWEBSHOW

  • Microsoft Windows Server 2008R2
  • Apache Tomcat (konfiguriert für VENTA)
  • Microsoft Internet Information Server (konfiguriert für Fortuna)
  • ...

TWDBSHOW

  • Oracle DB
  • User GUTINGIA, WEBDATA, WEBFRW, WEBSERVICES, VENTA-User
  • ...


Was ist zu tun:

TWWEBSHOW

  • Kopieren der aktuellen Version von VENTA
  • Kopieren der aktuellen Version der iPad App
  • Publilshen der aktuellen Version der Fortuna-Anwendungen
  • ...

TWDBSHOW

  • Anlegen der Tabellen / Views / Functions etc. für VENTA
  • Anlegen der Tabellen / Views / Functions etc. für Fortuna
  • Anlegen der Tabellen / Views / Functions etc. für VWS / GPS
  • Übernehmen von Basisdaten
  • Automatisiertes Befüllen von Anfangsdaten (per Script)
  • ...


Die Excel-Tabelle enthält eine Übersicht über die Tabellen in WEBDATA, WEBFRW, WEBSERVICES und GUTINGIA. Man sollte diese Übersicht als Basis dafür nehmen, welche Tabellen ob und wie gefüllt werden müssen. Auf Basis dieser Übersicht lässt sich dann ein Script entwickeln.

Tabellen Januar 2016.xlsx (53KB)

TabletWorld Showroom

Server für Tabletworld Showroom:

TWWEBSHOW

  • Windows Server 2008R2
  • 8GB RAM,  2 CPU
  • 10.98.98.163 (intern)
  • 81.20.117.20 (extern)
  • http://showroom.honorarkonzept.de
  • Apache Tomcat (Port 80)
  • Microsoft IIS (Port 88)

TWDBSHOW

  • Windows Server 2008R2
  • 8GB RAM, 2 CPU
  • 10.98.98.164 (intern)
  • Oracle DB
  • Oracle AppServer
  • dbshow (VWS/GPS-DB)
  • iasshow (Forms)

Voraussichtliche Aufwände: 1x/ Jahr je 3 Tage


Grundeinrichtung ohne Daten:

VENTA -> Christian? Ist das möglich?

VWS / GPS -> Torsten / Klaus / Helge (IAS)

Fortuna -> Christoph

Venta / iPad App (Tablet) -> Christoph

Infrastruktur / BS /WS -> Erico