PDF Drucken E-Mail

COM-Add-Ins installieren

COM-Add-Ins sind Zusatzkomponenten, mit denen man Office-Anwendungen und die VBA-Entwicklungsumgebung erweitern kann. Programmiert werden sie grundsätzlich als ActiveX-Komponenten - daher rührt auch das "COM" (Component Object Model) im Namen  - und normalerweise kommen sie als DLLs daher.

Gegenüber einer normalen ActiveX-DLL gibt es zwei Unterschiede, die aus ihr ein Add-In machen:

  1. Die öffentliche Hauptklasse der Komponente hat eine spezielle Schnittstelle implementiert, die sich IDExtensibility2 nennt. Über diese COM-Schnittstelle kommuniziert die Wirtsanwendung mit der Komponente. Ohne diese Schnittstelle ignoriert Office oder VBA das Add-In.
  2. Die ActiveX-DLL muss nicht nur ihre Klassen im System registrieren, wie jede andere ActiveX-Komponente (HKEY_CLASSES_ROOT), sondern muss auch noch verschiedene Einträge in spezielle Verzeichnisse der Registry unter HKEY_CURRENT_USER setzen, damit sie als Add-In von der Zielanwendung erkannt und geladen werden kann. Für Access etwa lautet der betreffende Zweig:

    HKEY_CURRENT_USER\Software\Microsoft\Office\Access\Addins

    Und für VBA ist es der Zweig:
    HKEY_CURRENT_USER\Software\Microsoft\VBA\VBE\6.0\Addins

    In deren Abschnitten wird das Add-In anhand seiner sogenannten ProgID identifiziert - das ist die Bezeichnung derjenigen Klasse der Komponente, die besagte IDExtensibility2 implementiert.
    Die einzelnen Werte der Registry-Keys geben dann Auskunft über Namen, Beschreibung und Ladeverhalten des Add-Ins.

Hier kommen einige Fallstricke ins Spiel:

  1. Das Registrieren der Add-In-DLL kann auf übliche Weise mit dem Kommandozeilen-Tool regsvr32.exe von Windows erfolgen. Dabei werden nicht nur die Klasseninformationen in HKEY_CLASSES_ROOT geschrieben, sondern automatisch auch die Einträge für die angeführten Add-in-Zweige in HKEY_CURRENT_USER. In HKEY_CLASSES_ROOT kann allerdings nur ein Benutzer schreiben, der Adminstratorrechte auf den Prozess regsvr32.exe hat. Deshalb kann ein COM-Add-In nicht von einem normalen Benutzer oder Hauptbenutzer installiert werden, sondern nur von einem Benutzer der Gruppe Administratoren.
    Während dies unter Windows XP noch relativ einfach zu erreichen ist, indem man sich unter dem Adminstratorkonto anmeldet und dann das Add-In installiert, wird es unter Vista und Windows 7 schon schwieriger. Dort reicht es nicht, als Adminstrator angemeldet zu sein, sondern die Kommando-Shell muss erst direkt im Adminstrator-Kontext aufgerufen werden. (Im Startmenü etwa die "Eingabeaufforderung" über Rechtsklick als Administrator starten.) Erst von der Kommandozeile aus kann dann regsvr32 mit dem Pfad zur Add-In-DLL als Parameter aufgerufen werden. Ohne diesen Umweg schlägt der Aufruf von regsvr32 mit einer Fehlermeldung 80070005 (>fehlende Berechtigung) fehl.
    Aus diesem Grund ist es sinnvoll, ein COM-Add-In in ein Installations-Setup zu packen, das, wie bei unserem Procbrowser, gleich die für Vista notwendige elevation eingebaut hat. Ein Manifest in der Setup.exe sagt Vista, dass es diese Setup-Anwendung nur unter Administratorrechten ausführen soll. Nach Bestätigung der üblichen Warndialoge startet dann das Setup im Administratorkontext und kann damit auch die Registrierung in HKEY_CLASSES_ROOT vornehmen.
  2. Ungeschickt ist nun jedoch, dass die Ladeeinträge für das Add-In, wie oben beschrieben, ja im Zweig HKEY_CURRENT_USER vorgenommen werden. Damit ist das Add-In zunächst nur für den Administrator installiert, nicht aber für andere Benutzerkonten des Rechners. Es zeigt sich im Add-In-Manager von Access oder VBA nur beim angemeldeten Administrator. Leider gibt es keine Registry-Schlüssel, die diesen Umstand umgehen könnten. Es gibt deshalb in der Microsoft Knowledgebase eine Anleitung, wie man dieses Problem mit einem Workaround beheben kann: http://support.microsoft.com/kb/190212/en-us
    Für die bekannten MZTools für VBA gibt es hier auch noch eine kurze Notiz: http://www.mztools.com/v3/faq.aspx#InstallingAsNonAdmin
    Die erläuterten Verfahren sind indessen recht umständlich. Einfacher ist es, wenn der Entwickler des Addins gleich die entsprechende .reg-Datei weitergibt, so dass ein User sie nur noch doppelklicken muss, um das Add-In für sich zu aktivieren.

Um das Ganze aber noch eleganter zu lösen, wurde auch für diesen Zweck ein mossTOOL entwickelt...

mossTOOLs COM-Add-In Registrator

Das Tool kann beliebige COM-Add-Ins nicht nur für den aktuell angemeldeteten User aktivieren, sondern auch für andere User, die auf dem System ein gespeichertes Benutzerprofil haben.
Voraussetzung ist allerdings, dass der angemeldete User administrative Rechte besitzt. Der COM-Add-In Registrator-Prozess streikt einfach, wenn er sich nicht im Administratorkontext ausgeführt sieht.

