Un .sln doit-il être affecté au contrôle de code source?


101

Est-il recommandé de valider un fichier .sln dans le contrôle de code source? Quand est-il approprié ou inapproprié de le faire?

Mise à jour Il y avait plusieurs points positifs dans les réponses. Merci pour les réponses!


21
Je crois que c'est le fichier .SUO que vous ne voulez PAS valider.
apandit le

Juste pour mémoire, je crois que les listes de tâches (si vous les utilisez) sont stockées dans le fichier .SUO ... Donc, même si vous ne voulez pas les confier au contrôle de code source, vous ne voudrez peut-être pas les `` simplement supprimer '' comme cruft étranger.
Benjol

Réponses:


69

Je pense qu'il ressort clairement des autres réponses que les fichiers de solution sont utiles et doivent être validés, même s'ils ne sont pas utilisés pour les versions officielles. Ils sont pratiques pour quiconque utilise les fonctionnalités de Visual Studio telles que Go To Definition / Declaration.

Par défaut, ils ne contiennent pas de chemins absolus ou d'autres artefacts spécifiques à la machine. (Malheureusement, certains outils complémentaires ne gèrent pas correctement cette propriété, par exemple AMD CodeAnalyst.) Si vous prenez soin d'utiliser des chemins relatifs dans vos fichiers de projet (à la fois C ++ et C #), ils seront indépendants de la machine. aussi.

La question la plus utile est probablement la suivante: quels fichiers devez-vous exclure? Voici le contenu de mon fichier .gitignore pour mes projets VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(La dernière entrée concerne uniquement le profileur AMD CodeAnalyst.)

Pour VS 2010, vous devez également exclure les éléments suivants:

ipch/
*.sdf
*.opensdf

2
J'ai également une règle d'ignorer pour les résultats des tests unitaires. Certaines personnes peuvent les enregistrer mais je n'aime pas le désordre
Matthew Whited

9
+1 - Personnellement, je ne commets rien de ce qui est construit, donc bin / and obj /
Steven Evers

Je ne commets que des fichiers .sln contenant plus d'un projet
Justin

2
voici ma subversion Global ignore patter: * .vsmdi * .suo * / [Bb] dans [Bb] dans * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Merritt

Voici un fichier .gitignore communément partagé qui comprend des fichiers temporaires, des résultats de génération et des fichiers générés par les modules complémentaires Visual Studio populaires.
Lauren Van Sloun

58

Oui - je pense que c'est toujours approprié. Les paramètres spécifiques à l'utilisateur se trouvent dans d'autres fichiers.


3
Certainement le .sln a des références aux fichiers .prj (projets)
déplante

20

Oui, vous devriez le faire. Un fichier de solution contient uniquement des informations sur la structure globale de votre solution. Les informations sont globales à la solution et sont probablement communes à tous les développeurs de votre projet.

Il ne contient aucun paramètre spécifique à l'utilisateur.


13

Vous devriez certainement l'avoir. Outre les raisons que d'autres personnes ont mentionnées, il est nécessaire de rendre possible la construction d'une étape de l'ensemble des projets.


8

Je suis généralement d'accord pour dire que les fichiers de solution doivent être archivés, cependant, dans l'entreprise pour laquelle je travaille, nous avons fait quelque chose de différent. Nous avons un référentiel assez volumineux et les développeurs travaillent de temps en temps sur différentes parties du système. Pour soutenir la façon dont nous travaillons, nous aurions soit un gros fichier de solution, soit plusieurs plus petits. Les deux ont quelques défauts et nécessitent un travail manuel de la part des développeurs. Pour éviter cela, nous avons créé un plug-in qui gère tout cela.

Le plug-in permet à chaque développeur d'extraire un sous-ensemble de l'arborescence des sources sur lequel travailler simplement en sélectionnant les projets pertinents dans le référentiel. Le plugin génère ensuite un fichier de solution et modifie les fichiers de projet à la volée pour la solution donnée. Il gère également les références. En d'autres termes, tout ce que le développeur a à faire est de sélectionner les projets appropriés, puis les fichiers nécessaires sont générés / modifiés. Cela nous permet également de personnaliser divers autres paramètres pour garantir les normes de l'entreprise.

De plus, nous utilisons le plug-in pour prendre en charge diverses politiques d'enregistrement, ce qui empêche généralement les utilisateurs de soumettre du code défectueux / non conforme au référentiel.


On dirait que cela pourrait être la réponse à l'une de mes longues questions sans réponse ( stackoverflow.com/questions/1490728/… ), une chance d'obtenir une copie de ce plugin?
Benjol

@Benjol: Désolé, non c'est un outil interne. En plus des fonctionnalités ci-dessus, il s'intègre également à un certain nombre d'autres systèmes internes, il est donc très spécifique à la façon dont nous gérons les choses. Si vous n'avez besoin que de la partie solution / projet des choses, ce n'est pas si difficile à mettre en œuvre.
Brian Rasmussen

OK, juste une chose, dans votre «grande solution» avez-vous des références de projet ou des références de fichiers? Et si un développeur ajoute une nouvelle référence à un fichier / projet, le plugin effectue-t-il la conversion appropriée avant de s'enregistrer? Et comment gérez-vous les dépendances que le développeur n'a pas choisi d'extraire?
Benjol

8

Oui, les choses que vous devriez commettre sont:

  • solution (* .sln),
  • fichiers de projet,
  • tous les fichiers source,
  • fichiers de configuration d'application
  • construire des scripts

Les choses que vous ne devriez pas commettre sont:

  • fichiers d'options utilisateur de la solution (.suo),
  • build des fichiers générés (par exemple en utilisant un script de build) [Edit:] - uniquement si tous les scripts et outils de build nécessaires sont disponibles sous le contrôle de version (pour s'assurer que les builds sont authentiques dans l'historique des cvs)

En ce qui concerne les autres fichiers générés automatiquement, il existe un thread distinct .


1
Je ne suis pas d'accord avec «tout fichier généré automatiquement».
Mehrdad Afshari

@Mehrdad pensez-vous que les fichiers Intelisense devraient également être validés?
Edison Gustavo Muenz

1
@Edison: Non. Je fais référence aux fichiers source générés automatiquement comme le contexte de données LINQ to SQL, par exemple.
Mehrdad Afshari

2
Les fichiers Formname.Designer.cs ne sont-ils pas considérés comme générés automatiquement?
jasonh

1
Ce que je voulais dire, c'était des fichiers générés pendant la construction. Je trouve cela souvent - quelqu'un commet un fichier qui est construit automatiquement, puis SVN signale un changement juste parce qu'un commentaire a été changé.
Groo

5

Oui, cela devrait faire partie du contrôle de code source. Chaque fois que vous ajoutez / supprimez des projets de votre application, .sln serait mis à jour et il serait bon de l'avoir sous contrôle de code source. Cela vous permettrait de récupérer les versions de votre code d'application 2 et de faire directement une compilation (si nécessaire).


5

Dans la plupart des cas, il est judicieux de valider les fichiers .sln dans le contrôle de code source.

Si vos fichiers .sln sont générés par un autre outil (tel que CMake), il est probablement inapproprié de les placer dans le contrôle de code source.


4

Oui, vous voulez toujours inclure le fichier .sln, il inclut les liens vers tous les projets qui sont dans la solution.


2

Nous le faisons parce que tout est synchronisé. Tous les projets nécessaires sont regroupés et personne n'a à craindre d'en manquer un. Notre serveur de build (Ant Hill Pro) utilise également le sln pour déterminer les projets à construire pour une version.


2

Nous mettons généralement tous nos fichiers de solutions dans un répertoire de solutions. De cette façon, nous séparons un peu la solution du code et il est plus facile de choisir le projet sur lequel je dois travailler.


1

Le seul cas où vous envisageriez même de ne pas le stocker dans le contrôle de code source serait si vous aviez une grande solution avec de nombreux projets qui était en contrôle de code source, et que vous vouliez créer une petite solution avec certains des projets de la solution principale pour certains exigence transitoire privée.


1

Oui - Tout ce qui est utilisé pour générer votre produit doit être sous contrôle de code source.


1

Nous conservons les fichiers de solution ou dans le contrôle de version TFS. Mais comme la solution principale est vraiment volumineuse, la plupart des développeurs ont une solution personnelle contenant uniquement ce dont ils ont besoin. Le fichier de solution principal est principalement utilisé par le serveur de construction.


0

.slns est la seule chose avec laquelle nous n'avons pas eu de problèmes dans tfs!


1
C'est drôle ... Les SLN étaient les seuls fichiers que j'ai jamais eu à réparer ... mais les problèmes étaient causés par les développeurs qui ne faisaient pas attention aux fusions.
Matthew Whited
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.