Von VBA zu VB.NET

Christoph Spielmann, Düsseldorf

Die Entwicklung von Anwendungen auf der .NET-Plattform gewinnt immer mehr an Bedeutung. Auch für Access-Entwickler stellt sich daher die Frage, ob bestimmte Anwendungen nicht besser mit .NET als mit Access entwickelt werden sollten. Dies trifft insbesondere auf moderne Anwendungen zu, die beispielsweise per Web-Service mit anderen Systemen kommunizieren, auf unterschiedliche Datenbank-Server zugreifen und das Benutzer-Interface im Web präsentieren. In diesem Artikel stellen wir Ihnen die .NET-Plattform genauer vor und zeigen Ihnen, wie Sie als VBA-Programmierer möglichst einfach auf VB.NET umsteigen können.

Wenn Sie eventuell schon einmal innerhalb von Access mit ActiveX-Steuerelementen gearbeitet haben, wurden Sie sicherlich mit Problemen bei der Weitergabe Ihrer Anwendung konfrontiert. Zum einen ist es erforderlich, dass der Ziel-PC das Microsoft-Office-Paket oder Access in der passenden Version installiert hat. Sollte dies nicht der Fall sein, bleibt Ihnen nur der Erwerb der Entwickler-Version von Access, die auch eine Laufzeitumgebung enthält.

Zudem ist es erforderlich, dass der Ziel-Rechner ebenfalls die bei der Entwicklung verwendeten ActiveX-Steuerelemente enthält. Da diese – anders als bei einer Access-Datenbankdatei – nicht einfach auf den Ziel-Rechner kopiert, sondern vorschriftsmäßig installiert und in der Registry eingetragen werden müssen, ist die Erstellung eines Setup-Programms erforderlich. Dies verursacht natürlich zusätzlichen Aufwand und bringt auch wieder Probleme mit sich, falls die ActiveX-Controls bereits auf dem Ziel-Rechner vorhanden sind, aber eine andere Versionsnummer haben. Sollte die vorhandene Version kleiner als die von Ihnen benötigte sein, funktioniert Ihre Anwendung eventuell nicht richtig. Wenn Sie die Version dagegen durch eine neuere ersetzen, könnten damit bereits vorhandene Anwendungen auf dem Ziel-Rechner unbrauchbar werden, da sie eine spezielle Version voraussetzen. Diese Problematik wird allgemein auch als “DLL-Hölle” bezeichnet. Sie führt dazu, dass viele Access-Entwickler komplett auf den Einsatz von Komponenten verzichten, sodass sie lediglich eine einfache MDB-Datei weitergeben müssen. Sie nehmen hierbei oft in Kauf, dass sie Funktionen, die von Komponenten zur Verfügung gestellt werden könnten, lieber in VBA nachprogrammieren, da dies das geringere übel bedeutet.

Alle beschriebenen Einschränkungen haben ihren Ursprung in dem Komponentenmodell “COM” (Component Object Model) von Windows. Dies ist Basis aller klassischen Anwendungen aus dem Hause Microsoft wie zum Beispiel Word, Excel, Outlook oder Access.

Microsoft hat sich die Aufgabe gestellt, das komplette COM-Objektmodell durch ein neues Komponentenmodell zu ersetzen. Herausgekommen ist nach fast zehn Jahren Forschungs- und Entwicklungsarbeit die .NET-Plattform.

Das Besondere an der .NET-Plattform ist, dass sie in weiten Zügen unabhängig vom Betriebssystem und der darunter liegenden Hardware ist. Lediglich einige Kernbereiche nutzen Betriebssystemfunktionen. Dazu gehören beispielsweise der Zugriff auf das Dateisystem, die Kommunikation über das Netzwerk sowie die Darstellung der Benutzeroberfläche von Windows-Anwendungen.

Tatsächlich ist es so, dass ein Tochterunternehmen der Firma Novell bereits eine Version des .NET-Frameworks für Linux entwickelt hat. Ziel des Projekts “Mono” ist es, dass Anwendungen zwischen Linux und Windows ohne Neukompilierung ausgetauscht werden können.

Damit dies funktioniert, besetzt das .NET-Framework ein Modul namens “Common Language Runtime”, kurz CLR. Die CLR besitzt die Fähigkeit, einen Programmcode kurz vor der Ausführung in Anweisungen für das jeweilige Betriebssystem zu übersetzen. Die übersetzung wird auch als “Just In Time”-Kompilierung (kurz JIT) bezeichnet. Hierbei kann der Compiler den Programmcode zum Beispiel auf Ausführungsgeschwindigkeit oder auf geringen Platzbedarf optimieren. Wenn Sie also auf Ihrem PC etwa Word und Access gestartet haben, also wenig Hauptspeicher zur Verfügung steht, kann die CLR eine neu gestartete Anwendung möglichst Platz sparend kompilieren.

Das “Jitten” spielt auch beim Komponentenmodell eine wesentliche Rolle. Kurz vor dem Start prüft .NET, welche Komponenten von der Anwendung benötigt werden und ob diese in passenden Versionen zur Verfügung stehen. Sollte dies der Fall sein, wird die Anwendung kompiliert und fest mit den Komponenten verknüpft.