Es reicht, die comaddinregistrator.exe in das gleiche Verzeichnis zu kopieren, in der sich eine COM-Add-In-DLL befindet. Bei Doppelklick auf die Exe berücksichtigt das Tool automatisch die erste im Verzeichnis gefundene DLL.
Dann kann im erscheinenden Dialog die DLL für beliebige User aktiviert oder deaktiviert werden. Für jeden gefundenen User gibt es eine Checkbox, die mit Häkchen versehen werden kann:

 Screenshot COM-Add-In Registrator 

Sollten mehrere DLLs im Verzeichnis existieren, so muss dem Tool mitgeteilt werden, welche DLL die Add-In-DLL ist. Dazu muss es mit einem Kommandozeilenparameter gestartet werden, der den Namen der DLL enthält. Dabei kann es sich um einen kompletten Pfad handeln, oder allein um den Dateinamen - in diesem Fall muss die DLL allerdings im gleichen Verzeichnis liegen, wie das Tool.
Beispiel-Kommandozeile:

comaddinregistrator.exe "C:\Programme\MZTools3VBA\MZTools3vba.dll"
oder nur:
comaddinregistrator.exe MZTools3vba.dll
(...falls die comaddinregistrator.exe im Verzeichnis der MZTools3vba.dll liegt.)

Wie funktioniert das?

Der COM-Add-In Registrator geht folgendermaßen vor:

  • Zuerst wird die DLL geladen und inspiziert, ob sie überhaupt eine TypeLibrary enthält, was die Voraussetzung für jegliche ActiveX-DLL ist.
  • Dann werden die in der Typelibrary enthaltenen Klassen (Interfaces) durchsucht und festgestellt, ob eine die Schnittstelle IDExtensibility2 unterstützt. Ist dies der Fall, dass handelt es sich korrekt um die Add-In-Klasse.
  • Aus dieser Klasse ergibt sich die Klassenbezeichnung (ProgID), die später in die Registry des Users eingetragen werden muss.
  • Über WMI werden die User des Systems ermittelt.
  • Nur solche User werden für die Listbox berücksichtigt, die auch ein Profil auf dem Rechner besitzen - etwa C:\Dokumente und Einstellungen\<username>. Andere User, wie etwa künstliche User, die das Windows-System oder der SQL-Server anlegen, bleiben außen vor.
  • Nun kann selbst ein Administrator nicht direkt in die Registrierung anderer User schreiben - die entsprechenden Zweige sind schlicht nicht geladen. Auch der Zweig HKEY_USERS zeigt nur Systemkonten und eine Spiegelung von HKEY_CURRENT_USER des Administrators. Darum lädt das Tools nach Setzen diverser Berechtigungen die Registrierungsdaten (Hives) jedes Users in einer Schleife in den Zweig HKEY_USERS. Dazu wird jeweils die ntuser.dat im Profilverzeichnis des Users geladen.
  • Jetzt kann aus dem geladenen Zweig gelesen oder in ihn geschrieben werden. Der Registrator zeigt deshalb gleich nach Öffnen aktivierte Checkboxen für die User, bei denen bereits Add-In-Eintrage gefunden werden.
  • Deaktivierte Checkboxen führen zum Löschen der entsprechenden Registry-Zweige, aktivierte zum Erzeugen dieser Zweige.
  • Nach dem Anlegen oder Löschen der Schlüssel werden die Registrierungsdaten jedes Users wieder entladen.

Das neue Tool liegt bisher im Beta-Stadium vor - Verwendung auf eigene Verantwortung. Tests unter Windows XP, Vista und Windows 7 RC liefen erfolgreich ab.
Berichten Sie uns, falls das Tool Fehlermeldungen von sich gibt. In diesem Fall können sie uns die bei jedem Start des Tools im gleichen Verzeichnis angelegte Datei log.txt mailen, was uns die Fehlersuche erleichtert - siehe im Archiv enthaltenes readme.txt.

 

Download Com-Add-In-RegistratorDownload mossTOOLS COM-Add-In Registrator - Beta 1

 

 
Kommentare (2)
RE: Clients im Domänen-Umfeld
2 Freitag, 19. Februar 2010 um 17:46 Uhr
Sascha Trowitzsch
Hm, ich habe extra nur die lokalen User reingenommen:

Select * From Win32_UserAccount WHERE LocalAccount=True

Grund: Bei einem Tester wurden sonst alle User der Domain enumeriert - und das waren ca. 500. ;-) Das dauerte...
2ter Grund: Die Domainuser haben andere Registryeinträge bzw. -Hives. Da ich leider hier keine Domain laufen habe, kann ich das nicht ausreichend testen.
Ich werde mal umgehend eine VM mit W2003 Server entspr. als Domaincontroller ausstatten, User einrichten, und dann berichten, falls ich das Tool modifiert habe.

Aber schön, dass das Teil erstmal für die lokalen User bei dir funktioniert.

Gruß, Sascha
Clients im Domänen-Umfeld
1 Freitag, 19. Februar 2010 um 17:30 Uhr
Oliver Fitz
Das Tool ist soweit schonmal ziemlich gut! Ich sitze hier allerdings an einem Rechner in einer Domäne. Nun habe ich hier auch ein lokales Admin Konto und würde gern den ProcBrowser über dieses coole Tool für meinen Domänenaccount registrieren. Leider werden der in der Auswahllliste nicht angezeigt (und auch sonst keiner der Domänen-Accounts). Vielleicht fehlt da ja noch eine Kleinigkeit in der WMI-Abfrage?

Gruß,
Oliver

Ihren Kommentar hinzufügen

Ihr Name:
Betreff:
Kommentar:
  Bild, welches den Sicherheitscode enthält
Sicherheitscode: