Die Automatisierung von Office Anwendungen, gestaltet sich dank entsprechender Objektbibliotheken als recht einfaches Unterfangen. Zumindest solange, wie der Anwender die gleiche Office Version einsetzt, wie der Entwickler. Sind unterschiedliche Versionen im Spiel, kann es schon mal zu Unverträglichkeiten kommen, wenn man mit der Objektbibliothek und damit mit früher Bindung arbeitet.

Frühe Bindung (Early-Binding) bedeutet nichts weiter, als das man zur Entwicklung festlegt, mit welchen Schnittstellen Objektreferenzen arbeiten sollen, so dass der Compiler weiß, welche Eigenschaften und Methoden ein Objekt unterstützt:

Dim lWordApp As Word.Application

In der IDE kann man auf den Komfort der IntelliSense Unterstützung zurückgreifen und muss nicht das ganze Objektmodell auswendig kennen, um zu wissen, welches Objekt, welche Methoden und Eigenschaften bereitstellt.

Für die Anwendung bedeutet das einen Performancegewinn, da nicht bei jedem Zugriff das referenzierte Objekt abgefragt werden muss, ob es eine Eigenschaft oder Methode mit dem Namen "XY" bereitstellt. Stattdessen erfolgt der Zugriff über die in der Objektbibliothek hinterlegten Dispatcher IDs. Jede Eigenschaft oder Methode kann über diese eindeutige ID aufgerufen werden.

Wie bereits zu Beginn erwähnt, erkauft man sich diesen Komfort mit dem Risiko, dass die Anwendung Fehler produziert, sobald auf dem Zielrechner eine andere Office-Version installiert ist, als zur Entwicklung verwendet. Auch wenn die Office-Objektmodelle grundsätzlich aufwärtskompatibel gehalten sind.

Um dieses Risiko auszuschließen, bietet sich die späte Bindung (Late-Binding) an. Hierbei deklariert man alle betroffenen Objektvariablen als Object. Damit verzichtet man auf die IntelliSense Unterstützung und nimmt Performanceeinbußen hin. Die sind mithin weniger gravierend, als dass die Automatisierung von Office-Anwendungen ohnehin über out-of-process Servern abläuft, die als solches schon eine Performancebremse darstellen, da hier Daten über Prozessgrenzen hinaus ausgetauscht werden müssen.

Auf die Objektbibliothek selber muss man aber nicht verzichten. Dieser Verweis allein stellt kein Problem dar und liefert weiterhin die Konstanten/Enum-Mitglieder auf die man zwecks Lesbarkeit nicht verzichten sollte.

Wenn man aber schon den Verweis auf die Objektbibliothek im Projekt erhält, kann doch auch mit den vorhandenen Schnittstellen-Definitionen arbeiten und so die volle IntelliSense Unterstützung (Early-Binding) in der IDE nutzen. Auf dem Entwicklungsrechner ist die Welt ja meistens in Ordnung. Erst bei Veröffentlichung möchte man die späte Bindung nutzen.

Über bedingte Kompilierung, lässt sich beides hinreichend komfortabel miteinander vereinen. Die Compiler-Konstante LATEBOUND steuert dabei, welcher Teil des Codes kompiliert wird. Beispiel für die Word-Automatisierung:

#Const LATEBOUND = 0 '/1

[...]

#If LATEBOUND Then
Dim lWordApp		As Object
Dim lDocument	As Object
Dim lBookmark	As Object
#Else
Dim lWordApp		As Word.Application
Dim lDocument	As Word.Document
Dim lBookmark	As Word.Bookmark
#End If

Set lWordApp = CreateObject("Word.Application")
lWordApp.Visible = True
[...]

Die Konstante für bedingte Kompilierung LATEBOUND gilt in diesem Fall nur für das jeweilige Modul, wo sie definiert wurde und steuert beim Kompilieren (auch in der IDE), ob mit früher- oder später Bindung gearbeitet werden soll. Um beim Release mit später Bindung zu arbeiten, muss man vor dem Kompilieren den Wert "1" angeben.

Soll die Compiler-Konstante für das gesamte Projekt gültig sein, muss sie unter Projekt => Eigenschaften > Erstellen > 'Argumente für bedingte Kompilierung' angegeben werden.

Das schützt einen jedoch nicht davor, dass die Anwendung abstürzt, weil es bestimmte Methoden oder Eigenschaften unter früheren Office-Versionen noch nicht gegeben hat. Das sollte man vorher austesten bzw. es ist ratsam die bei der Entwicklung verwendete Office/Word Version auch als Minimum Voraussetzung für die Anwendung anzusetzen.