3 replies to this topic

[Weissenborn]

Hallo,

bei einem Update auf eine bestehende Programmversion wird auch eine selbstregistrierende DLL aktualisiert.

Wird dabei zunächst die alte DLL deregistriert (DLLUnRegisterServer) und die neue DLL nach dem Kopiervorgang registriert (DLLRegisterServer)? - So wäre es wünschenswert.

Oder wird nur die neue DLL über die alte DLL kopiert und und die alte Registrierung bleibt weiterhin unverändert gültig?

Letzteres hätte fatale Folgen, wenn das Update ganz oder teilweise wegen Änderungen der Selbstregistrierung notwendig ist. - Diese würden dann ja gar nicht im Produktupdate enthalten sein, weil die alte DLL nicht deregistriert und die neue DLL neu registriert würde.

Wenn Letzteres gilt, - was könnte man da am besten machen?

Viele Grüße
Gregor Weissenborn

[Stefan Krueger]

Sprechen wir von Windows Installer (MSI), InstallScript oder etwas ganz anderem?

Wenn das Update die alte Produktversion nicht deinstalliert (wie das z.B. beim Major Upgarde bei Windows Installer der Fall sein kann), sondern nur die neue DLL drüberschreibt, dann wird vermutlich auch nur die Registrierungsfunktion der neuen Version aufgerufen.
Bei Windows Installer sollte man auf diese Form der Selbstregistrierung verzichten und stattdessen die Registrierungsdaten extrahieren. Dann sollten die Registry-Einträge aktualisiert (überschrieben) werden.
Bei InstallScript könnte manuell die Deregistrierung aufrufen, denke ich.

[Weissenborn]

Das ist Windows Installer (MSI).

Die Funktionen DllRegisterServer und DllUnRegisterserver, können beliebigen Code der ausschließlich unter der Planung und Controlle des Entwicklers dieser DLL steht, enthalten.
Also auch Code, der völlig andere Dinge tut, als Eintragungen in der Systemregistry vorzunehmen. (!) (Z.B. Dateien beschreiben, kopieren,verschieben, löschen, Schnittstellen abfragen, Daten senden, ...)

Die Verwendung von Selbstregistrierungen halte ich sogar für ausgesprochen gut. So kann der Entwickler der DLL unabhängig von dem Installer die Einstellungen und Anpassungen vornehmen, die für die Ausführung der DLL dringend erforderlich sind.

Meines Erachtens sollte der Installer grundsätzlich nur solche Einstellungen vornehmen, die nur ihm bekannt sein können. Wie z.B. den Installationspfad, das Installationsdatum, den Usernamen, die Firma, das Passwort irgendwo eintragen.
Alle anderen Einstellungen und Konfigurationen, sollte der Entwickler der DLL in der Selbstregistrierung, ganz nach Belieben und Erforderniss, selbst vornehmen, denn nur ihm selbst sind alle Anforderungen und Anpassungen wirklich bekannt und es kommt nicht zu Missverständinssen und Übertragungsfehlern. Zudem werden dadurch die DLL-Relevanten Daten, auch mit dieser verbunden. So sind z.B. spätere Fehlerbehebungen durch Neuregsitrierung (regsvr32.exe) und ohne Neuinstallation möglich.

Allerdings setzt dies auch zwingend voraus, dass die Funktion DllRegisterServer, in dem Fall, dass der Installer als Update ausgeführt wird, weil bereits eine Vorversion installiert wurde, immer ausgeführt wird. Denn sonst wird ja der Code der DllRegisterServer-Funktion nur bei der allerersten Installation ausgeführt und Updates der Funktion kommen im Update-Fall der Istallation nicht mehr zur Wirkung.

Bevor ich nun "regsvr32 /i dllname.dll" irgendwo in einem Script bei Update ausführe, wollte ich erst einmal wissen, ob nicht ohnehin die DllRegisterServer im Updatefall ausgeführt wird. - Denn dann könnte ich mir das ja sparen.

[Stefan Krueger]

Es lässt sich darüber streiten, ob solche Änderungen am Zielsystem in die DllSefRegister Funktion gehören. Dagegen spricht zum Beispiel, dass es eine "Black Box" ist, ein Administrator also nicht sehen kann, was dort passiert, und dass die Rollback-Funktionalität von Windows Installer solche Änderungen nicht erfassen kann. Aber zum Glück hat man ja die freie Wahl, welches Registrierungsverfahren man nutzen möchte.

Zurück zur ursprünglichen Frage: ehrlich gesagt weiß ist nicht, ob bei einem Small oder Minor Update (wir sprechen hier nicht von Major Upgrades, oder?) die DllRegisterServer nochmal aufgerufen wird. Das müsste man mal ausprobieren. Aber ich bin ziemlich sicher, dass die DllUnRegister Funktion der alten DLL nicht aufgerufen wird.