Dois-je ajouter les fichiers Visual Studio .suo et .user au contrôle de code source?


841

Les solutions Visual Studio contiennent deux types de fichiers utilisateur masqués. Le premier est le .suofichier de solution qui est un fichier binaire. L'autre est le .userfichier de projet qui est un fichier texte. Quelles sont exactement les données contenues dans ces fichiers?

Je me suis également demandé si je devais ajouter ces fichiers au contrôle de code source (Subversion dans mon cas). Si je n'ajoute pas ces fichiers et qu'un autre développeur vérifie la solution, Visual Studio créera-t-il automatiquement de nouveaux fichiers utilisateur?


9
Les fichiers .suo sont recréés automatiquement. Un excellent moyen de «rafraîchir» vos paramètres par défaut si les choses se cassent.
CodingBarfield

3
Les meilleures pratiques pour les projets Subversion et Visual Studio sont une question plus générique sur ce sujet précis. La réponse acceptée contient également un lien vers la documentation MSDN officielle, qui décrit en détail quels fichiers / répertoires de solutions / projets VS doivent être ajoutés aux systèmes de contrôle des sources et quelles parties doivent être ignorées.
Attila Csipak


Réponses:


673

Ces fichiers contiennent des configurations de préférences utilisateur qui sont en général spécifiques à votre machine, il est donc préférable de ne pas les mettre dans SCM. De plus, VS le changera presque à chaque fois que vous l'exécuterez, il sera donc toujours marqué par le SCM comme «modifié». Je n'inclus pas non plus, je suis dans un projet utilisant VS depuis 2 ans et je n'ai eu aucun problème à le faire. Le seul inconvénient mineur est que les paramètres de débogage (chemin d'exécution, cible de déploiement, etc.) sont stockés dans l'un de ces fichiers (je ne sais pas lequel), donc si vous avez une norme pour eux, vous ne pourrez pas ' publier "via SCM pour que les autres développeurs aient l'ensemble de l'environnement de développement" prêt à l'emploi ".


22
Attention, le fichier suo stocke des informations sur le chargement / déchargement du projet dans la solution.
Kugel

5
Je crois qu'il stocke les informations de débogage dans le fichier .user (au moins pour SQL Server Data Tools). De plus, lorsque vous modifiez les paramètres dans l'onglet Débogage, il n'est pas toujours persisté pour .user immédiatement (la fermeture de la solution semble fonctionner, un peu ennuyeux ... ou la modification d'un autre paramètre stocké dans le fichier .sqlproj).
jamiebarrow

87
Vous pouvez ouvrir les fichiers .user et .csproj dans n'importe quel éditeur de texte. Je viens de tester le copier-coller des paramètres de débogage pertinents du .user dans le .csproj, puis de supprimer le fichier .user. Le débogage a continué de fonctionner, lisant les paramètres corrects à partir de leur nouvel emplacement dans le fichier .csproj. Cela devrait fournir un moyen de valider les paramètres de débogage sans valider le fichier .user. Assurez-vous de les mettre dans la bonne configuration (débogage, version, etc.). Fonctionne sur ma machine! =)
Chris Nielsen

139

Vous n'avez pas besoin de les ajouter - ils contiennent des paramètres par utilisateur et les autres développeurs ne voudront pas de votre copie.


19
Si vous travaillez seul sur plusieurs machines différentes, cela en vaudrait-il la peine de les ajouter?
thepocketwade

33
Je ne le ferais pas, car il peut être fragile face à des différences de système inattendues; par exemple, si vous travaillez sur x64 au travail et x86 à la maison, cela risque d'étouffer "c: \ program files (x86)" et "c: \ program files". Je ne sais pas, mais je ne le risquerais pas.
Steve Cooper

2
Bien qu'ils contiennent des informations spécifiques à l'utilisateur, mais les informations des fichiers qui sont nouvellement ajoutés via (inclure dans le projet) se trouvent également dans le fichier .csproj, ce qui nécessite que les autres utilisateurs ajoutent manuellement toutes les ressources du projet nouvellement ajoutées. Si quelqu'un connaît une solution de contournement, veuillez l'indiquer ici.
zeppelin

69

D'autres ont expliqué pourquoi avoir les fichiers *.suoet *.usersous contrôle de source n'est pas une bonne idée.

Je vous suggère d'ajouter ces modèles à la svn:ignorepropriété pour 2 raisons:

  1. Ainsi, les autres développeurs ne se retrouveront pas avec les paramètres d'un développeur.
  2. Ainsi, lorsque vous affichez l'état ou que vous validez des fichiers, ces fichiers n'encombrent pas la base de code et n'obscurcissent pas les nouveaux fichiers que vous devez ajouter.

Où et comment la svn:ignorepropriété est-elle définie?
Peter Mortensen

@PeterMortensen, voir cette question: stackoverflow.com/questions/86049/…
JXG

Mais il y a un cas (voir cette réponse ) pour ajouter le .user, alors alors on peut choisir de ne pas ignorer seulement .suo- ou on pourrait ignorer .user, de sorte qu'il faut une décision consciente de les ajouter? Ne pensez pas, le but svn:ignoreest de marquer des choses où aucune décision consciente n'est nécessaire.
PJTraill

