Mit dem Werkzeug ExpEdge können zur Unterstützung der Implementierung von Anwendungskomponenten in .NET unterstützende .NET-Klassen in einzelne Assemblies erzeugt werden. Nachfolgend sind die speziellen Optionen für dieses Szenario bei Aufruf des Werkzeuges beschrieben. Allgemeines zu der Befehlszeile und der Optionen finden Sie hier.
Mit der Optionsangabe Anwendung wird festgelegt, zu welcher Anwendung die von ExpEdge erzeugte Assembly gehören soll. Wenn keine Angabe erfolgt, wird die Anwendung aus dem aktuellen Kontext benutzt. Aus den Anwendungsangaben wird der Name der Assembly gebildet.
Mit der Angabe einer Version kann festgelegt werden, welche Version für die Assembly registriert werden soll. Die Versionsangabe wird als letzter Bestandteil der AssemblyVersion und AssemblyFileVersion verwendet.
Die Angabe Company wird für die Bildung des Namens der zu generierenden Assembly benutzt.
Wird kein Zielverzeichnis angegeben, so wird der Pfad über die Einstellung für den Bausteintyp ASSY in der Bstn-Tabelle der TAA-Metadefinitionen ermittelt (bspw. $E\$V\$A\ASSY).
Die Optionsangabe Name legt fest, welchen Namen die erzeugte Assembly erhalten soll. Wird keine explizite Angabe gemacht, wird der Name gebildet aus dem Firmenkürzel und der Anwendung.
Mit der Option -proj <Projektdatei> kann angegeben werden, welcher Name für die zu erstellende Projektdatei genommen werden soll. Der Name soll nur die Basename, ohne Erweiterung beinhalten. Die notwendige Erweiterung wird von ExpEdge hinzugefügt. Wird keine Projektdatei angegeben, wird der Name der Projektdatei aus dem Namen der zu erstellenden Assembly gebildet.
Mit der Option -rns <Rootnamespace> kann angegeben werden, wie die Namensgebung für die oberste Namespace gebildet werden soll. Wird keine explizite Angabe gemacht, wird der Name gebildet aus dem Firmenkürzel und der Zeichenfolge Taa.
Falls ExpEdge mit der UpdateMode-Option ausgeführt, soll nur für die angegebenen Komponenten (ggf. mit Wildcard-Angaben) neuer Code erzeugt werden. Die Zusammensetzung der Zielassembly bleibt unverändert. Wenn also die Komponente bereits in der Zielassembly vorhanden ist, wird diese nach einem erneuten Build modifiziert. Sollte die Komponente vorher nicht in der Assembly gewesen sein, so wird durch diesen UpdateMode diese nicht der Assembly hinzugefügt. Die Assembly-Info wird immer aktualisiert um ggf. eine neue Version zu berücksichtigen.
Derzeit sind folgende Settings unterstützt:
TargetFrameworkVersion: hiermit kann angegeben werden, für welche Version des .NET-Frameworks die Assembly erzeugt werden soll. Bis einschließlich V10.00 wird, wenn nichts angegeben ist, die Assembly für die Version v4.8 erzeugt.
Wegen der Unterstützung von .NET Core wird ab R10.01 ein sog. SDK-style project erzeugt. Dieses Format unterstützt auch die Erstellung für mehrere .NET Versionen (Details). Nur wenn explizit TargetFrameworkVersion angegeben ist, wird das bisherige Format verwendet.
TargetFramework1): hiermit kann eine einzelne .NET Version (net4.8 oder net6.0-windows, etc.) angegeben werden, wofür die Assembly erzeugt werden soll.TargetFrameworks2): hiermit können (getrennt durch ein Semikolon) mehrere .NET Versionen angegeben werden, wofür die Assembly erzeugt werden soll. Da das Semikolon auch als Trennzeichen für einzelne Settings verwendet wird, muss der Wert zwischen Anführungszeichen angegeben werden, e.g. TargetFrameworks=„net4.8;net6.0-windows“.
Der angegebene Wert für TargetFrameworkVersion, TargetFramework bzw. TargetFrameworks (ohne Anführungszeichen) wird direkt in die generierte Projektdatei übernommen, und nicht auf Gültigkeit geprüft. Wenn keines der drei Settings angegeben ist, wird TargetFramework=net4.8 angenommen.
CTV3): Wenn für CTV der Wert 1 angegeben ist, wird CTV-Unterstützung in die Assembly generiert; damit ist es möglich, Schriftgutvariablen (SGPV) abzufragen und zu bestücken. Wenn bei den Objekten explizit Schriftgut angegeben ist, wird CTV automatisch gesetzt.AssemblyInfo5): Wenn dieses Setting explizit auf false gesetzt wird, wird keine AssemblyInfo.cs im Verzeichnis Properties generiert oder überschrieben. Dies ist dazu gedacht, dass man eine eigene AssemblyInfo.cs mit detaillierten Angaben anlegen kann.internal6): wenn dieses Setting explizit auf true gesetzt wird, werden alle top-level Klassen der Assembly nicht als public sondern als internal generiert. Dies ist dazu gedacht, dass man mit friend Anweisungen in der AssemblyInfo.cs festlegen kann, welche Assemblies überhaupt diese generierte Base-Assembly benutzen dürfen.
Mit den Objektangaben wird spezifiziert, für welche Objekte passendes .NET-Coding in die Assembly erzeugt werden soll. Das Szenario ba-net kennt derzeit Generatoren für
DDRS oder abgeleitet (DRSE, DRST) sindMODL abgeleitet sindDSTO abgeleitet sindWenn keine expliziten Objekte angegeben werden, werden alle derzeit von ExpEdge unterstützten Objekte für die spezifizierte Anwendung in die Assembly erzeugt.
Hier folgt eine Auflistung der Optionen die bei eine Komponente angegeben werden können.
Wenn eine DV-KOMPONENTE verwendet wird, können diese in Rochade als Verweiszusatzinformation mit den Namen ExpEdge-Optionen: angegeben werden:
->DV_MODUL VVS-REST-API (ExpEdge-Optionen: web=1) ->DV_MODUL AF-VVS-REST-TEST
Der Generator für Schlüsseltabellen kennt derzeit die Option const, die den Wert true oder false (Default) haben kann, und die Option constlim, die einen numerischen Wert (Default: 4096) haben kann. Wenn zu einer Schlüsseltabellenkomponente die Option const=true angegeben wurde, wird der Code für das Laden der Schlüsseltabelle derart gestaltet, dass der Inhalt der Schlüsseltabelle in der generierten Assembly erzeugt wird, und somit nicht zur Laufzeit (versionsabhängig) aus Ressourcen-DLLs oder Datenbanken geladen wird10). Wenn dabei der für die Initialisierung benötigte Speicherplatz kleiner oder gleich der Angabe constlim ist, werden die Einträge als sog. Array-Initializer statisch erzeugt. Ansonsten wird eine (statische, damit versionsübergreifende) Ressource in der generierten Assembly erzeugt, aus der die Einträge zur Laufzeit deserialisiert werden. Diese Deserialisierung findet gegenüber dem Laden aus den herkömmlichen (dynamischen, versionsspezifischen) Ressourcen-DLLs mit einem anderen Datenformat und deutlich schneller statt.
Symbolische Konstanten werden für Schlüsseltabellen erzeugt, für die entweder in TablEdge, vgl. hier) ein Feld als Namensspalte festgelegt wurde, oder die Option SimpleConstWith angegeben wurde.
Der Generator für Schlüsseltabellen kennt die Option SimpleConstWith, mit der ein Feld aus der Schlüsseltabelle angegeben werden kann, dessen Inhalt als Bezeichner für die Generierung von symbolischen Konstanten für den Schlüsselwert der Tabelle benutzt werden soll. Diese Angabe überschreibt eine ggf. in TablEdge getroffene Feldauswahl. Der Wert der Konstanten ist i.d.R. der (einzige) Schlüssel der Tabelle, es sei denn es wurde in TablEdge eine andere Wertespalte festgelegt.
Zur Verdeutlichung wird hier eine Tabelle Zahlweise benutzt. Die Tabelle besitzt eine Schlüsselspalte KENN-ZW und u.a. eine Wertspalte KENN-ZW-BZ. Hier die vollständige Tabelle:
| KENN-ZW | KENN-ZW-BZ | KENN-ZW-S-BZ | KENN-ZW-L-BZ | RVK-ZW-DEMRW-KZ |
|---|---|---|---|---|
| 0 | Einmalbeitrag | einmalig | Einmalbeitrag | N |
| 1 | jährlich | jährlich | Jährlich | N |
| 2 | halbjährlich | halbjährlich | Halbjährlich | N |
| 4 | vierteljährlich | vierteljährlich | Vierteljährlich | N |
| 12 | monatlich | monatlich | Monatlich | N |
| 99 | irrelevant | irrelevant | irrelevant | J |
Durch die Spezifikation der zu generierende Schlüsseltabelle als levert.drse.zahlweise:SimpleConstWith="KENN-ZW-BZ" würden folgende Konstanten erzeugt werden:
public static class Zahlweise { public const UInt16 Einmalbeitrag = 0; public const UInt16 Jährlich = 1; public const UInt16 Halbjährlich = 2; public const UInt16 Vierteljährlich = 4; public const UInt16 Monatlich = 12; public const UInt16 Irrelevant = 99; }
Die Klasse für die Konstanten wird im <Rootnamespace>.Const.<Anwendung> erzeugt. Bei entsprechender using-Anweisung könnte die Benutzung also wie folgt aussehen:
this.Data.Xmusteu.KennZw = Zahlweise.Jährlich;
Folgende Voraussetzungen müssen gegeben sein (und werden bei der Generierung geprüft und ggf. gemeldet):
Mit der Option usedomain kann die standardmäßige Interpretation und Nutzung der Domänenangaben unterdrückt werden. Die Option kann bei Datenstrukturen und bei Schlüsseltabellen gesetzt werden.
Mit der Option useinterface kann die standardmäßige Interpretation und Nutzung der Interfaceangaben unterdrückt werden. Die Option kann bei Datenstrukturen und bei Schlüsseltabellen gesetzt werden.
Falls sich durch die Erzeugung C#-typischer Namen aus dem Modulnamen innerhalb einer Assembly Namensgleichheiten ergeben (z.B. Modulnamen AF-NFUN-CHECK1 und AF-NFUN-CHECK-1, ergibt beides AfNfunCheck1), werden durch den Generator eindeutige Klassennamen erzeugt, indem der Modulkurzname hinzugefügt wird (z.B. AfNfunCheck1Afc1, AfNfunCheck1Afx1). Um dies zu vermeiden, kann der Klassenname für ein Modul als Option angegeben werden, z.B. MYAPP.NFUN.AF-NFUN-CHECK1:classname=AfNfunCheck1A); 11)
Mit der Option web können für ein Modul spezifische Webfunktionalitäten freigeschaltet (true) bzw. unterbunden (false) werden12). Der Standardwert wird durch das Setting web vorgegeben.
Momentan betrifft das nur die Methode UseHttpContext für NTRY Module.
Kommandozeile, um für alle derzeit von ExpEdge unterstützten Objekte der Anwendung LEFIRM dedizierte Klassen in einer Assembly zu erzeugen:
TeamWiSE.ExpEdge -gen ba-net -lo c:\temp\expedge.log -a Lefirm
Das Ergebnis ist eine Assembly mit dem Namen Al.Lefirm, in der für alle unterstützten Objekttypen der Anwendung LEFIRM dedizierte .NET-Klassen vorhanden sind. Sowohl das Firmenkürzel als auch die zu nutzende Versionsangabe werden aus den Anwendungseinstellungen für LEFIRM aus der Registry gelesen.
Kommandozeile, um alle Schlüsseltabellen der Anwendung Levert in eine dedizierte Assembly mit vorbestückten Einträgen zu erzeugen:
TeamWiSE.ExpEdge -gen ba-net -lo c:\temp\expedge.log -i 066 -c AL -a Levert Levert.Ddrs.*:const=true,constlim=1024
Das Ergebnis ist eine Assembly mit dem Namen Al.Levert, in der alle Schlüsseltabellen der Anwendung LEVERT vorhanden sind, und bei der die Einträge der jeweiligen Tabellen in die Assembly übernommen wurden.
Oder eine Kommandozeile, um für alle bekannten Schlüsseltabellen eine dedizierte Assembly mit dynamischem Laden aus Datenbank oder Ressourcen-DLL zu erzeugen:
TeamWiSE.ExpEdge -gen ba-net -lo c:\temp\expedge.log -i 067 -c AL -a Zentko -n Al.Reftab *.Ddrs.*:const=false
Das Ergebnis ist eine Assembly mit dem Namen Al.Reftab in das für Zentko konfigurierte Verzeichnis für ASSY-Bausteine, in der alle bekannten Schlüsseltabellen aller registrierten Anwendungen vorhanden sind, und bei der die Einträge der jeweiligen Tabellen zur Laufzeit gemäß Einstellungen in der Registry aus Datenbanken und/oder Ressourcen-DLLs geladen werden.