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 generierende 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, welchen Namen 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 erstellende 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, 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.
TargetFramework
1): hiermit kann eine einzelne .NET Version (net4.8 oder net6.0-windows, etc.) angegeben werden, wofür die Assembly erzeugt werden soll.TargetFrameworks
2): 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.
CTV
3): 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.AssemblyInfo
4): 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.internal
5): 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
oder abgeleitet sindDSTO
oder abgeleitet sindWenn keine expliziten Objekte angegeben werden, werden alle derzeit von ExpEdge unterstützten Objekte für die spezifizierte Anwendung in die Assembly erzeugt.
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 wird8). Wenn dabei der für die Initialisierung benötigter 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 dann zur Laufzeit deserialisiert werden. Diese Deserialisierung findet gegenüber das 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
); 9)
Beispiel 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, bei der die Einträge der jeweiligen Tabellen in der Assembly übernommen wurden.
Oder eine Kommandozeile um für alle bekannte Schlüsseltabellen eine dedizierte Assembly mit dynamischen 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, bei der die Einträge der jeweiligen Tabellen zur Laufzeit gemäß Einstellungen in der Registry aus Datenbanken und/oder Ressourcen-DLLs geladen werden.