Wie erstelle, speichere und nutze ich in VB.NET 2003 eine DLL im Projekt?

**In VB.NET 2003 erstellst du eine DLL als *Class Library*, kompilierst sie zu einer `.dll` und bindest sie im Hauptprojekt per *Projektverweis* oder *Dateiverweis* ein. Entscheidend ist: Nicht die DLL „manuell speichern“, sondern das Bibliotheksprojekt bauen und dann die erzeugte Assembly referenzieren.** ([learn.microsoft.com](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/dd874511%28v%3Dvs.85%29)) ## DLL erstellen In Visual Studio .NET 2003 legst du **kein normales Windows- oder Konsolenprojekt**, sondern ein **Class Library**-Projekt an. Genau daraus erzeugt der Compiler eine .NET-Assembly als DLL. ([learn.microsoft.com](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/dd874511%28v%3Dvs.85%29)) Beispiel für eine einfache Klasse in der DLL: ```vb Namespace MeineBibliothek Public Class Rechner Public Function Addiere(ByVal a As Integer, ByVal b As Integer) As Integer Return a + b End Function End Class End Namespace ``` Wichtig ist `Public`: Wenn Klasse oder Methode nicht öffentlich sind, kannst du sie im anderen Projekt nicht verwenden. Das ist einer der häufigsten Fehler bei alten VB.NET-2003-Projekten. ## DLL speichern und erzeugen Die DLL entsteht beim **Build** des Class-Library-Projekts automatisch. Der Dateiname richtet sich normalerweise nach dem Projektnamen; die Ausgabe landet im Projektordner unter **bin\Debug** oder **bin\Release**. Assemblies werden beim Build mit ihrem Namen und ihren Metadaten erzeugt; genau das ist das normale .NET-Modell für Bibliotheken. ([learn.microsoft.com](https://learn.microsoft.com/en-us/archive/msdn-magazine/2003/august/naming-and-building-assemblies-in-visual-basic-net)) Praktisch heißt das: - Projekt anlegen - Klasse schreiben - **Build** ausführen - danach liegt z. B. `MeineBibliothek.dll` im Ausgabeordner Der typische Denkfehler ist, eine DLL wie eine normale Datei „extra abspeichern“ zu wollen. Das ist nicht nötig; sie wird kompiliert, nicht separat exportiert. ## DLL im Hauptprojekt verwenden Am saubersten ist ein **Projektverweis**, wenn DLL und Hauptprogramm in derselben Solution liegen. Visual Studio verwaltet dann Pfad und Build-Reihenfolge automatisch. Ein Verweis ist genau der Mechanismus, mit dem Visual Studio Assemblies im Projekt bekannt macht. ([learn.microsoft.com](https://learn.microsoft.com/en-us/visualstudio/ide/managing-references-in-a-project?view=vs-2022)) Vorgehen in VS .NET 2003 sinngemäß: 1. Hauptprojekt öffnen 2. **Add Reference** / **Verweis hinzufügen** 3. Entweder: - das DLL-Projekt auswählen, oder - die bereits erzeugte `MeineBibliothek.dll` auswählen 4. Verweis bestätigen Danach kannst du die Klasse direkt verwenden: ```vb Imports MeineBibliothek Module Modul1 Sub Main() Dim r As New Rechner() Dim ergebnis As Integer = r.Addiere(3, 4) MessageBox.Show(CStr(ergebnis)) End Sub End Module ``` Falls `Imports` fehlt, geht auch der vollqualifizierte Name: ```vb Dim r As New MeineBibliothek.Rechner() ``` ## Wichtiger Unterschied: Projektverweis vs. DLL-Dateiverweis **Projektverweis ist besser**, wenn du den Quellcode der DLL selbst besitzt. Dann wird bei Änderungen an der Bibliothek die DLL beim Build neu erzeugt, und dein Hauptprojekt nutzt automatisch die aktuelle Version. Bei einem reinen Dateiverweis passiert es leicht, dass du versehentlich eine alte DLL referenzierst. Genau dieser Versionsfehler kostet in VS 2003 oft mehr Zeit als das eigentliche Programmieren. ([learn.microsoft.com](https://learn.microsoft.com/en-us/visualstudio/ide/managing-references-in-a-project?view=vs-2022)) ## Typische Fehler in VB.NET 2003 - **Klasse nicht `Public`** → im Hauptprojekt unsichtbar - **Namespace verwechselt** → `Imports` zeigt auf den falschen Namen - **alte DLL referenziert** → Änderungen erscheinen nicht im Hauptprogramm - **DLL nur kopiert statt referenziert** → Build wird unzuverlässig - **Ausgabeordner verwechselt** → Debug- und Release-DLL sind nicht dieselbe Datei Der wichtigste Praxistipp: Wenn die DLL zu deinem eigenen Projekt gehört, packe **beide Projekte in eine Solution** und arbeite mit **Projektverweisen**, nicht mit manuell herumkopierten DLL-Dateien. ## Kurzform - **DLL erstellen:** neues **Class Library**-Projekt - **Code schreiben:** öffentliche Klassen/Methoden - **DLL erzeugen:** Projekt **Build** - **DLL nutzen:** im Hauptprojekt **Verweis hinzufügen** - **verwenden:** per `Imports` oder vollqualifiziertem Klassennamen Damit ist die DLL in VB.NET 2003 nicht nur „eingebunden“, sondern sauber wartbar.