Le programme d'installation ne remplacera pas l'application existante
J'ai une solution Visual Studio 2010 avec 8 projets. Il a également un projet d'installation que je construis pour créer l'installation.
Cela fonctionne bien lors de la première installation sur un PC client. Cependant, je modifie ensuite mon projet, crée une nouvelle installation et le transmet aux clients. Lorsque cela se produit, le client doit d'abord, manuellement, désinstaller la dernière installation, puis exécuter le programme d'installation.
S'ils exécutent le programme d'installation sans désinstallation, il semble que les fichiers existants ne soient pas écrasés (les fichiers exe ainsi que les dll). D'habitude c'est juste l'exe qui est modifié. Cependant, cela ne l'écrase pas. La version sur l'ordinateur client semble rester la même.
Y a-t-il un moyen de le forcer à écraser?
Notez que lorsque je modifie mon projet d'application principal, j'accède aux propriétés du projet, aux informations d'assemblage, et j'augmente la version d'assemblage ainsi que la version du fichier.
Le programme d’installation de Visual Studio n’est pas le logiciel le plus convivial par rapport aux produits commerciaux ni même à WiX si vous souhaitez bien contrôler votre installation.
Lorsque vous avez un projet d'installation de Visual Studio, vous avez plusieurs propriétés impliquées dans le processus de mise à niveau.
1) Le code de mise à niveau - il s’agit du lien entre les installateurs du même type et vous ne devriez pas changer ce code inutilement.
2) Le numéro de version - étrangement, seuls les 3 premiers chiffres (major.minor.build) sont utilisés à des fins de comparaison (il s'agit d'une erreur courante commise par de nombreux développeurs).
3) Le code produit - Dès que vous modifiez le numéro de version, VS vous invitera à modifier ce numéro. Faites-le. Si vous automatisez le changement de numéro, n'oubliez pas de le faire également.
4) DetectNewerInstalledVersion - défini sur True
5) RemovePreviousVersions - défini sur True
Personnellement, je considérerais l’utilisation de WiX pour une installation aussi petite, c’est-à-dire si vous pouvez le faire dans Visual Studio, puis la version WiX.
Mon installateur pour OpenCover ressemble à ceci
<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>
J'espère que vous trouvez ce qui précède utile
Dans les propriétés du projet d'installation, modifiez les numéros de version/build. Cela vous invitera à autoriser la génération d'un nouveau GUID. Cela indique au programme d'installation que vous disposez d'une nouvelle version et permettra à l'ancienne version du programme d'être automatiquement supprimée et la nouvelle installée par le système MSI.
Ceci est un ancien post mais en ajoutant ceci pour les personnes qui pourraient venir chercher une réponse.
J'ai rencontré ce problème même après avoir suivi tout ce qui est donné ici à la lettre. Mon problème était que la version du programme C # ne sera pas incrémentée sur toutes les versions, peu importe quoi. Même après que j'ai édité manuellement AssemblyInfo.cs, la version de l'exe généré serait toujours 1.0.0.0. En conséquence, le programme d'installation ne remplacera pas le fichier.
La solution de contournement consiste à ajouter une condition de lancement au nœud "Sortie principale du projet XYZ" (ou à ce que vous souhaitez écraser) du projet de configuration. Le programme d’installation supprime le fichier lors de l’exécution de la nouvelle configuration. Désormais, lorsque l'utilisateur lance l'application, une fenêtre apparaît indiquant que l'application est en cours de configuration, les fichiers les plus récents sont copiés dans le dossier de l'application et l'application est lancée. Ceci est simple essai et erreur. Je ne sais pas pourquoi cela fonctionne de cette manière (et j'ai besoin de café après avoir passé toute la nuit à essayer de comprendre cela :)).
- Faites un clic droit sur votre projet d'installation >> Voir >> Conditions de lancement
- Faites un clic droit sur "Configuration requise sur la machine cible" >> Ajouter une condition de lancement du fichier
- Un nœud ("Search for File1") apparaîtra sous "Search Target Machine" et un autre nœud ("Condition1") apparaîtra sous "Launch Conditions"
- Cliquez sur Search for File1 et remplacez sa propriété FileName par quelque chose qui est lié à préexister (comme "Notepad.exe", enfin presque toujours)
- Notez que "Dossier" est défini sur "[SystemFolder]" et "Propriété" sur "FILEEXISTS1".
- Maintenant, cliquez sur Sortie principale du projet XYZ ou de tout autre noeud. Dans la fenêtre des propriétés, définissez "Condition" sur "FILEEXISTS1" exactement comme ci-dessus.
J'ai également eu le problème du .exe ne mettant pas à jour bien en suivant les étapes ci-dessus. Il semblerait que la version du produit .exe ne suive pas automatiquement le numéro de version défini dans les propriétés d'installation. Pour que le fichier .exe soit remplacé lors de l'exécution des nouveaux programmes d'installation, incrémentez la version du produit comme suit:
1) Aller à Propriétés du projet> Application> Informations sur l'assemblage ...
2) Augmenter les numéros de version d'assemblage et de fichier
3) Générez à nouveau l'installation et l'installation devrait remplacer l'ancien .exe
J'espère que ça aide quelqu'un.
AssemblyVersion & AssemblyFileVersion devrait être incrémenté pour écraser Assembly (exe/dll) avec d'autres paramètres, ce que @shaun wilde a mentionné
J'ai eu le même problème. Le meilleur moyen de vous en assurer est de vous assurer que votre fichier exécutable, c’est-à-dire que l’application.exe elle-même a une version plus récente que la précédente.
Cliquez simplement sur les propriétés du projet (pas le projet d'installation), et définissez la version de l'application sur une version supérieure.
En affinant un peu les réponses, vous devez incrémenter la version du fichier pour que Windows Installer écrase lors de la mise à jour. Ce n'est pas nécessairement la même chose que l'incrémentation de la version Assembly, comme certains l'ont indiqué. Seule la version du fichier nécessite une incrémentation, et avec le code géré, vous procédez de la sorte avec AssemblyFileVersion. La version de fichier par défaut est Version d'assembly, mais AssemblyFileVersion vous permet de les rendre différents lorsque vous avez des assemblys clients qui dépendent d'une AssemblyFileVersion spécifique.
Avait des problèmes similaires avec les fichiers ne pas écraser. Numéros de version vérifiés, codes produit/mise à niveau, tout. Ce qui m'a finalement aidé, c'est ce poste à MSDN . Spécifiquement la partie ici, lorsqu’on utilise Orca pour examiner le fichier msi:
J'ai également modifié la séquence de RemoveExistingProducts dans la table> InstallExecuteSequence de 6550 à 1525 (après InstallExecute, après> InstallInitialize).
Vous ne savez pas pourquoi, mais le programme d'installation semble lancer la désinstallation de la version précédente après avoir installé la nouvelle version. Peut-être y a-t-il une raison à cela, mais le changer semblait être le seul moyen de forcer mon application à se mettre à niveau.
Si quelqu'un d'autre découvre ce problème comme je l'ai fait récemment, espérons que cette solution de contournement aidera.