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?

visual-studio version-control Ben Mills
la source
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
3
pour * .suo, veuillez voir ici: msdn.microsoft.com/en-us/library/bb165909.aspx
smwikipedia
Quels types de fichiers Visual C ++ doivent être validés pour le contrôle de version?
phuclv

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 ".

Fabio Ceconello
la source
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.

Steve Cooper
la source
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.
JXG
la source
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.

Thomas
la source
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?

Stephen
la source
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).

JRoppert
la source
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)

Scott W
la source
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.

cori
la 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.

Limier
la source
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.

Farax
la 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

ScaleOvenStove
la source
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.

bienfaiteur
la source
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.

ugasoft
la 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.

massimogentilini
la source
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.

pseudo
la source
5

Non.

Je voulais juste une vraie réponse courte, et il n'y en avait pas.

Pablo Carrasco Hernández
la source
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.

titanae
la source
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.

Amila
la source
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

Stephen Kennedy
la source
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.

adheen
la source
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.

AntonK
la source