7 replies to this topic

[Weissenborn]

Hallo Leute,

ich habe ein Problem, für das ich noch keine Lösung gefunden habe:

Ausgangssituation:
-------------------------
Ich habe eine Software A und eine Software B, die beide eine gemeinsame Software C verwenden und diese bei Bedarf installieren, bzw. updaten.

Deinstalliert wird C nie.

A installiert eine ältere Version von C als B.

Die Version von C die B installiert ist in B als Merge-Modul realisiert.
Die Version von C die B installiert benötigt MFC 7.1.

Damit C nie deinstalliert wird ist in dem Merge-Modul die Eigenschaft Permanent aller Compontents auf Yes gesetzt.

Die MFC 7.1 ist den Module Dependencies der Merge Module Properties hinzugefügt.

Problem:
-------------

Wenn man auf einem ganz neuen System A installiert, danach B installiert und dann B wieder deinstalliert, läuft A nicht mehr, weil folgendes passiert ist:

A hat C installiert.
B hat C aktualisiert und die dazugehörige MFC 7.1 aufgespielt.
B hat bei der Deinstallation die MFC 7.1 wieder weggenommen.

Frage:
---------

Wie verhindere ich das die MFC 7.1 weggenommen wird, wenn B deinstalliert wird. Die MFC 7.1 ist doch bei den Merge-Modul-Dependencies angegeben und da ich keine der Componenten deinstalliere sollte die MFC 7.1 auch installiert bleiben.
Leider kann ich bei den Merge-Modul-Dependencies keine Eigenschaft "Permanent" auf Yes setzen.

Viele Grüße von
Gregor Weißenborn

[akerl]

Ich verstehe Dein Problem nicht ganz, denn mir scheint dass dabei zu viele Merkwürdigkeiten auftreten:
1. Du sprichst von 2 Versionen von C. Ich vermute C ist eine Komponente. Allerdings schreibst Du dass die C, die mit B installiertt die MFC71 benötigt. Ich vermute, die C von A benötigt diese nicht. Hieraus folgt, dass die C von B und die C von A nicht kompatibel sind; somit kann es sich nicht um die gleiche Komponente handeln. Denn die Component-Guidelines sage, dass die ComponentId zu ändern ist, wenn die beiden Versionen nicht mehr kompatibel sind.

Siehe:
Creating a New Version of a Component
A new version of a component is assigned the same component code as another existing component. Modifying a component without changing the component code is only optional in the following cases:
The changes to the component have been proven by testing to be backward compatible with all previous versions of the component.

2. Du verstößt mit Deinen Anforderungen gegen sämtliche Logo-Guidelines. Denn die Software, die Du installierst, muss auch wieder deinstalliert werden.

Gruß
Andreas

[Weissenborn]

Zu 1.:
Ja alles soweit richtig verstanden. Allerdings: C ist eine Middleware, die in einigen hundert DLLs, MDBs etc. realsiert ist und in erster Linie spezielle Kommunikationstechniken zu spezieller Hardware realisiert.
Der Umstand das die ältere Version von C keine MFC 7.1 benötigt, die neuere aber doch, hat keinen Einfluß auf die Kompatibelität von C zu A oder B, bzw. es wir dvom Hersteller von C garantiert, dass die Versionen zu einander kompatibel sind. - Sind sie auch, durch Evaluation bestätigt, da die Interfaces zu A und B gleich geblieben sind.
Die Version A und C (darin enthalten) ist nicht mit MSI realiseirt sondern basiert auf IS 7.1

Zu 2.:
Ja. - Und? ... Wer hat gesagt, das Bills Wort das das letzte ist.

Aber zurück:
Wie erreiche ich das das MFC 7.1- Merge Modul nicht deinstalliert wird?

Man muß ja auch bedenken, das das Problem grundlegender Natur ist. Wenn man irgendwelche Components mit der Eigenschaft Permanent = Yes versehen kann, können diese ja grundsätzlich abhängig sein von anderen Merge Modulen, wie z.B. der MFC 7.1. Denen wird dann u.U. die Grundlage entzogen wenn das Programm deinstalliert wird. Und es gibt auch Technologien, die so fundamental sind, dass es Sinn macht diese nicht mehr zu deinistallieren. Die MFC z.B.

Viele Grüße
Gregor Weißenborn

[akerl]

Na dann, wirst Du ein großes Problem haben. Die Module Dependencies sind relevant für den Buildprozess aber nicht für die Installation. Soll heißen beim Build wird erkannt das Abhängigkeiten vorhanden sind und prüft ob diese erfüllt sind. Es werden letztlich die Komponenten des MFC-MSM in das Package übertragen. Da Microsoft sich an die Richtlinien (siehe 2) hält, sind die MFC-Komponenten als Nicht-Permanent gekennzeichnet. Bei der Deinstallation erfolgt eine Referenzcheck, der keine weitere Referenz offenbart und die MFC entfernt.

Sicher besteht die Möglichkeit fundamentale Technologien auf dem System zu belassen. Doch die Einstufung in fundamental oder nicht legt dabei der Hersteller fest - und das ist bei der MFC wohl nicht der Fall.

Ggf. wäre es sinnvoll das MSM-Mergemodul auch mit A zu verwenden oder ein separates Setup zu bauen, dass als System-Komponente gekennzeichnet ist.

[Weissenborn]

Ich habe eine Lösung gefunden:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls

Und da setze man für die Keys:

WINSYSDIR ^ "mfc71.dll"
WINSYSDIR ^ "mfc71u.dll"
WINSYSDIR ^ "msvcp71.dll"
WINSYSDIR ^ "msvcr71.dll"

Den Wert wenn < 2 auf mindestens 2.

Viele Grüße von
Gregor Weißenborn

[akerl]

Und schwupp ist die ganze Referenzzählung für Non-MSI's durchbrochen

[Weissenborn]

Ja, dass stimmt. - Aber ist das so etwas neues?

Es löst das Problem. Und das ist das was der Kunde will.

Für Produkt A einen neuen Installer zu schreiben löst das Problem nicht, denn es ist bereits im Markt und mit dem anderen Installer ausgeliefert.

Ich finde die Lösung ja auch nicht so toll.
Aber man hätte ja auch die Module-Dependencies konkretisieren können, so das sie einer Componente zugeordnet werden können: Erst wenn diese deinstalliert würden, würde auch das abhängige Merge Modul deinstalliert. Dann hätte ich das Problem nämlich garnicht.

Viele Grüße
Gregor Weißenborn

[akerl]

Ich verstehe das - würde es wahrscheinlich genauso machen.

Viele Grüße