Generierung von Assemblies

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.

Anwendung

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.

Version

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.

Company

Die Angabe Company wird für die Bildung des Namens der zu generierende Assembly benutzt.

Zielverzeichnis

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).

Name

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.

Projektdatei

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.

Root Namespace

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.

Es empfiehlt sich, für jede einzelne generierte Assembly eine eigene Namespace zu nutzen. Das Werkzeug ExpEdge ist darauf ausgerichtet, einen Satz an Informationen gezielt für einen bestimmten Baustein oder eine bestimmte Anwendung oder ein bestimmtes Problemgebiet zu erzeugen. Im Namespace sollte dann dieser Baustein, Anwendung oder Problemgebiet Eingang finden. Wenn in einem Prozess die gleiche Klasse mit der gleichen Namespace auftaucht, kann das zu schwer nachvollziehbaren Problemen führen. Im Zweifelsfall wäre es empfehlenswert, eine 1:1 Beziehung zwischen Namespace und physikalischem Namen der Assembly zu haben.

UpdateMode

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.

Settings

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.

  • 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.
  • AssemblyInfo4): 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.
  • internal5): 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.

Objektangaben

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

  • Schlüsseltabellen - Komponenten, die vom Typ DDRS oder abgeleitet (DRSE, DRST) sind
  • Bausteine - Komponenten, die vom Type MODL oder abgeleitet sind
  • Datenstrukturen - Komponenten, die vom Type DSTO oder abgeleitet sind
  • 6)CTV-Dokumente: Schriftgut, welches von den Typen CDOK oder SSTZ abgeleitet ist.
  • 7)Komponentenstruktur: Es werden alle Komponenten generiert, die in der Komponentenstruktur (Rochade: DV_KOMPONENTE) enthalten sind und generierbar sind, unter Berücksichtigung der Optionen, die für eine einzelne Komponente angegeben sind.

Wenn keine expliziten Objekte angegeben werden, werden alle derzeit von ExpEdge unterstützten Objekte für die spezifizierte Anwendung in die Assembly erzeugt.

Komponentenspezifische Optionen

Statische Inhalte

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

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):

  • die Schlüsseltabelle darf nur eine Schlüsselspalte besitzen, oder es wurde mit TablEdge eine Wertespalte selektiert.
  • die Schlüsseltabelle darf keine historisierte sein
  • das Bezeichnerfeld muss ein bekanntes Feld in der Schlüsseltabelle sein
  • das Bezeichnerfeld muss eine Zeichenfolge sein
  • die Werte im Bezeichnerfeld müssen eindeutig sein.
Man beachte, dass hierbei die übliche versionsspezifische Dynamik der TAA verloren geht. Wenn Bezeichner oder Schlüsselwerte sich ändern, wird das in den generierten Konstanten nicht berücksichtigt. Daher sollte diese Funktionalität wohlüberlegt eingesetzt werden.

Domänen

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.

Interfaces

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.

Module

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)

Beispiele

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.

1) , 2) , 4) , 5)
ab V10.01
3)
ab V9.11
6)
Ab 9.11
7)
Ab 9.06
8)
Die Nutzung dieser Option sollte wohlüberlegt sein, denn mit der statischen Generierungsvariante verzichtet man auf die durch die dynamische Variante gebotene Versionierung der Tabellen zur Laufzeit.
9)
V9.06
expedge:ba-net · Zuletzt geändert: 16.01.2024 16:22

Copyright © 1992-2024 TeamWiSE Gesellschaft für Softwaretechnik mbH         Adressen |  Kontakt |  AGB |  Datenschutzerklärung |  Impressum