Un .sln devrait-il être engagé dans le contrôle de la source?

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

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

Je pense qu’il est clair d’après les 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 toute personne utilisant les fonctionnalités de Visual Studio telles que Aller à la définition / Déclaration.

Par défaut, ils ne contiennent aucun chemin absolu ni aucun autre artefact spécifique à la machine. (Malheureusement, certains outils complémentaires ne gèrent pas correctement cette propriété, par exemple, AMD CodeAnalyst.) Si vous veillez à utiliser des chemins d’access 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 

Oui, je pense que c’est toujours approprié. Les parameters spécifiques à l’utilisateur se trouvent dans d’autres fichiers.

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.

Vous devriez certainement l’avoir. Outre les raisons évoquées par d’autres personnes, il est nécessaire de créer une seule étape pour l’ensemble des projets.

Je conviens généralement que les fichiers de solution doivent être archivés, cependant, dans l’entreprise pour laquelle nous travaillons, nous avons fait quelque chose de différent. Nous avons un repository assez important et les développeurs travaillent de temps en temps sur différentes parties du système. Pour soutenir notre façon de travailler, nous aurions soit un grand fichier de solution, soit plusieurs plus petits. Les deux ont quelques défauts et nécessitent un travail manuel sur la partie 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 source, en sélectionnant simplement les projets pertinents dans le référentiel. Le plugin génère alors 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 parameters pour garantir les normes de l’entreprise.

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

Oui, les choses que vous devriez commettre sont:

  • solution (* .sln),
  • fichiers de projet,
  • tous les fichiers sources,
  • fichiers de configuration de l’application
  • construire des scripts

Les choses que vous ne devriez pas commettre sont:

  • fichiers d’options de l’utilisateur de la solution (.suo),
  • construire des fichiers générés (par exemple en utilisant un script de compilation) [Edit:] – uniquement si tous les scripts et outils de construction nécessaires sont disponibles sous contrôle de version (pour garantir l’authenticité des builds dans l’historique de cvs)

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

Oui, cela devrait faire partie du contrôle de source. Lorsque vous ajoutez / supprimez des projets de votre application, .sln serait mis à jour et il serait bon de le placer sous contrôle de code source. Cela vous permettrait de récupérer vos versions de code d’application 2 et de créer directement une version (si nécessaire).

Oui, vous souhaitez toujours inclure le fichier .sln, il inclut les liens vers tous les projets de la solution.

Dans la plupart des cas, il est conseillé de valider les fichiers .sln pour le contrôle de 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.

Nous faisons parce que tout est synchronisé. Tous les projets nécessaires sont regroupés, et personne ne doit s’inquiéter de l’absence d’un. Notre serveur de compilation (Ant Hill Pro) utilise également le sln pour déterminer les projets à construire pour une version.

Le seul cas où vous envisageriez de ne pas le stocker dans le contrôle de code source serait si vous aviez une grande solution avec de nombreux projets qui étaient sous 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.

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

Nous conservons ou solutionnons les fichiers dans TFS Version Control. Mais comme la solution principale est vraiment volumineuse, la plupart des développeurs ont une solution personnelle ne contenant que ce dont ils ont besoin. Le fichier de solution principal est principalement utilisé par le serveur de génération.

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.

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

1) Créer un nouveau projet dans VS
2) Cliquez avec le bouton droit sur la solution dans l’Explorateur de solutions, sélectionnez Ajouter au contrôle de code source.

Le sln est-il ajouté au contrôle de source? C’est ta réponse.