Letzte Änderung am 15. April 2023 by Christoph Jüngling
Im ersten Teil dieser kleinen Reihe habe ich einen kurzen Überblick über die Möglichkeiten der Fehlerbehandlung in VBA-Projekten gegeben. In meinem Fall sind das sehr oft Access-Projekte, aber grundsätzlich gilt das hier beschriebene auch für andere Applikationen, die “unter der Haube” mit VBA arbeiten. In diesem zweiten Teil will ich wieder einmal etwas mehr auf die Quellcodeverwaltung eingehen, denn da gibt es im Zusammenhang mit vbWatchDog (leider) etwas zu beachten.
In diesem Artikel
Problem
Wie schon zuvor erwähnt, ist vbWatchDog Lizenzsoftware. Alle Informationen darüber findet ihr auf der entsprechenden Seite der Homepage, das Thema dort heißt naheliegenderweise License & Download. Da ich in diesem Punkt selbst etwas unsicher war, habe ich mich zuvor mit dem Autor Wayne Phillips per eMail beraten. Wayne wies darauf hin, dass “our licence agreement only covers including the vbWatchdog components inside of your projects”. Damit ist das Problem für den Entwickler klar: Die Klassenmodule von vbWatchDog haben nichts in der Quellcodeverwaltung zu suchen, es sei denn, es handelt sich um ein Repository, an das außer mir selbst niemand heran kommt. Auch wenn alle Entwickler selbst über eine Lizenz verfügen oder sogar eine Firmenlizenz existiert, wäre es möglich, die Dateien z.B. in Git einzuchecken.
So etwas ist zwar technisch durchaus machbar, aber oft nicht gewollt. Denken wir nur an Teamarbeit oder daran, dass auch der Kunde Zugriff auf das ALM-System haben soll.
Aber wir haben einen Weg gefunden, der praktikabel ist und die Bedingungen der Lizenz erfüllt.
Lösung
Die Lösung besteht dabei aus mehreren Teilen. Ich beschreibe es hier mal wieder am Beispiel von Git, jedoch denke ich, dass im Grunde jede Versionsverwaltung einen vergleichbaren Mechanismus anbietet. Von Mercurial (Hg) und Subversion (Svn) weiß ich sicher, dass das der Fall ist.
Commit vermeiden
Zunächst geht es darum, zu vermeiden, dass die vbWatchDog-Klassenmodule in die Quellcodeverwaltung kommen. Das geht mit Git sehr einfach (wie ich bereits im ersten Teil beschrieben habe), indem ich in der Datei .gitignore
mindestens die ErrEx-Dateien aufführe. Am besten fügt ihr die Ignore-Datei zum Projekt hinzu, denn dann hat auch jeder Entwicklerkollege diese Einstellung zur Verfügung. Der Effekt ist, dass Git und auch dessen graphische Erweiterung TortoiseGit die dort aufgeführten Dateien gar nicht mehr für den Commit anbietet. Damit wäre der erste Teil erledigt.
Dateien bei Bedarf ergänzen
Allerdings entsteht nun ein Folgeproblem: Falls man die Access-Datenbank aus dem Sourcecode neu erzeugen muss oder will, dann fehlen diese Dateien zunächst. Das bedeutet, dass einerseits jeder Entwickler über eine Lizenz mit einer installierten Version von vbWatchDog verfügen muss, und andererseits nach dem Aufbauen der neuen Accdb-Datei im VB-Editor einmal den Befehl “Add vbWatchdog to this project” ausführen muss. Das ist sicher nicht schwierig, man muss halt nur daran denken. Damit ist auch Punkt zwei erledigt, jeder Entwickler kann damit arbeiten.
Continuous Integration
Bleibt noch der dritte Punkt, der endgültige “Build” für den Anwender. Hier kommt es natürlich stark darauf an, wie dies erfolgt. Wenn es ohnehin der Entwickler von Hand macht, dann geht einfach alles wie zuvor dargelegt. In meinem Fall versuche ich jedoch solche Schritte immer zu automatisieren. Dieses Prinzip habe ich in dem Beitrag Access-Datenbank aus VCS automatisch aufbauen bereits ausführlich beschrieben. (Der Artikel ist zwar schon fast 10 Jahre alt, aber das alles gilt auch heute immer noch.)
Allerdings bleibt jetzt noch eine Kleinigkeit zu tun, denn es fehlen ja nach dem Aufbau der Access-Datenbank noch die vbWatchDog-Dateien, ohne die unser Projekt nicht vollständig wäre. Also müssen wir dafür sorgen, dass diese Dateien nach dem “Checkout” der Versionsverwaltung und vor dem Aufbau der Accdb/e hinzugefügt werden müssen. Zu diesem Zweck müssen diese Dateien irgendwo auf dem Rechner (oder der virtuellen Maschine) verfügbar sein, auf dem der Build-Prozess läuft. Dabei ist darauf zu achten, dass das Datei- und Namensformat genau dem entspricht, was für den Aufbau der Accdb notwendig ist. Bei mir erfolgt dieser Build mit OASIS, daher heißen die Dateien z.B. “M_ErrEx.def”. Das Verzeichnis nenne ich einfach “C:\vbWatchDog-Files” (der Name ist beliebig, er muss nur im Script verwendet werden). Das ist natürlich nur eine einmalige Vorbereitung, die nur nach einem Update des vbWatchDogs erneut gemacht werden muss. Da diese Dateien ebenfalls auf meinem Rechner liegen, ist der Lizenz genüge getan.
Nun kommt der letzte Teil, das Script “build.cmd” wird einfach um einen Copy-Befehl erweitert. Nehmen wir an, das Frontend liegt im Projekt in einem Unterverzeichnis “app”, und darunter befinden sich alle von OASIS exportierten Dateien wiederum in “source”. Dann könnte das Script so aussehen:
@echo off
rem This batch file shall always live in the project's main folder!
pushd app
copy C:\vbWatchDog-Files %cd%\source
msaccess.exe /cmd OASIS#%cd%\MeineDatenbank.accdb
popd
Dieses Script muss natürlich vom Buildprozess automatisch aufgerufen werden, was ein CI/CD-System wie z.B. Jenkins in der Regel ohnehin tun müsste. Bevor dieses Script aufgerufen wird, hat Jenkins dafür gesorgt, dass aus dem Git-Repository alle Dateien in das Arbeitsverzeichnis ausgecheckt wurden. Dann kopiert der Copy-Befehl die vbWatchDog-Dateien hinzu und danach baut Access mit OASIS die Accdb/e auf.
Im Anschluss daran könnte ein Setup-Programm die fertige Datenbank verpacken und das Setup auf den Deploy-Server hochladen. Oder wer auch immer dies macht.
Fazit
Insgesamt haben wir also folgendes Konzept:
- ErrEx-Dateien per .gitignore-Datei für die Versionsverwaltung ignorieren
- vbWatchDog-Dateien nach jedem manuellen Build per Menübefehl zum Projekt hinzufügen
- vbWatchDog-Dateien während eines automatisierten Builds per Script zum Source-Verzeichnis hinzufügen
Damit sind die Bedingungen der Lizenz erfüllt, aber der Anwender erhält trotzdem eine vollständige und garantiert dem Stand der Versionsverwaltung entsprechende Applikation. Die Details sind natürlich stark vom eingesetzten Buildkonzept und -system abhängig, aber im Großen und Ganzen sollte das so machbar sein.
Nebenbei sei noch bemerkt, dass zusätzliche Aktionen wie in AccessMake beschrieben jederzeit ergänzt werden können. Das hat aber mit vbWatchDog nichts mehr zu tun und hätte diesen Artikel nur unnötig aufgebläht.
Weitere Artikel zum Thema “vbWatchDog” findet ihr über das Tag vbWatchDog. Irgendwie naheliegend, oder? :-)
3 Kommentare
Die Vorlagen-DB wird als Template verwendet.
Von Bibliothekenvarianten sind wir komplett abgekommen. Es gibt zu viele verschiedene Dienstleister bei den Kunden, vom ambitionierten Mitarbeitern bis hin zu externen Firmen. Also gibt es nur eine “Datei” und keine unnötigen Diskussionen ;-)
Das ist ein weiterer klarer Vorteil des Watchdog!
Auch wird dem normalen Anwender im Fehlerdialog nur ein Minimum an Infos und Buttons gezeigt. Der hinzugerufene “Experte” soll dann bitte alle Details einblenden. Das hat sehr zur Akzeptanz beigetragen.
Autor
Hi Hannes, danke für den Hinweis! Die Vorlagen-DB ist sowas wie eine Bibliothek, die per Verweis eingebunden ist? Damit wollte ich mich eh schon lange mal beschäftigen. Oder ist das ein Template, in das dann der Quellcode hineingeladen wird?
Wir machen es wie folgt:
– Grundlegende Dinge liegen in einer “Vorlagen-DB”, sowie alle Verweise in der gewünschten Version. Natürlich auch der Watchdog.
– Mit dieser DB wird dann die Application aufgebaut.
Das oben beschriebene Problem haben wir also nicht. Auch weil wir (historisch bedingt) eine selbstgebaute Quellverwaltung verwenden.
Gruss, Hannes