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

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?

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

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.

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.

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.

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?

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

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)

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.

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.

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.

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

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.

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.

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.

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

Non.

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

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.

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.

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

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.

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.