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
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
