Ich habe eine Visual Studio 2010-Lösung mit 8 Projekten. Es hat auch ein Setup-Projekt, das ich zur Erstellung der Installation aufbaue.
Es funktioniert gut, wenn es die erste Installation auf einem Client-PC ist. Ich ändere dann jedoch mein Projekt, erstelle ein neues Setup und gebe es an Clients weiter. In diesem Fall muss der Client zuerst die letzte Installation manuell deinstallieren und dann das Setup ausführen.
Wenn sie das Setup ausführen, ohne es zu deinstallieren, werden vorhandene Dateien (exe sowie die DLLs) dadurch nicht überschrieben. Normalerweise wird nur das Exe modifiziert. Es wird jedoch nicht überschrieben. Die Version auf dem Client-Computer scheint gleich zu bleiben.
Gibt es eine Möglichkeit, das Überschreiben zu erzwingen?
Wenn ich mein Hauptanwendungsprojekt ändere, gehe ich zu den Eigenschaften des Projekts, zu Baugruppeninformationen, und erhöhe die Baugruppenversion sowie die Dateiversion.
Das visuelle Studio-Installationsprogramm ist im Vergleich zu kommerziellen Produkten oder sogar WiX nicht besonders benutzerfreundlich, wenn Sie die Installation gut beherrschen.
Wenn Sie ein Visual Studio-Setup-Projekt haben, haben Sie mehrere Eigenschaften, die an dem Aktualisierungsvorgang beteiligt sind
1) Der Upgrade-Code - Dies ist die Verbindung zwischen Installationsprogrammen desselben Produkts. Sie sollten diesen Code nicht unnötig ändern
2) Die Versionsnummer - seltsamerweise werden nur die 1. 3 Zahlen (major.minor.build) zum Vergleich verwendet (dies ist ein häufiger Fehler, den viele Entwickler machen)
3) Der Produktcode - Sobald Sie die Versionsnummer ändern, werden Sie von VS aufgefordert, diese Nummer zu ändern. Wenn Sie die Änderung der Nummerierung automatisieren, sollten Sie dies ebenfalls tun
4) DetectNewerInstalledVersion - auf True setzen
5) RemovePreviousVersions - auf True setzen
Ich persönlich würde WiX für eine so kleine Installation verwenden, d. H. Wenn Sie dies in Visual Studio und dann die WiX-Version tun können
Mein Installer für OpenCover sieht so aus
<Wix xmlns="http://schemas.Microsoft.com/wix/2006/wi" >
<Product Id="*" Name="OpenCover" Language="1033" Version="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)"
Manufacturer="OpenCover @ GitHub" UpgradeCode="2250c3f1-d9ba-44d8-b4db-25f91fe92dc6">
<Package InstallerVersion="200" Compressed="yes" />
<Upgrade Id="2250c3f1-d9ba-44d8-b4db-25f91fe92dc6">
<UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND" Minimum="1.0.0.0" IncludeMinimum="yes"
Maximum="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)" IncludeMaximum="no" />
<UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND" Minimum="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)"
IncludeMinimum="yes" />
</Upgrade>
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
...
</Wix>
Ich hoffe, Sie finden das oben nützliche
Ändern Sie in den Eigenschaften des Setup-Projekts die Versions-/Build-Nummern. Dadurch werden Sie aufgefordert, die Generierung eines neuen GUID zuzulassen. Dadurch wird dem Installationsprogramm mitgeteilt, dass Sie über eine neue Version verfügen und die alte Version des Programms automatisch entfernt und die neue vom MSI-System installiert wird.
Dies ist ein alter Beitrag, der jedoch für Leute hinzugefügt wird, die nach einer Antwort suchen.
Ich bin auf dieses Problem gestoßen, auch nachdem ich alles hier auf den Brief eingegangen bin. Mein Problem war, dass die Version des C # -Programms nicht bei jedem Build zunimmt, egal was passiert. Selbst nachdem ich AssemblyInfo.cs manuell bearbeitet habe, wäre die Version des generierten Exe immer noch 1.0.0.0. Das Setup ersetzt die Datei daher nicht.
Sie können das Problem umgehen, indem Sie dem Knoten "Primäre Ausgabe aus XYZ-Projekt" (oder was auch immer Sie überschreiben möchten) des Setup-Projekts eine Startbedingung hinzufügen. Dies bewirkt, dass das Installationsprogramm die Datei löscht, wenn das neuere Setup ausgeführt wird. Wenn der Benutzer die App startet, wird ein Fenster mit der Meldung angezeigt, dass die Anwendung konfiguriert wird. Neuere Dateien werden in den App-Ordner kopiert und die App wird gestartet. Dies ist ein Versuch und Irrtum. Ich habe keine Ahnung, warum es so funktioniert (und ich brauche etwas Kaffee, nachdem ich die ganze Nacht damit verbracht habe, das herauszufinden :)).
Ich hatte auch das Problem, dass die .exe-Datei nicht aktualisiert wurde, obwohl die obigen Schritte ausgeführt wurden. Es scheint, dass die Produktversion der .exe nicht automatisch der Versionsnummer folgt, die in den Setup-Eigenschaften festgelegt ist. Wenn die EXE-Datei beim Ausführen der neuen Installationsprogramme ersetzt werden soll, erhöhen Sie die Produktversion wie folgt:
1) Springen Sie Projekteigenschaften> Anwendung> Montageinformationen ...
2) Erhöhen Sie die Versionsnummern von Assembly und File
3) Erstellen Sie das Setup erneut und die Installation sollte die alte .exe-Datei überschreiben
Hoffe das hilft jemandem.
AssemblyVersion & AssemblyFileVersion sollte erhöht werden, wenn Assembly (exe/dll) zusammen mit anderen Einstellungen überschrieben wird, was @shaun wilde erwähnt
Ich hatte das gleiche Problem. Um dies sicherzustellen, stellen Sie am besten sicher, dass Ihre ausführbare Datei, d. H. Application.exe selbst, eine höhere Version als die vorherige hat.
Klicken Sie einfach auf die Projekteigenschaften (nicht das Setup-Projekt) und setzen Sie die Anwendungsversion auf eine höhere Version.
Um die Antworten ein wenig zu verfeinern, müssen Sie die Dateiversion inkrementieren, damit Windows Installer während eines Updates überschrieben wird. Dies ist nicht notwendigerweise dasselbe wie das Erhöhen der Assembly-Version, wie von einigen angegeben. Nur die Dateiversion muss inkrementiert werden. Mit verwaltetem Code können Sie dies mit AssemblyFileVersion tun. Die Dateiversion ist standardmäßig auf die Assembly-Version eingestellt. Mit AssemblyFileVersion können Sie sie jedoch anders machen, wenn Sie über Client-Assemblys verfügen, die von einer bestimmten AssemblyFileVersion abhängen.
Hatte ähnliche Probleme mit Dateien, die nicht überschrieben wurden. Geprüfte Versionsnummern, Produkt-/Upgrade-Codes, alles. Was mir schließlich geholfen hat, war dieser Beitrag bei MSDN . Speziell der Teil hier, wenn Sie Orca verwenden, um die MSI-Datei zu untersuchen:
Ich habe auch die Reihenfolge der RemoveExistingProducts in der Tabelle> InstallExecuteSequence von 6550 in 1525 geändert (nach InstallExecute in after> InstallInitialize).
Nicht sicher, warum, aber das Installationsprogramm scheint die Deinstallation der vorherigen Version auszuführen, nachdem die neue Version bereits installiert wurde. Vielleicht gibt es einen Grund dafür, aber durch eine Änderung schien es die einzige Möglichkeit zu sein, dass ich meine Anwendung zur Aktualisierung zwingen konnte.
Wenn jemand anderes wie kürzlich auf dieses Problem stößt, hoffen Sie, dass diese Problemumgehung hilft.