49

Nous ne validons pas le fichier binaire (* .suo), mais nous validons le fichier .user. Le fichier .user contient par exemple les options de démarrage pour le débogage du projet. Vous pouvez trouver les options de démarrage dans les propriétés du projet dans l'onglet "Debug". Nous avons utilisé NUnit dans certains projets et configuré le nunit-gui.exe comme option de démarrage pour le projet. Sans le fichier .user, chaque membre de l'équipe devrait le configurer séparément.

J'espère que cela t'aides.


4
Je commence également à penser que cela devrait être le cas - validez le fichier utilisateur afin que les développeurs d'une équipe utilisent les mêmes paramètres de débogage. S'ils le changent sur leur propre machine, ça va, tant que la manière standard est la version en contrôle de source.
jamiebarrow

1
D'autres ont suggéré de ne pas le faire, mais je ne sais pas quels pourraient être les dangers. Peut-être parce que le fichier repo avec des paramètres moins précis emporterait la (meilleure) copie locale de l'utilisateur? (Notre équipe utilise Mercurial, BTW.)
Jon Coombs

2
Microsoft déconseille d' ajouter le fichier .user au contrôle de code source.
DavidRR

1
Vous pouvez déplacer les paramètres de débogage vers le .csproj, voir ce commentaire
Timbo

26