Dies benötigt zwar etwas Zeit beim Start der Anwendung, garantiert jedoch eine hohe Ausführungsgeschwindigkeit. Wird die Anwendung beendet und neu gestartet, beginnt der Vorgang von Neuem. Sollten nun neuere Komponenten zur Verfügung stehen, werden diese natürlich beim Neustart berücksichtigt.

Die bereits angesprochenen Komponenten werden unter .NET als “Assemblies” bezeichnet. Hierbei handelt es sich um Dateien, die aus zwei wesentlichen Bereichen bestehen: Dem Manifest und dem eigentlichen Programmcode. Das Manifest enthält hierbei Informationen zu dem Assembly. Dazu gehören etwa die Versionsnummer, die Namen der enthaltenen Klassen und deren Mitglieder sowie Text- und Grafik-Ressourcen. Jedes Assembly beschreibt sich selbst also möglichst gut, damit es von anderen Assemblies verwendet werden kann.

Assemblies haben in der Regel die Dateiendung DLL, obwohl sie nichts mehr mit den klassischen DLLs aus der COM-Welt zu tun haben. Ausnahme bilden direkt ausführbare Programme, die die Dateiendung EXE haben. .NET-EXE-Dateien enthalten im Kopf einen Boot-Bereich. Dieser teilt dem Betriebssystem mit, dass die EXE-Datei nicht auf herkömmlichem Wege gestartet, sondern an die CLR weitergeleitet werden soll. Diese nimmt dann den Start vor.

Vorher prüft sie noch die Herkunft des Assemblies und aktiviert entsprechende Sicherheitsfunktionen. Beispielsweise haben Assemblies, die aus dem Internet stammen, standardmäßig nur sehr wenig Rechte. Sie dürfen nicht auf das Dateisystem oder die Registry zugreifen, was die Ausbreitung von .NET-Viren zusammen mit den anderen Sicherheitsfunktionen von .NET nahezu unmöglich macht.

Wie bereits erwähnt, enthalten Assemblies neben dem beschreibenden Manifest auch den eigentlichen Programmcode; dieser liegt jedoch nicht in einer Hochsprache vor, sondern in einer Zwischen-Sprache. Diese trägt den Namen “Intermediate Language” – kurz “IL”.

Diese Sprache kann sehr einfach in Ausführungsanweisungen für den Prozessor übersetzt werden, was vom JIT-Compiler erledigt wird und eine hohe Performance garantiert.

Die Sprache ist daher sehr hardwarenah, was für den normalen Programmierer wenig Komfort bedeutet. Ein Beispiel finden Sie in Abb. 1.

Abb. 1: Beispiel für IL-Code

Praxis-Tipp

Wenn Sie selbst einmal einen Blick auf den IL-Code eines Assemblies werfen möchten, verwenden Sie das Tool ILDASM.EXE (s. Abb. 2), das zum Lieferumfang des .NET-SDKs gehört. Sie finden es im BIN-Ordner. Mit dem Menüpunkt File/Open können Sie ein beliebiges Assembly öffnen und das Manifest begutachten. Bei einem Klick auf einen Klassen-Member wird der IL-Code angezeigt.

Zur Vereinfachung der IL kommen Hochsprachen wie C# oder VB.NET ins Spiel. Ein mit diesen Sprachen erstellter Programm-Code wird mit Hilfe eines Kompilers zunächst in die IL übersetzt und zusammen mit dem Manifest in ein Assembly gepackt.

Dieses Assembly kann schließlich vom JIT-Kompiler in Maschinen-Code übersetzt und ausgeführt werden.

Andere Anbieter wie etwa Borland stellen ebenfalls Kompiler zur Verfügung, die beispielsweise die Programmiersprache “Delphi” in die IL übersetzen.

Da dies relativ einfach ist, gibt es inzwischen sehr viele unterschiedliche Sprachen für die .NET-Plattform. Die übersetzung der Hochsprache in die IL findet auf dem PC des Entwicklers statt, sodass dieser den Quellcode seiner Anwendung nicht weitergeben muss. Auf diese Weise kann er sein geistiges Eigentum schützen.

Hierbei gibt es jedoch eine Einschränkung: Microsoft wollte das Komponentenmodell möglichst effizient gestalten.

Abb. 2: Der Disassembly ILDASM

Zu diesem Zweck war es erforderlich, sehr viele Informationen über die Komponente im Manifest unterzubringen. Dazu zählen beispielsweise auch Namen von Klassen, Prozeduren und Eigenschaften.

Zusammen mit dem IL-Code ist es relativ einfach möglich, den originalen Quelltext zu rekonstruieren. Hierbei fehlen zwar einige Elemente wie etwa die Namen der lokalen Variablen; die Arbeitsweise des Quellcodes lässt sich jedoch gut nachvollziehen. Wenn Ihr Quellcode also zum Beispiel schützenswerte Algorithmen enthält, sollten Sie hierauf achten.

Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...

Workplace

Jahresabonnement TestzugangOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar