Un fichier .sln doit-il être placé dans le contrôle de la source ?

Question

Est-ce une bonne pratique de livrer un fichier .sln au contrôle de la source ? Quand est-il approprié ou inapproprié de le faire ?

Mise à jour Plusieurs bons points ont été soulevés dans les réponses. Merci pour les réponses !

Answer 1

Je pense qu'il est clair, d'après les autres réponses, que les fichiers de solution sont utiles et devraient être engagés, même s'ils ne sont pas utilisés pour les constructions officielles. Ils sont pratiques à avoir pour tous ceux qui utilisent les fonctionnalités de Visual Studio comme 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 maintiennent pas correctement cette propriété, par exemple, AMD CodeAnalyst). Si vous prenez soin d'utiliser des chemins relatifs dans vos fichiers de projet (C++ et C#), ils seront également indépendants de la machine.

La question la plus utile est probablement : 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

Answer 2

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

Answer 3

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

Il ne contient pas de paramètres spécifiques à l'utilisateur.

Answer 4

Vous devriez vraiment l'avoir. En plus des raisons mentionnées par d'autres personnes, il est nécessaire pour rendre possible la construction en une seule étape de l'ensemble des projets.

Answer 5

Je suis généralement d'accord pour dire que les fichiers de solutions doivent être enregistrés, mais dans l'entreprise pour laquelle je travaille, nous avons procédé différemment. Nous avons un référentiel assez important et les développeurs travaillent sur différentes parties du système de temps en temps. Pour soutenir la façon dont nous travaillons, nous aurions soit un grand fichier de solution, soit plusieurs petits. Ces deux solutions présentent quelques inconvénients 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 module externe permet à chaque développeur de choisir un sous-ensemble de l'arbre des sources sur lequel il peut travailler en sélectionnant simplement 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 doit 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 afin de garantir les normes de l'entreprise.

De plus, nous utilisons le plug-in pour supporter diverses politiques de check-in, ce qui empêche généralement les utilisateurs de soumettre du code défectueux/non conforme au dépôt.