Dois-je ajouter les fichiers .suo et .user de Visual Studio au contrôle de source?
Les solutions Visual Studio contiennent deux types de fichiers utilisateur masqués. Le premier est le fichier solution .suo qui est un fichier binaire. L'autre est le fichier projet .user qui est un fichier texte. Quelles données ces fichiers contiennent-ils exactement?
Je me suis également demandé si je devrais ajouter ces fichiers au contrôle de 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 généralement spécifiques à votre machine. Il est donc préférable de ne pas les insérer dans le SCM. De plus, VS le changera presque chaque fois que vous l'exécuterez, il sera donc toujours marqué par le SCM comme 'changé' . Je n'inclus pas non plus, je suis dans un projet utilisant VS depuis 2 ans et pas de 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 un standard pour eux, vous ne pourrez pas " publiez-le via SCM pour que les autres développeurs disposent de tout 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 veulent pas de votre copie.
D'autres ont expliqué pourquoi le fait d'avoir les fichiers *.suo et *.user sous contrôle de code source n'est pas une bonne idée.
J'aimerais suggérer que vous ajoutiez ces modèles à la propriété svn:ignore pour 2 raisons:
- Ainsi, les autres développeurs ne finiront pas Avec les paramètres d’un développeur.
- Ainsi, lorsque vous consultez le statut ou que vous validez des fichiers , Ces fichiers n'encombreront pas la base de code et ne masqueront pas les nouveaux fichiers que vous devez ajouter.
Nous ne validons pas le fichier binaire (* .suo), mais 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 "Débogage". Nous avons utilisé NUnit dans certains projets et configuré nunit-gui.exe comme option de démarrage du 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, je pensais prendre une seconde et ajouter le lien vers 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 ( IDE les recréera). N'étant pas certain qu'un fichier * .sdf puisse avoir une utilisation légitime ailleurs, j'ai uniquement ignoré le fichier .sdf [nom du projet] spécifique de SVN.
Non, vous ne devez pas les ajouter au contrôle de source car, comme vous l'avez dit, ils sont spécifiques à l'utilisateur.
SUO (Options d’utilisateur de solution): Records toutes les options que vous pourriez associez-vous à votre solution pour que chaque fois que vous l'ouvrez, cela inclut personnalisations que vous ont fait.
Le fichier .user contient les options utilisateur du projet (tandis que SUO est pour la solution) et étend le nom du fichier du projet (par exemple, tout.csproj.user contient les paramètres utilisateur du projet tout.csproj).
Cela semble être l'opinion de Microsoft en la matière:
Ajout (et édition) de fichiers .suo au contrôle de 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 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 source! Le SUO Le fichier (options utilisateur) est destiné à contenir .__ spécifique à l’utilisateur. paramètres, et ne doit pas être partagé entre les utilisateurs travaillant sur le même Solution. Si vous souhaitez ajouter le fichier suo à la base de données scc, je ne le sais pas. savoir quelles autres choses du IDE vous foudriez, mais à partir du contrôle de code source point de vue, vous allez briser les projets Web d'intégration scc, le Lan vs Plug-in 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 le 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 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.
Visual Studio les créera automatiquement. Je ne recommande pas de les mettre dans le contrôle de source. Il est arrivé à maintes reprises que le fichier SOU d'un développeur local force VS à se comporter de manière erratique dans cette boîte de dialogue. Supprimer le fichier puis laisser VS le recréer résolvait toujours les problèmes.
Sur le site Web MSDN , il est clairement indiqué que
Le fichier d'options utilisateur de la solution (.suo) contient la solution par utilisateur options. Ce fichier ne doit pas être archivé dans le contrôle de code source.
Donc, je dirais qu'il est assez prudent d'ignorer ces fichiers tout en enregistrant des éléments dans votre contrôle de source.
Je ne voudrais 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, de sorte qu'ils n'ont pas besoin d'être archivés dans le contrôle de 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 la source des 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 contient les "options utilisateur de la solution" (projet (s) de démarrage, position de Windows (ce qui est ancré et où, ce qui flotte, etc.)
C'est un fichier binaire, et je ne sais pas s'il contient quelque chose de "utilisateur".
Dans notre société, nous ne prenons pas ces fichiers sous contrôle de source.
Ils contiennent les paramètres spécifiques au projet qui sont généralement attribués à un seul développeur (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, de laisser VS les recréer afin que chaque développeur puisse disposer des 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.
Utilisation de Rational ClearCase la réponse est non. Seuls les fichiers .sln &. * Proj doivent être enregistrés dans le contrôle de code source.
Je ne peux pas répondre pour les autres vendeurs. Si je me souviens bien, ces fichiers sont des options spécifiques à l'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 archivés sous contrôle de version, ce qui causera des problèmes sur d'autres postes de travail.
Non, ils ne doivent pas être engagés dans le contrôle de source car il s'agit de paramètres locaux spécifiques au développeur/à la machine.
GitHub conserve une liste de types de fichiers suggérés que les utilisateurs de Visual Studio peuvent ignorer à l’adresse https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Pour svn, j'ai la propriété global-ignore suivante:
* .DotSettings.User
* .onetoc2
* .suo
.contre
Web précompilé
thumbs.db
obj
poubelle
déboguer
*.utilisateur
* .vshost. *
* .tss
* .dbml.layout
Non.
Je voulais juste une vraie réponse courte, et il n'y en avait pas.
Comme expliqué dans d'autres réponses, .suo et .user ne doivent pas être ajoutés au contrôle de source, car ils sont spécifiques à l'utilisateur/à la machine (BTW .suo pour les versions les plus récentes de VS a été déplacé dans le répertoire temporaire dédié .vs, qui doit rester en dehors du code source. contrôler complètement).
Cependant si votre application nécessite une configuration d’environnement pour le débogage sous VS (ces paramètres sont généralement conservés dans le fichier .user), il peut être utile de préparer un fichier exemple (le nommant comme .user.SAMPLE) et de l’ajouter au contrôle de code source. références.
Au lieu d'utiliser un chemin absolu codé en dur dans un tel fichier, il est judicieux d'utiliser des noms relatifs ou de s'appuyer sur des variables d'environnement, de sorte que l'échantillon peut être suffisamment générique pour pouvoir être facilement réutilisé par d'autres.