Manfred Hoffbauer, Düsseldorf
Das Microsoft.NET Framework hält mit über 4.000 wesentlich mehr Klassen bereit als Microsoft Access. Darunter befinden sich auch zahlreiche Klassen, bei denen dem Access-Entwickler das Wasser im Munde zusammenläuft. Der folgende Beitrag beschreibt ein paar Tricks, mit denen Sie eine .NET-Klasse als COM-Komponente kompilieren und mit Access benutzen können.
Ein mit Microsoft .NET erstelltes Programm kann prinzipiell nur innerhalb des .NET-Frameworks ausgeführt werden. Demzufolge können Sie auch die mit .NET programmierten COM-Komponenten auf PCs ausführen, auf denen das .NET-Framwork installiert ist. Außerdem benötigen Sie einige Hilfsprogramme, die im Microsoft Visual Studio.NET und im Microsoft NET-Framework SDK enthalten sind. Als Programmeditor setzen wir SharpDevelop ein. Alle benötigten Komponenten können Sie kostenlos aus dem Internet laden und installieren.
Hinweis
Eine Anleitung zur Installation und zur Anwendung der .NET-Entwicklungsumgebung SharpDevelop finden Sie im Beitrag .NET-Programmierung mit SharpDevelop in der vorliegenden Ausgabe von Access im Unternehmen.
Vom Quellcode zum COM-Server
Das Component Object Model ist als weitgehend standardisierte Beschreibung für die Kommunikation zwischen Anwendungen unter Windows recht weit verbreitet.
Viele Windows-Programme können COM-Komponenten unabhängig davon benutzen, mit welcher Programmiersprache sie erstellt wurden. Beispiele sind Microsoft Access, Microsoft C++, Microsoft Excel und Microsoft Visual Basic. Wenn eine Anwendung eine COM-Komponente benutzt, fungiert die Anwendung als COM-Client und die Komponente als COM-Server.
Bei der Verwendung eines .NET-Programms mit Microsoft Access ist die .NET-Komponente der COM-Server und die Microsoft Access-Anwendung der COM-Client. Dieser Weg ist für Sie als Access-Programmierer zunächst der nahe liegende. Dank der COM-Schnittstelle können Sie Ihre Hauptanwendung weiterhin mit Microsoft Access entwickeln und .NET-Programmcode nur sporadisch per COM einfließen lassen.
Wenn Sie später hauptsächlich mit .NET entwickeln sollten, dann wird Sie vielleicht schon jetzt beruhigen, dass der umgekehrte Weg ebenfalls möglich ist: Ein .NET-Programm kann bestehende COM-Komponenten als so genannten unsicheren Code verwenden. Diese Verfahrensweise benötigen Sie, um mit .NET auf Microsoft Excel und Microsoft Word zuzugreifen.
Ein erstes Testprogramm soll zunächst die verschiedenen Schritte vom Quellcode zum COM-Server aufzeigen. Um wirklich nur die erforderlichen Schritte zu zeigen und etwaige Programmierfehler weitgehend auszuschließen, soll das Programm selbst möglichst einfach gehalten werden. Später erhält die Komponente weitere Klassen aus dem .NET-Framework. Dabei erhalten Sie unter anderem eine Klasse, mit der sich Zeichenketten ver- und entschlüsseln lassen.
Bild 1: Mit diesem Dialog legen Sie eine neue Klassenbibliothek an.
Programm eingeben
Zur Eingabe des ersten Testprogramms starten Sie den kostenlosen Programmeditor SharpDevelop. Gehen Sie dann wie folgt vor (siehe Bild 1):
SharpDevelop legt eine neue Klassenbibliothek an und fügt die leere Klasse NewClass hinzu. Aus Gründen der übersichtlichkeit sollten Sie der Klasse einen sprechenden Namen geben. Klicken Sie den Eintrag NewClass.vb im Projekt-Explorer mit der rechten Maustaste an und wählen Sie Umbenennen aus dem Kontextmenü. ändern Sie den Namen in DotNetTestClass.vb. Korrespondierend können Sie den Klassennamen im Quelltext ebenfalls anpassen. Fügen Sie außerdem den folgenden Programmcode ein:
Public Class DotNetTestClass
Public Sub New()
MyBase.New()
End Sub
Public Function EineZeichenkette() _ As String
EineZeichenkette = _ "http://www.trinidat.de"
End Function
End Class
Damit verfügen Sie über eine Funktion namens EineZeichenkette(), die eine Zeichenkette als Parameter zurückgibt. Mit der F8-Taste können Sie das Combine erstellen und erhalten im Verzeichnis C:\Daten\DotNetServerApp\DotNetServerApp\bin\Debug die Datei DotNetServerApp.dll. Diese Datei gilt es nun für eine Access-Anwendung verfügbar zu machen.
Nun könnte man auf die Idee kommen, die DLL über den Befehl Extras/Verweise und Durchsuchen in Access hinzuzufügen. Dies führt jedoch leider zu der Fehlermeldung, dass ein Verweis auf die angegebene Datei nicht hinzugefügt werden kann (siehe Bild 2). Die nächsten Abschnitte dieses Beitrags beschreiben die Schritte, mit denen Sie aus der DLL-Datei einen COM-Server machen.
Von der DLL zum COM-Server
Eine wichtige Voraussetzung für einen COM-Server ist das Vorhandensein eines Konstruktors, der ohne Argumente auskommt. Durch die Eingabe der New()-Prozedur ist diese Voraussetzung bereits erfüllt. Die Angabe von MyBase.New() ruft den Konstruktor der Basisklasse auf, was für unser Beispiel völlig ausreichend ist.
<Comclass(VonDotNet.ClassId, VonDotNet.InterfaceId, VonDotNet.EventsId)> _ Public Class DotNetTestClass
Quellcode 1
<Microsoft.Visualbasic.Comclass(DotNetTestClass.ClassId, DotNetTestClass.InterfaceId, DotNetTestClass.EventsId)> _ Public Class DotNetTestClass
Quellcode 2
#Region "COM GUIDs"
Public Const ClassId As String = "ce8c8909-1126-4694-bfdd-602528cae505"
Public Const InterfaceId As String = "b937860c-6670-4f1e-8028-31e5adacb18d"
Public Const EventsId As String = "ccd5da17-c538-4903-913e-3b7bcf6f7f71"
#End Region
Quellcode 3
Bild 2: Diese Fehlermeldung erhalten Sie beim Versuch, die DLL als Com-Server einzubinden.
Mit dem ComClass-Attribut kennzeichnen Sie die neue Klasse als COM-Server. Dies veranlasst den Compiler zu verschiedenen Aktionen, die für die Verwendung eines .NET-Programms als COM-Server erforderlich sind. Sie müssen das Attribut in spitzen Klammern vor Public Class DotNetTestClass setzen.
Alternativ können Sie es auch eine Zeile darüber positionieren und die beiden Zeilen mit dem Unterstrich verbinden (s. Quellcode 1).
Wenn Sie das Combine nun mit F8 erstellen, dann meldet .NET den Fehler, dass ComClass unbekannt sei. Der Grund hierfür besteht darin, dass ComClass im Namespace Microsoft.VisualBasic definiert ist. Aus diesem Grund müssen Sie den Namespace entweder importieren oder vor ComClass mit angeben (s. Quellcode 2).
Jede unter Windows registrierte COM-Komponente muss eindeutig über eine Guid identifizierbar sein. Aus diesem Grund müssen Sie mindestens die Guid für die ClassId im Quellcode angeben. Falls Ihr COM-Server Interfaces und Ereignisse verwendet, müssen Sie auch diese Guids angeben. Die Definition der Guids geschieht durch die Programmzeilen aus Quellcode 3.
Woher kommen die Guids
Es stellt sich natürlich die Frage, woher Sie gültige Guids bekommen können. Eine einfache Möglichkeit besteht darin, dass Sie mit SharpDevelop ein kleines Tool für diesen Zweck programmieren. Legen Sie dazu eine neue Combine mit dem Namen CreateGuid an. Wählen Sie VBNET als Kategorie und verwenden Sie die Schablone Windows-Anwendung.
SharpDevelop fügt Ihrer Combine automatisch das Formular MainForm.vb hinzu. Klicken Sie auf das Register Design, damit SharpDevelop die Entwurfsansicht des Formulars anzeigt(siehe Bild 3). Gehen Sie dann wie folgt vor:
Bild 3: In der Entwurfsansicht des Formulars können Sie Steuerelemente hinzufügen und deren Eigenschaften bearbeiten.
Mit einem Doppelklick auf den Button veranlassen Sie SharpDevelop, eine Ereignisprozedur für das Click-Ereignis des Buttons anzulegen und diese über AddHandler mit dem Click-Ereignis des Buttons zu verknüpfen. Falls Sie sich den vom Formulardesigner generierten Programmcode ansehen wollen, dann brauchen Sie nur einen Doppelklick auf die Region Windows Forms Designer generated code auszuführen.
Die Ereignisprozedur BtnCreateGuidClick ist ein echter Einzeiler. Mit der folgenden Anweisung veranlassen Sie .NET zur Anlage einer Guid. Diese Guid wird dem Steuerelement als Text zugewiesen:
me.txtGuid.text =
System.Guid.NewGuid.ToString
Durch das Betätigen der F5-Taste veranlassen Sie das Kompilieren und den Start des Programms. .Net zeigt ein Formular mit einer Schaltfläche an. Bei jedem Klick auf die Schaltfläche wird eine neue Guid generiert (siehe Bild 4).
Falls Sie das Programm häufiger benötigen, brauchen Sie jeweils nur die Datei CreateGuid.exe per Doppelklick zu starten. Bei Bedarf können Sie auch eine Verknüpfung zu dieser EXE-Datei auf dem Desktop ablegen.
Bild 4: Mit diesem Formular erhalten Sie neue Guids.
Das Programm ist nun so vollständig, dass Sie es mit F8 kompilieren können. Falls beim Kompilieren Fehler auftreten, zeigt SharpDevelop die Anzahl der Fehler an. Im unteren Teil des Fensters können Sie auf das Register Aufgaben klicken, um eine Liste der Fehler zu erhalten. Ein Doppelklick auf einen dieser Fehler markiert die entsprechende Stelle im Quellcode.
Wenn das Kompilieren fehlerfrei funktioniert, erhalten Sie erwartungsgemäß die Datei DotNetServerApp.dll. Leider lässt sich auch diese Datei mit Access nicht als Verweis hinzufügen. Bevor Sie den COM-Server wirklich benutzen können, müssen Sie ihn zuerst noch in Windows registrieren.
Einen starken Namen zuweisen
Eine DLL ist nur dann als COM-Server zu gebrauchen, wenn die Assembly einen starken Namen hat. In .NET ist eine Assembly eine abstrakte Zusammenfassung von Klassen und Projekten zu einer Einheit.
Es handelt sich dabei um die kleinste als eigenständiges Programm ausführbare Einheit. Ein einfaches Beispiel für eine minimale Assembly ist das weiter oben beschriebene Programm CreateGuid.exe.
Eine besondere Stärke von .NET ist das so genannte XCopy-Deployment. Das bedeutet sinngemäß, dass Sie, um sie von dort aus zu starten, die Bestandteile einer Anwendung (DLL-, EXE- und Ressourcen-Dateien) einfach nur in ein Verzeichnis zu kopieren brauchen. Wenn Sie das Programm CreateGuid.exe in ein anderes Verzeichnis kopieren, dann können Sie es von dort aus starten. Ein zusätzliches Installationsprogramm ist nicht erforderlich.
Dieses Verfahren ist in den meisten Fällen einfach zu handhaben und sinnvoll. Nicht geeignet ist das Verfahren für Programmbestandteile, die von vielen Anwendungen gleichzeitig benutzt werden sollen. Diese verwaltet .NET im so genannten Global Assembly Cache (kurz: GAC). Ein .NET-Programm, das als COM-Server fungieren soll, muss ebenfalls im GAC registriert werden. Dies ist nun aber leider nur mit solchen Programmen möglich, die über einen starken Namen (englisch: strong name) verfügen. Es gibt mehrere Verfahren zur Vergabe starker Namen. Das Beispiel verwendet das AssemblyKeyFile-Attribut. Mit ihm können Sie den Namen einer Datei angeben, die ein Schlüsselpaar für die Registrierung der Assembly im GAC enthält.
Die Anlage dieser Datei erfolgt mit dem Programm SN.EXE, das sowohl im Lieferumfang von Microsoft Visual Studio .NET als auch im Lieferumfang des Microsoft .NET Framework SDK enthalten ist. Wenn Sie nicht wissen, an welcher Stelle Sie das Programm finden können, sollten Sie einfach mit dem Windows-Explorer im Unterverzeichnis Programme danach suchen. Auf einem PC mit installiertem Visual Studio.NET lautet der Aufruf zur Anlage des Schlüsselpaares wie folgt:
"C:\Programme\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\sn.exe" -k DotNetServerApp.snk Pause
Sie finden die Batchdatei unter dem Namen SN.BAT in den Beispieldateien zu diesem Beitrag. Wenn Sie die Befehle direkt eingeben wollen, dann wählen Sie den Befehl Ausführen aus dem Start-Menü von Windows und geben Sie Command als Befehl ein.
Ja richtig, im Zeitalter von WLans und objektorientierter Programmierung geht“s wieder zurück zu den Wurzeln, also zum DOS-Prompt – Verzeihung: zum Windows-Befehlszeileninterpreter. Der beschriebene Aufruf von SN.EXE generiert die Datei DotNetServerApp.snk, die Sie als Schlüsseldatei in Ihre Combine einfügen sollten (siehe Bild 5). Es bietet sich an, die Datei in das gleiche Verzeichnis zu kopieren, in dem sich der Quellcode der Anwendung befindet.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo