2009-06-22 4 views
5

J'ai une application Windows Forms avec un programme d'installation (.msi) déjà créé avec Visual Studio. Je crée maintenant un nouveau programme d'installation pour la version 2.0 avec la propriété RemovePreviousVersions définie sur true.Pouvons-nous demander à Visual Studio Setup de conserver les fichiers existants pour les réinstaller?

Maintenant, quand j'installe 2.0 sur 1.0 il supprime 1.0 et installe complètement 2.0.

Est-il possible que je peux dire à l'installateur si vous trouvez des fichiers déjà installés (comme les fichiers .xml utilisés pour les données) alors ne les remplace pas?

Je suis en train d'avoir mon 2.0 installateur servir les 2 objectifs:

  • Installer à partir de zéro pour les nouveaux utilisateurs
  • Les utilisateurs existants de mise à niveau, mais ne perdent pas leurs personnalisations

Répondre

2

Quand j'étais dans une situation similaire ce que je faisais était:

les fichiers qui ont été personnalisés par chaque utilisateur et ne doivent PAS être touchés par le programme d'installation ne figurent pas dans e e MSI (PAS dans le projet d'installation de Visual Studio). Lorsque l'application a été exécutée pour la première fois, j'ai généré les fichiers XML via le code.

Les fichiers qui étaient statiques (par exemple des données qui a été utilisé pour remplir DropDownLists) J'inclus dans le MSI et je peux mettre à jour ceux en construisant un nouveau MSI avec Visual Studio.

Fondamentalement ne comprennent pas les fichiers personnalisables dans votre projet MSI. Créez-les dans le code pour les nouveaux utilisateurs.

Je ne ai jamais regardé en disant au MSI de ne pas mettre à jour certains fichiers qui sont inclus dans le fichier MSI. La solution que j'ai trouvée était parfaite pour moi. Je ne sais pas si cela peut être fait.

J'espère que cette aide.

13

Le projet de déploiement dans VS n'écrase pas les fichiers. Ce qui se passe est que, puisque vous avez défini RemovePreviousVersions sur true, lorsque vous modifiez la version du fichier de programme et le GUID ProductCode du projet d'installation, il désinstalle d'abord la version précédente et effectue une nouvelle installation de la nouvelle version. Pour m'assurer que certains fichiers ne sont pas remplacés, je les exclue généralement des fichiers de sortie Content ou Primary (où qu'ils se trouvent), puis les ajoute séparément au projet d'installation. Pour ce faire, vous pouvez définir individuellement les propriétés de ces fichiers. La propriété que vous cherchez s'appelle Permanent "si elle est définie sur" true ", elle ne désinstallera jamais le fichier en question et ne l'écrasera donc jamais avec une nouvelle version, le seul inconvénient est que lorsque vous désinstallez le produit, les fichiers permanents ne supprimeront pas de leur emplacement cible, mais dans mon cas (généralement des fichiers DB locaux), qui est une bonne chose;!.)

Vive

[modifier] ce qui précède est vrai pour VS 2008 SP1 Haven » Je l'ai essayé sur d'autres versions, donc j'espère que vous utilisez la même version VS ou cela fonctionne pour la version que vous utilisez

[edit2] Oh, vous pouvez également utiliser la propriété "Condition" pour réaliser quelque chose de similaire ar. Si vous faites cela, assurez-vous que "Transitive" est défini sur True afin que la condition soit toujours évaluée. Je n'ai pas essayé avec les conditions, mais c'est une autre option que vous pourriez regarder. Autres que ces 2, je pense que c'est à peu près tout pour les projets de déploiement VS.

+0

Super, merci! Cela devrait être marqué comme réponse. –

+1

Les règles pour le remplacement de fichiers sont [ici] (http://msdn.microsoft.com/en-us/library/aa370531(v=VS.85).aspx). – CyberMonk

+0

Utilisation de VS2010 SP1. Ca ne marche pas pour moi ... Le fichier est remplacé même si le paramètre Permanet est réglé sur vrai !!! Il est remplacé lorsque la date/heure du fichier sur le disque est antérieure à l'heure de la création du paquet. Dans VS2010 pas SP1, il a été remplacé lorsque l'heure de la date du fichier sur le disque était plus ancienne que l'heure de la date du fichier utilisé pour créer le paquet. La mise à jour de l'heure du fichier source au 01/01/2001 m'a permis de résoudre de nombreux problèmes, mais cela ne fonctionne plus !!! –

Questions connexes