Depuis que j'ai trouvé cette question / réponse via Google en 2011, j'ai pensé prendre une seconde et ajouter le lien pour les fichiers * .SDF créés par Visual Studio 2010 à la liste des fichiers qui ne devraient probablement pas être ajoutés au contrôle de version ( l'IDE les recréera). Comme je n'étais pas sûr qu'un fichier * .sdf puisse avoir une utilisation légitime ailleurs, j'ai seulement ignoré le fichier [projectname] .sdf spécifique de SVN.

Pourquoi l'assistant de conversion de Visual Studio 2010 crée-t-il un fichier de base de données SDF massif?


2
Le fichier SDF est probablement une base de données SQL Server Compact Edition .
Carl G

23

Non, vous ne devez pas les ajouter au contrôle de code source car, comme vous l'avez dit, ils sont spécifiques à l'utilisateur.

SUO (Options utilisateur de la solution): enregistre toutes les options que vous pouvez associer à votre solution afin que chaque fois que vous l'ouvrez, elle comprenne les personnalisations que vous avez apportées.

Le fichier .user contient les options utilisateur pour le projet (alors que SUO est pour la solution) et étend le nom du fichier projet (par exemple, n'importe quoi.csproj.user contient les paramètres utilisateur pour le projet everything.csproj).


20

Il semble que ce soit l'opinion de Microsoft sur la question:

Ajout (et modification) de fichiers .suo au contrôle de code source

Je ne sais pas pourquoi votre projet stocke le DebuggingWorkingDirectory dans le fichier suo. S'il s'agit d'un paramètre spécifique à l'utilisateur, vous devez envisager de le stocker dans le nom de fichier * .proj.user. Si ce paramètre est partageable entre tous les utilisateurs travaillant sur le projet, vous devez envisager de le stocker dans le fichier de projet lui-même.

Ne pensez même pas à ajouter le fichier suo au contrôle de code source! Le fichier SUO (soluton user options) est destiné à contenir des paramètres spécifiques à l'utilisateur et ne doit pas être partagé entre les utilisateurs travaillant sur la même solution. Si vous ajoutiez le fichier suo dans la base de données scc, je ne sais pas quelles autres choses dans l'IDE vous casseriez, mais du point de vue du contrôle des sources, vous casserez l'intégration scc des projets Web, le plugin Lan vs Internet utilisé par différents utilisateurs pour l'accès VSS, et vous pourriez même provoquer la rupture complète du scc (le chemin de la base de données VSS stocké dans un fichier suo qui peut être valide pour vous peut ne pas l'être pour un autre utilisateur).

Alin Constantin (MSFT)


Aussi, à partir de MSDN: Fichier Options utilisateur de solution (.Suo) . La première phrase rend l'intention de Microsoft assez claire: "Le fichier d'options utilisateur de solution (.suo) contient des options de solution par utilisateur. Ce fichier ne doit pas être archivé pour contrôler le code source."
DavidRR

19

Par défaut, Visual SourceSafe de Microsoft n'inclut pas ces fichiers dans le contrôle de code source car ce sont des fichiers de paramètres spécifiques à l'utilisateur. Je suivrais ce modèle si vous utilisez SVN comme contrôle de source.


12

Visual Studio les créera automatiquement. Je ne recommande pas de les mettre en contrôle de source. Il y a eu de nombreuses fois où le fichier SOU d'un développeur local provoquait un comportement erroné de VS sur cette boîte de développeurs. Supprimer le fichier, puis laisser VS le recréer a toujours résolu les problèmes.


Il me restait le fichier .sou et cela posait un problème de rechargement des packages. La suppression du fichier .sou a résolu le problème. Je vous remercie.
mercedes

11

Sur le site Web MSDN , il indique clairement que

Le fichier d'options utilisateur de solution (.suo) contient des options de solution par utilisateur. Ce fichier ne doit pas être archivé pour contrôler le code source .

Donc, je dirais qu'il est assez sûr d'ignorer ces fichiers lors de l'archivage de votre contrôle de source.


9

Je ne le ferais pas. Tout ce qui pourrait changer par "utilisateur" n'est généralement pas bon en contrôle de source. Répertoires .suo, .user, obj / bin


8

Ces fichiers sont des options spécifiques à l'utilisateur, qui doivent être indépendantes de la solution elle-même. Visual Studio en créera de nouveaux si nécessaire, il n'est donc pas nécessaire de les archiver pour le contrôle de code source. En effet, il serait probablement préférable de ne pas le faire car cela permet aux développeurs individuels de personnaliser leur environnement comme bon leur semble.


7

Vous ne pouvez pas contrôler par source les fichiers .user, car cela est spécifique à l'utilisateur. Il contient le nom de la machine distante et d'autres éléments dépendants de l'utilisateur. C'est un fichier lié à vcproj.

Le fichier .suo est un fichier lié à sln et il contient les "options utilisateur de la solution" (projet (s) de démarrage, position des fenêtres (ce qui est ancré et où, ce qui est flottant), etc.)

C'est un fichier binaire, et je ne sais pas s'il contient quelque chose de "lié à l'utilisateur".

Dans notre entreprise, nous ne prenons pas ces fichiers sous contrôle de source.


7

Ils contiennent les paramètres spécifiques du projet qui sont généralement attribués à un seul développeur (comme, par exemple, le projet de démarrage et la page de démarrage à démarrer lorsque vous déboguez votre application).

Il est donc préférable de ne pas les ajouter au contrôle de version, laissant VS les recréer afin que chaque développeur puisse avoir les paramètres spécifiques qu'il souhaite.


5

.user correspond aux paramètres utilisateur, et je pense que .suo correspond aux options utilisateur de la solution. Vous ne voulez pas que ces fichiers soient sous contrôle de source; ils seront recréés pour chaque utilisateur.



4

Avec Rational ClearCase, la réponse est non. Seul le projet .sln &. * Doit être enregistré dans le contrôle du code source.

Je ne peux pas répondre pour les autres fournisseurs. Si je me souviens bien, ces fichiers sont des options spécifiques "utilisateur", votre environnement.


only the .sln & .*proj should be registered- vous n'avez pas oublié beaucoup de fichiers ici?
Wolf

@Wolf outre l'évidence
Polluks

3

N'ajoutez aucun de ces fichiers au contrôle de version. Ces fichiers sont générés automatiquement avec des informations spécifiques au poste de travail, s'ils sont enregistrés dans le contrôle de version, ce qui entraînera des problèmes dans d'autres postes de travail.


2

Non, ils ne doivent pas être engagés dans le contrôle de code source car ce sont des paramètres locaux spécifiques au développeur / à la machine.

GitHub gère une liste de types de fichiers suggérés que les utilisateurs de Visual Studio doivent ignorer sur https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Pour svn, j'ai l' global-ignoreensemble de propriétés suivant :

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
débogage
* .user
* .vshost. *
* .Tss
* .dbml.layout


1

Si vous définissez vos dépendances de dir exécutables dans ProjectProperties> Debugging> Environment , les chemins sont stockés dans des fichiers '.user'.

Supposons que je mette cette chaîne dans le champ mentionné ci-dessus: "PATH = C: \ xyz \ bin" Voici comment elle sera stockée dans le fichier '.user':

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

Cela nous a beaucoup aidés en travaillant avec OpenCV. Nous pourrions utiliser différentes versions d'OpenCV pour différents projets. Autre avantage, la mise en place de nos projets sur une nouvelle machine a été très simple. Nous venons de copier les répertoires de dépendances correspondants. Donc, pour certains projets, je préfère ajouter le '.user' au contrôle de code source.

Même si cela dépend entièrement des projets. Vous pouvez prendre un appel en fonction de vos besoins.


Les liens symboliques fonctionnent également très bien à cet effet.
sɐunıɔ ןɐ qɐp

1

Comme expliqué dans d'autres réponses, les deux .suoet .userne doivent pas être ajoutés au contrôle de code source, car ils sont spécifiques à l'utilisateur / à la machine (BTW .suopour les dernières versions de VS a été déplacé dans un répertoire temporaire dédié .vs, qui doit être complètement hors contrôle de code source).

Cependant, si votre application nécessite une configuration d'environnement pour le débogage dans VS (ces paramètres sont généralement conservés dans un .userfichier), il peut être utile de préparer un exemple de fichier (en le nommant comme .user.SAMPLE) et de l'ajouter au contrôle de code source pour les références.

Au lieu d'un chemin absolu codé en dur dans un tel fichier, il est logique d'utiliser des chemins relatifs ou de s'appuyer sur des variables d'environnement, de sorte que l'échantillon peut être suffisamment générique pour être facilement réutilisable par d'autres.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.