Neuheiten Framework Studio 4.2
Informationen zu aktuellen Versionen und korrigierten Fehlern finden Sie in den Release-Informationen.
Neue Systemvoraussetzungen
In dieser Version gibt es einige Anpassungen bei den Systemvoraussetzungen. Im folgenden sind die wichtigsten Änderungen aufgeführt.
Datenbank-Server
Es wird der Oracle Server 12.2 oder höher (18c, 19c, ...) unterstützt. Ältere Versionen werden nicht mehr unterstützt.
Es wird der SQL-Server 2012 oder höher unterstützt. Ältere Version (z.B. SQL-Server 2008) werden nicht mehr unterstützt.
Important
Ein Betrieb mit einer älteren Datenbank-Version ist nicht möglich. Ein Connect auf so einen Datenbank-Server führt unmittelbar zu einer entsprechenden Fehlermeldung.
Oracle Client
Es wird nur noch der Oracle Managed Provider unterstützt.
Der Oracle ODP Provider wird nicht mehr unterstützt. Framework Studio benötigt damit keinen separaten Oracle-Client mehr.
64 Bit
Die folgenden Programme können nur noch auf 64-Bit Systemen installiert werden. Eine 32-Bit Installations-Routine wird nicht mehr angeboten:
- Framework Studio IDE / Package Manager
- Publish / Publish2Go
- Anwendungs-Broker
- Framework Studio Services
32-Bit wird weiterhin unterstützt für:
- Client-Rechner
- Print-Server
.NET Framework 4.8
Framework Studio setzt auf das .NET Framework 4.8 auf. Der Installer ist im Requirements-Paket enthalten und muss ggf. vor der Installation von Framework Studio ausgeführt werden.
Alternativ kann der Installer auch direkt bei Microsoft heruntergeladen werden: https://dotnet.microsoft.com/download/dotnet-framework/net48
Betriebssysteme
Mit dem Umstieg auf das .NET Framework 4.8 können einige ältere Windows Betriebssysteme nicht mehr unterstütz werden. Es werden aktuell folgende Betriebssysteme unterstützt:
Server
- Windows Server 2012 R2 - oder höher
Client / Entwicklungs-Rechner
- Windows 10 (Version 18.03 - oder höher)
- Windows 8.1
Für die Endanwender-Rechner bzw. Terminal-Server gelten weiter die bisherigen Anforderungen.
C# 7
Mit dem Update auf das .net Framework 4.8 unterstützt Framework Studio auch die C# Sprach-Features bis zur Version 7.3. Eine Übersicht der Features bietet die Web-Seite:
In der folgenden Liste werden einige Features genannt, die seit C# 6 hinzugekommen sind. Der Einsatz dieses Features ist in Framework-Studio empfehlenswert:
- out variables - inline-Deklaration (C# 7.0)
Folgende Features können ggf. sinnvoll sein:
- Tuples (C# 7.0) - nur innerhalb von Methoden-Code (z.B. bei Linq-Queries), nicht als Parameter oder Rückgabe-Typ von Methoden
- Inferred tuple element names (C# 7.1)
- Tuples support == and != (C# 7.3)
- Pattern matching (C# 7.0)
- Local functions (C# 7.0) - aber nur sehr gut überlegt!!
MLKey Wörterbuch
Eine zentrale Neuerung in der Version 4.2 betrifft das Handling der fremdsprachigen Texte. Diese werden jetzt in einem zentralen Wörterbuch verwaltet.
Bisher wurden alle Texte am jeweiligen Element (z.B. Metadatentyp, ComponentProperty, FormControl) gepflegt. Jetzt werden an allen diesen Stellen Schlüssel (MLKeys) angegeben, die auf das zentrale Wörterbuch verweisen. Dadurch hat man erst einmal etwas mehr organisatorischen Aufwand, aber auf längerer Sicht betrachtet bringt diese Vorgensweise viele Vorteile:
- Redundanzen werden vermieden, weil existierende Texte wiederverwendet werden können und sollen. Dadurch erhält man zudem in der kompletten Anwendung durchgängige und einheitliche Bezeichnungen.
- Die fremdsprachigen Übersetzungen können sehr einfach und zentral gepflegt werden.
- Besonders im Customizing-Package ist das von großem Vorteil, weil jetzt nicht mehr die einzelnen Elemente ausgecheckt werden müssen.
- Das Wörterbuch kann auch im Service-Release bearbeitet werden.
- Der Export und Import von Texten ist sehr einfach. Es wird das standardisierte TMX-Format verwendet. Texte können so zwischen verschiedenen Packages und Versionen ausgetauscht werden. Auch eine Übersetzung durch Werkzeuge oder externe Dienstleister ist dadurch deutlich einfacher als bisher.
Eine detailliert Beschreibung der Funktionalität finden sie im Kapitel MLKey.
Es ist sinnvoll, die Texte des eigenen Packages in das Wörterbuch zu überführen. Bitte beachten sie dazu die Hinweise und Anleitungen für die Migration.
Fremdsprachen im Customizing-Package
Sprachen werden jetzt an der Package-Version organisiert und können somit in Customizing-Packages ergänzt werden.
Code-Messages überarbeitet
Die vom Exception- und MessageBox-Wizard generierten Code-Messages wurden überarbeitet.
Das bisherige Konstrukt mit #region
wurde durch eine Variante mit einem einfachen eingefärbten Kommentar // FSCodeMessage:
ersetzt. Das macht den Quellcode kompakter und leserlicher – ohne extra aufklappen zu müssen.
Der XML-Teil, welcher bisher die Informationen für die Wizard-Dialoge beinhaltet hat, entfällt. In der Vergangenheit konnte es sein, dass die XML-Informationen vom Code abwichen. Der Wizard hat dann den Code ignoriert und einfach ersetzt. Dadurch konnten wichtige Infos – wie z.B. ein MessageBox EventHandler – verloren gehen. Die Informationen werden jetzt aus dem Code geparsed. Kann (z.B. aufgrund von manuellen Anpassungen) der Code nicht geparsed werden, kann er nicht mehr durch den Wizard bearbeitet werden.
Die Code-Messages können einen MLKey aus dem Wörterbuch verwenden. Die bisherige Variante mit TextCollection-Einträgen soll nach und nach durch die MLKeys ersetzt werden und so die ctMessage-TextCollections auslaufen.
Bei MsgBox.Show() sind die Enum-Werte für Button und Icon leserlich ausgeschrieben. Bisher wurden dort nur die int-Werte verwendet.
Die Konvertierung des bestehenden Codes in das neue Format erfolgt auf folgende Weise:
- Durch die MLKey-Konvertierungs-Routine – diese setzt alle Code-Messages automatisch auf einen MLKey und/oder das neue Format um.
- Durch manuellen Aufruf des Exception- oder MsgBox-Wizards. Beim Speichern wird der Code durch die neue Variante ersetzt.
Bei beiden Konvertierungen wird nur der Code betrachtet - der alte XML-Teil wird ignoriert. Neue Messages werden immer im neuen Format generiert. Dabei ist es egal, ob ein Textcollection-Eintrag oder ein MLKey verwendet wird.
Neue Text-Funktionen
In Framework Studio 4.2 wurden im Zuge der Umstellung auf die MLKeys auch die Text-Zugriffe auf Text-Collections und DevMLStrings überarbeitet.
Note
Es muss eine Migration durchgeführt werden.
Actions SetEnabled und SetVisible nullable
Die Control-Actions SetEnabled
und SetVisible
haben neue Überladungen bekommen, welche das Zurücksetzen auf den im Property-Grid des Form-Designers eingestellten Wert ermöglichen.
Dazu wurden folgende Überladungen ergänzt, bei denen der null
-Wert zum Zurücksetzten verwendet werden kann:
SetEnabled(bool? value)
SetEnabled(FSbool value)
SetVisible(FSVisibility? value)
Caution
Achtung, falls Reflection verwendet wurde!
Sollte eine der ursprünglichen Methoden aus irgend einem Grund per Reflection angesprochen worden sein, so kann es nun zu dem Problem kommen, dass nicht mehr eine eindeutige, sondern mehrere Überladungen der Methode gefunden werden. Die Überladungen SetEnabled(bool value)
und SetVisible(FSVisibility value)
wurden entfernt, da Aufrufe vom Compiler direkt auf die entsprechenden Nullable-Überladungen umgelenkt werden.
Forms und Workflows Obsolete setzen
Soll ein Form oder ein Workflow nicht mehr verwendet werden, so können die für diese Elemente generierten Klassen mit dem Obsolete
Attribut versehen werden. Dazu muss der Name des Elements mit _Obsolete enden.
Beispiel: wlfArticleDetail_Obsolete
Der Compiler erzeugt dann bei Verwendung der Elemente Warnings in der Form 'wflArticleDetail_Obsolete' is obsolete: 'Workflow 'wflArticleDetail_Obsolete' will be deleted in future version.'.
Weitere Neuerungen
- Die MLColumn-Sprache kann zur Laufzeit beeinflusst werden.
- An den DBColumns können die Größen-Angaben überschrieben werden, auch wenn ein Metadatentyp zugeordnet ist.
- Compare with previous in Method- und Element-History Browsern
- Such-Funktionalität für die ML-Columns
- Im Register AccessUnits wird bei einer ungültigen Parent Beziehung ein Button 'Fix the parent Access Unit' angezeigt. Dieser löscht die ungültige Parent Beziehung und legt, falls kein anderer gültiger Parent vorhanden ist, die Access Unit unter Root.