Implementierungstyp VSNET

Mit Hilfe des Implementierungstyps (ITyp) VSNET ist der Entwickler in der Lage, Bausteine, die als Klasse in einer Assembly (ITyp DLLCLR) oder als eigenständiger Prozess (ITyp EXECLR) mit einer .NET-kompatiblen Sprache implementiert werden, unter Kontrolle von Visual Studio auszuführen.

Die Infrastruktur überwacht hierbei Visual Studio und wartet, bis der Baustein sich registriert hat. Ab dem Punkt wird nur noch der Prozess überwacht, der den Register ausgeführt hat. Sobald der Unregister dann ausgeführt wird, wird auch die Überwachung dieses Prozesses eingestellt, und der Aufrufer wird durchgestartet.

Als Implementierungsspezifikation (ISpc) wird die Visual Studio Solution eingetragen, welche das Projekt für die Implementierung enthält:

Wird nur der Dateiname angegeben, also ohne Pfadangabe, wird der ComponentPath verwendet, um die Datei zu suchen, und um Visual Studio mit der gefundenen Solution Datei zu starten. Welche Version von Visual Studio gestartet wird, ist ersichtlich wenn im Windows Explorer für die Solution Datei in dem Kontextmenu unterhalb Öffnen mit den Eintrag Standardprogramm auswählen… angeklickt wird: Standardmäßig wird das Programm Microsoft Visual Studio Version Selector gestartet. Dieser erkennt an Hand des Inhalts¹⁾ der Solution Datei, welche Version von Visual Studio gestartet werden soll.

Die Infrastruktur prüft vorher, ob bereits eine Instanz von Visual Studio²⁾ läuft, die die Solution geladen hat. Wenn dies der Fall ist, wird diese Instanz von der Infrastruktur verwendet. Es wird eine Meldung eingeblendet, um auf diese Tatsache hinzuweisen:

Bausteine, die als eigenständiger Prozess (ITyp EXECLR) implementiert sind, können direkt in Visual Studio gestartet werden, indem bei den Projekteigenschaften auf dem Reiter Debug als Start Action Start Project ausgewählt wird: Eventuelle Parameter für das Programm können unter Command line arguments eingetragen werden.

Für Bausteine, die als Klasse in einer Assembly implementiert sind, wird ein Kopfprogramm benötigt. Dieser lädt das Assembly und kümmert sich um den Einstieg in der Klasse. Die Infrastruktur stellt hierfür einen Entrypoint DLLCLR_Invoke zur Verfügung, der diese Aufgabe übernimmt. Dieser Entrypoint befindet sich der DLL TeamWiSE.RuntimeCore.dll und wird über das Windows Utilityprogramm Rundll32.exe³⁾ aufgerufen:

Es ist nicht notwendig für die TeamWiSE.RuntimeCore.dll den kompletten Pfadnamen anzugeben, wenn dieser über die Umgebungsvariable PATH gefunden werden kann. Der Entrypoint DLLCLR_Invoke bekommt als Argument die Implementierungsspezifikation für den Baustein übergeben, wie diese für den Implementierungstyp DLLCLR eingetragen ist (z.B. ALVOC001.dll;AL.VO.VO_D_REQUEST_TO_CONTEXT;C001;S). Die spezifizierte Assembly wird über den ComponentPath gesucht, wobei der Entrypoint DLLCLR_Invoke diesen vorübergehend um das Working Directory⁴⁾ erweitert, damit eine Pfadangabe nicht benötigt wird⁵⁾.

DLLCLR_Invoke erkennt das Zielframework (.NET Framework, .NET Core) des Assemblies und lädt das entsprechende .NET Laufzeitsystem.

Wenn für die Implementierung generierte Basis-Assemblies verwendet werden, gibt es einige angepasste bzw. erweiterte Funktionalitäten in der Infrastrukur. Die Infrastruktur erkennt normalerweise an der Implementierungspezifikation, ob eine Funktionalität zur Verfügung stehen soll oder nicht. Dies ist bei dem Implmentierungstyp VSNET nicht möglich, da hier die Solution als Implementierungspezifikation eingetragen wird.

Damit diese Apassungen/Erweiterungen trotzdem auch beim Debuggen funktionieren, können neben der Solution auch Flags angebeben werden (<solution>;<flags>). Als Trennzeichen wird ein ; (Semikolon) verwendet. Wenn für die Implementierung generierte Basis-Assemblies verwendet werden, muss hier der Flag N eingetragen werden: