hhcsbat ermöglicht den Einsatz von CSharp Scripten in Kommandoprozeduren.
Innerhalb des CSharp Scriptes muss es einen Namespace "Script", eine Klasse "Main" und eine Funktion "Run" geben. Diese wird als Startfunktion aufgerufen. Die weiteren Kommandozeilenparameter werden in einem Objectarray an die Startfunktion übergeben.
Als Script kann entweder ein vollständiger Dateiname eines CSharp-Scripts angegeben werden, oder ein Dateiname ohne Pfad und Endung. Es wird dann versucht ein entsprechendes Script mit der Endung ".hhcsbat" über die Path-Variable zu finden.
Um Scripte z. B. im Microsoft Developer Studio zu testen, kann ein entsprechendes Assembly erstellt werden. Wenn das Assembly im gleichen Verzeichnis wie das Script liegt, wird dieses zur Laufzeit verwendet, und das Script kann im Developer Studio ausgetestet werden. (Verwenden Sie das Programm "hhcsbat.exe" als Startapplikation!.
Steht kein Developer Studio zur Verfügung, können nur Message und Traceausgaben zum Testen verwendet werden. (Siehe Beispiel).
Als Basis eigener Scriptentwicklungen verwenden Sie am besten eine Kopie des Tools-Scripts "prc\testcsbat1.hhcsbat" in ihrem SOG ERP Projektverzeichnis.
hhcsbat Script [Parameter ...]
using System;
using SOG.Base;
using SOG.Base.Helper;
using SOG.Base.Exceptions;
namespace Script
{
/// <summary>
/// </summary>
public class Main : SOGScriptBase
{
public static int Run(object[] parms)
{
// Beispiel für eine einfache Ausgabe
WriteLine("Test 1 erfolgreich!");
// Beispiel für eine einfache Trace-Ausgabe
SOGTrc.Base()?.WriteLine( "Traceausgabe");
// Beispiel für eine einfache Protokollmeldung
WriteError("Einfache Fehlerausgabe");
return 0;
}
}
}
Weitere Beispiele finden Sie in Ihrem Projektverzeichnis unter prc\testcsbat*
Debugeinstellungen im Microsoft Developer Studio
Der Ablauf in diesem Abschnitt ist nicht zwingend erforderlich. Scripte funktionieren auch wenn sie nur den .NET Runtime installiert haben.
Haben Sie aber auch eine vollständige Microsoft CSharp Entwicklungsumgebung, so können Sie Scripte auch in dieser Umgebung entwickeln und testen.
Um Scripte im Developer Studio debuggen zu können, benötigen sie das Microsoft Developer Studio, z. B. die kostenfrei erhältliche Version "Community Edition" https://visualstudio.microsoft.com/de/vs/community/
Vorgehensweise:
Legen Sie ein neues Developer-Studio Projekt an.
Wählen Sie als Projekttyp "Klassenbibliothek (.NET Framework)".
In den Einstellungen des Projektes, wählen Sie auf dem Reiter "Debuggen" die Checkbox "Externes Programm starten".
Geben Sie als Namen des externen Programms "s:\vacos\bin\SOGERP.xxx\hhcsbat.EXE" => Setzen Sie hier den Namen ihres aktuelle bin\SOGERP.XXX-Verzeichnisses ein.
Unter Befehlszeilenargumente geben Sie den Namen des zu testenden Scripts, ggf. als vollständigen Pfad an.
Wählen Sie das korrekte Arbeitsverzeichnis.
Öffnen Sie die Script-Datei, und setzen Sie einen Break-Point.
Führen Sie das Programm nun über z. B. "F5" aus.
Debugging mit Änderungen OnTheFly
Die Microsoft Entwicklungsumgebung erlaubt auch die Veränderung der Quelldatei während einer Debug-Sitzung.
Diese Einstellungen sind zum Debuggen nicht notwendig, erlauben aber ein komfortableres Debugging.
Um diese Möglichkeit zu nutzen, sind einige weitere Voraussetzungen zu erfüllen:
Geben Sie als Referenzassembly Ihrer Klassenbibliothek die Assembly "SOG.Base.dll" aus dem aktuellen Projekt-bin-sogerp Verzeichnis hinzu.
Fügen Sie Ihr Script als ".cs" Datei Ihrer Klassenbibliothek hinzu.
Erweitern Sie das Script um die Zeilen:
// *ASM*D:/dev/hdldev/todev/test/tscript/bin/Debug/tscript.dll
// *REF*END*
Geben Sie hinter *ASM* den Debug-Ausgabenamen Ihrer Klassenbibliothek an. Achtung: Verwenden Sie hier "/" an Stelle von "\"
In den Projekteigenschaften, unter "Debugging", legen Sie in den Befehlszeilenargumente den Namen des zu testenden Scripts auf den Namen dieser neuen ".cs" Datei fest.
Nun kann das Script verändert werden, während die Ausführung läuft, wenn es sich z. B. auf einem Break-Point befindet.
Vergessen Sie nicht, die Änderungen die Sie an der Kopie Ihres Scriptes machen, später wieder in die Originaldatei zurück zu kopieren.
Vergessen Sie nicht, die "*ASM*" Zeile aus dem Original-Script wieder zu entfernen. Ansonsten macht es später den Eindruck, als wenn man das Script nicht mehr ändern könnte, da ja immer die fertig übersetzte Version aus dem angegebenen Assembly genutzt wird.
Zugriff auf weitere Referenzassemblies sowie Scripte in mehreren Quellen
Soll aus dem Script auf weitere externe Systemassemblies, oder benutzereigene Assemblies zugegriffen werden, oder ist für das Script mehr als eine CS-Quelldatei erforderlich, so kann diese durch folgende Syntax am Anfang des Scriptes definiert werden:
// *REF*:System.Windows.Forms.dll
// *REF*:System.dll
// *SRC*Form1.cs
// *REF*END*
In diesem Beispiel werden die Systemreferenzen "System.Windows.Forms.dll" sowie "System.dll" eingebunden, sowie zusätzlich die Quelldatei "Form1.cs" geladen.
Beispiel für die Angabe eines absoluten Pfades zu einem Referenzassembly:
// *REF*:"c:\Program Files (x86)\Dundas Software\Gauges\WinControlVS2008\Bin\DundasWinGauge.dll"
Achtung: In diesem Fall muss auf ALLEN Clients diese Assembly verfügbar sein!