Ich habe ein Windows-Anwendungsprojekt (A.exe), die ein anderes Projekt aufruft Klassenbibliothek (B.dll).
A..exe hat eine Schaltfläche (myButton), die ruft die Methode Method1 von B.dll.
So installieren Sie die Anwendung, die ich erstellt habe ein Setup-Projekt ASetup.vdproj, dessen Primäre Ausgabe ist Projekt A.
Nach dem Kompilieren des Setups wird das Installation läuft ohne Probleme, wenn A..exe startet und ich Klicken Sie auf myButton, die Anwendung gibt kein Fehler.
Dann habe ich B.dll geändert und ein neues hinzugefügt Methode2.
myButton ruft jetzt Method2 von B.dll statt Methode1.
Ich habe die Version von A..exe und Erhöhen Sie die Version von ASetup.vdproj, aber nicht erhöhen die Version von B.dll.
Nach der Installation der Anwendung I bemerkte ich hatte zwei Installationen von A.exe in der Systemsteuerung - & gt; Hinzufügen / Entfernen Sie Programme.
Wenn Sie A..exe ausführen und auf klicken myButton Ich erhalte einen Fehler, "The Methode Method2 wurde nicht gefunden B.dll ", bedeutet dies, dass das Setup funktioniert B.dll nicht während ersetzen Installation.
Ich habe die Deinstallation durchgeführt und ich habe es bemerkt dass die Dateien nicht entfernt wurden von der Festplatte.
Meine Frage ist:
Warum aktualisiert die zweite Installation B.dll nicht? Wenn die Version von B.dll inkrementiert wird, wird B.dll während der Installation ersetzt, aber das Problem ist, dass mein aktuelles Projekt viele externe Assemblys hat, die schwer zu steuern sind, wenn sie geändert werden oder nicht. Grundsätzlich möchte ich, dass alle Assembly-Dateien in jeder Installation ersetzt werden.
Ich erwarte Feedback von euch allen. Danke für die Aufmerksamkeit.
Die zwei Einträge in Programme hinzufügen / entfernen sagen mir, dass Sie die ProductCode-Eigenschaft geändert haben, aber keine gültige Zeile in der Aktualisierungstabelle hatten, um ein Major Upgrade richtig zu definieren. MSI behandelt dies als 2 verschiedene Produkte, die zufällig in dasselbe Verzeichnis installiert werden. Wenn Sie eines der beiden Produkte deinstallieren, bleiben die Dateien erhalten, bis Sie das andere Produkt deinstallieren.
Die DLL, die nicht überschrieben wird, schlägt mir vor, dass Sie das AssemblyFileVersion Attribut von einem Build zu einem anderen nicht ändern. Die erste Installation kopiert in 1.0.0.0 und die zweite Installation sagt "1.0.0.0 ist schon da, nichts zu tun" und überspringt es.
Neben dem von @Christopher Painter erwähnten Problem gibt es höchstwahrscheinlich ein anderes Problem: Das mit Visual Studio (2008) erstellte Installationsprojekt ersetzt nur Dateien, wenn die Versionsnummer erhöht wurde. Die naheliegende Lösung wäre, alle Versionsnummern zu erhöhen. Dies ist jedoch möglicherweise nicht immer das, was Sie möchten.
Das Verhalten der MSI-Datei wird im Wesentlichen durch den Zeitpunkt bestimmt, zu dem die Aktion RemoveExistingProducts ausgeführt wird wird ausgeführt. Installer, die mit VS 2008 erstellt wurden, planen diese Aktion , nachdem das neue Produkt installiert wurde. Geänderte Baugruppen, deren Version nicht inkrementiert wurde, werden daher nicht ersetzt. Einige weitere Details zum Aktualisierungsverhalten werden in diesem Thread beschrieben:
RemovePreviousVersions=True, aber die vorherige Version wurde nicht entfernt vom Zielgerät
Um das Verhalten zu ändern, können Sie die erstellte .msi-Datei so patchen, dass die RemoveExistingProducts entfernt wird Die Aktion wird ausgeführt bevor das neue Produkt installiert wird (dies ist das Verhalten, wenn Sie das Setup mit Visual Studio 2005 erstellt haben). Das Patchen kann z.B. mit einem kleinen VBScript ausgeführt werden, das als Post-Build-Schritt ausgeführt wird:
%Vor%Tags und Links installation installer windows-installer