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


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

Je me demandais aussi si je devrais ajouter ces fichiers au contrôle de la 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?


763
2017-09-16 13:40


origine


Réponses:


Ces fichiers contiennent des configurations de préférences utilisateur généralement spécifiques à votre machine, il est donc préférable de ne pas les mettre dans SCM. En outre, VS le changera presque chaque fois que vous l'exécuterez, ainsi il sera toujours marqué par le SCM comme 'changé'. Je ne comprends pas non plus, je suis dans un projet utilisant VS depuis 2 ans et n'ai eu aucun problème à le faire. Le seul ennui mineur est que les paramètres de débogage (chemin d'exécution, cible de déploiement, etc.) sont stockés dans un de ces fichiers (ne sait pas lequel), donc si vous avez un standard pour eux, vous ne serez pas en mesure de ' publiez-le via SCM pour que les autres développeurs puissent utiliser l'ensemble de l'environnement de développement.


615
2017-09-16 14:08



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


128
2017-09-16 13:42



D'autres ont expliqué pourquoi avoir le *.suo et *.user les fichiers sous le contrôle de la source n'est pas une bonne idée.

Je voudrais suggérer que vous ajoutiez ces modèles à la svn:ignore propriété pour 2 raisons:

  1. Alors les autres développeurs ne vont pas se retrouver avec les paramètres d'un développeur.
  2. Donc, lorsque vous affichez le statut, ou commettez fichiers, ces fichiers n'encombrent pas la base de code et obscurcissent les nouveaux fichiers que vous devez ajouter.

64
2017-09-17 14:55



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


46
2017-09-16 13:46



Depuis que j'ai trouvé cette question / réponse par 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 simplement ignoré le fichier [nom de projet] .sdf spécifique de SVN.

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


25
2017-07-04 14:21



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

SUO (Options de l'utilisateur de la solution): enregistrements   toutes les options que vous pourriez   associer à votre solution afin que   chaque fois que vous l'ouvrez, cela inclut   personnalisations que vous   ont fait.

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


22
2017-09-16 13:55



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


17
2017-09-16 13:43



Cela semble être l'opinion de Microsoft à ce sujet: http://social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f

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

Ne pensez même pas à ajouter le fichier suo au contrôle de la source! Le SUO   Le fichier (options d'utilisateur de Soluton) est destiné à contenir des   paramètres, et ne devrait pas être partagé entre les utilisateurs travaillant sur le même   Solution. Si vous ajoutez le fichier suo dans la base de données scc je ne sais pas   savoir quelles autres choses dans l'EDI vous casser, mais à partir du contrôle de la source   point de vue que vous allez briser l'intégration des projets web scc, le Lan vs   Plugin Internet utilisé par différents utilisateurs pour l'accès VSS, et vous pourriez   même provoquer la rupture du scc (chemin de la base de données VSS stockée dans   fichier suo qui peut être valide pour vous peut ne pas être valide pour un autre utilisateur).

Alin Constantin (MSFT)


16
2017-09-16 13:52



Visual Studio les créera automatiquement. Je ne recommande pas de les mettre dans le contrôle de la source. Il y a eu de nombreuses occasions où le fichier SOU d'un développeur local faisait que VS se comportait de manière erratique sur cette boîte de développeurs. Supprimer le fichier et laisser VS le recréer a toujours corrigé les problèmes.


11
2017-09-16 13:42