6

J'ai un service Windows écrit en C# en utilisant VS2005.Comment persuader un VS2005 msi de mettre à niveau?

L'installation s'effectue via un assistant qui appelle msiexec pour installer le fichier msi également créé avec VS2005.

Je rencontre des problèmes pour générer un fichier msi qui sera mis à niveau d'une version du service à une autre. Le programme de l'assistant gère la détection de la version actuellement installée, en arrêtant le service, en proposant une ligne de commande appropriée pour msiexec, puis en redémarrant le service.

Le fichier msi existant a une propriété version de 1.1.02, la nouvelle version est 1.1.03. Les codes de produit et de mise à niveau sont identiques.

La désinstallation manuelle de la version 1.1.02 via les programmes d'ajout/suppression fonctionne correctement, tout comme l'installation de la version 1.1.03 sur un système "propre".

La mise à jour de 1.1.02 à 1.1.03 passe par les mouvements mais le résultat final est 1.1.02 installé.

La ligne de commande que l'assistant utilise pour la mise à niveau est:

msiexec/qb/i "MyProduct.msi" REINSTALL = "ALL" REINSTALLMODE = "vos"

Où vais-je tort? Je suppose que j'ai dû manquer quelque chose d'assez fondamental ...

La position de repli est d'informer les clients qu'ils doivent désinstaller manuellement 1.1.02 avant d'exécuter l'assistant pour installer 1.1.03 mais je préfère pas besoin de faire ça.

Sous la direction d'ajouter:

Modification du code du produit (comme VS2005 vous invite également à) supprime effectivement la possibilité de mettre à niveau à tout, comme l'installateur ne vous laissera pas faire une réinstallation si ce code produit hasn pas déjà été installé.

Tout ce qu'il vous laissera alors est installer (et alors vous obtenez le message habituel "service existe déjà").

Répondre

8

Plusieurs choses doivent être faites pour que les «mises à niveau» fonctionnent avec les MSI si vous voulez supprimer automatiquement la version précédente.

D'abord quelques informations de fond sur les "codes" mystérieux. Il y a 3 codes (GUID) associé à un MSI:

  1. package Code - Ceci identifie une version particulière du programme d'installation MSI et ne doit jamais être réutilisé dans construit. Il doit toujours être mis à jour.
  2. Code de produit - Cet identificateur est utilisé pour identifier une version particulière de l'application. Il appartient à l'auteur de l'installateur de décider quand attribuer un nouveau code de produit.
  3. Upgrade code - Il identifie l'application et ne devrait pas changer à travers sa vie

Le Code de mise à niveau ne devrait jamais changer. Pour la mise à niveau de scenerio, le code produit doit être modifié pour chaque version. En outre, comme vous l'avez mentionné, vous devez augmenter le numéro de version.Le Code de produit et Le code de mise à niveau peut être trouvé en sélectionnant votre projet d'installation et en allant à la fenêtre Propriétés. Le code du package est masqué dans Studio et sera toujours mis à jour.

L'élément dont vous avez probablement besoin, est que vous devez également définir le paramètre RemovePreviousVersions dans la fenêtre Propriétés sur true.

6

Une chose en plus de la réponse de mohlsen (pour Visual Studio 2008):

Pour que votre sortie primaire (! Votre EXE) pour mettre à niveau correctement, vous devez incrémenter la version du fichier

Ce paramètre peut être trouvé dans les propriétés du projet: Onglet Application -> Informations sur l'assemblage

+0

Oui, cela a été fait correctement. A fini par renoncer à cela et a eu recours à faire de l'assistant la désinstallation suivie d'une nouvelle installation si elle détecte déjà une ancienne version en place. Semble fonctionner correctement et permet aux utilisateurs finaux de mettre à niveau sans devoir manipuler manuellement quoi que ce soit. –

+0

Aussi, pour autant que je puisse le constater, les MSI construits par Visual Studio sont apparemment connus pour ne pas vous permettre de mettre à niveau les services, donc en faisant le travail dans l'assistant, j'ai évité de tomber dans le piège suivant. –

+0

+1 mais pour le rendre complètement clair, cela signifie mettre à jour la version du fichier du projet MAIN (pas le projet d'installation!). –

2

Une façon plus simple de gérer cela est de supprimer la AssemblyFileVersion de tous les assemblys, y compris l'exécutable principal et toutes les DLL managées.

Dans chacun de vos fichiers AssemblyInfo.cs, je recommande de faire quelque chose comme ceci si vous ne vous souciez pas des numéros de version, mais que vous voulez avoir une traçabilité.

[assembly: AssemblyVersion("1.1.*")] 
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")] 

Tout compile toujours bien, et si vous n'avez pas le AssemblyFileVersion défini, le programme d'installation suppose que tout est différent à chaque fois (ce qui est probablement bien si vous installez toutes les DLL à côté de la principale EXE).

J'ai passé beaucoup de temps à comprendre cela, surtout si je ne veux pas avoir à incrémenter quoi que ce soit manuellement!

Questions connexes