Un .sln doit-il être engagé dans le contrôle des sources?
Est-il recommandé de valider un fichier .sln dans le contrôle de code source? Quand est-il approprié ou inapproprié de le faire?
pdate Il y avait plusieurs bons points dans les réponses. Merci pour les réponses!
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 tous ceux qui utilisent des fonctionnalités de Visual Studio comme Aller à la définition/déclaration.
Par défaut, ils ne contiennent pas de chemins absolus ni aucun autre artefact spécifique à la machine. (Malheureusement, certains outils de complément ne gèrent pas correctement cette propriété, par exemple, AMD CodeAnalyst.) Si vous faites attention à utiliser des chemins relatifs dans vos fichiers de projet (C++ et C #), ils seront indépendants de la machine aussi.
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
Oui - je pense que c'est toujours approprié. Les paramètres spécifiques à l'utilisateur se trouvent dans d'autres fichiers.
Oui, tu devrais faire ça. Un fichier de solution contient uniquement des informations sur la structure globale de votre solution. Les informations sont globales pour 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 mentionnées par d'autres personnes, il est nécessaire de rendre possible la construction en une seule étape de l'ensemble des projets.
Oui, vous devez vous engager:
- solution (* .sln),
- fichiers de projet,
- tous les fichiers source,
- fichiers de configuration d'application
- construire des scripts
Les choses que vous devez ne pas commettre sont:
- fichiers d'options utilisateur (.suo) de la solution,
- construire 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 contrôle de version (pour garantir les builds sont authentiques dans l'histoire des cvs)
Concernant les autres fichiers générés automatiquement, il y a thread séparé .
Je suis généralement d'accord pour que les fichiers de solutions soient 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 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 gros fichier de solution, soit plusieurs plus petits. Les deux présentent quelques lacunes 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 source sur lequel travailler en sélectionnant simplement les projets appropriés 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.
Oui, cela devrait faire partie du contrôle de source. Chaque fois que vous ajoutez/supprimez des projets de votre application, .sln est mis à jour et il serait bon de le contrôler sous la source. Cela vous permettrait de retirer les versions de votre code d'application 2 et de faire directement une build (si nécessaire).
Oui, vous souhaitez toujours inclure le fichier .sln, il inclut les liens vers tous les projets qui se trouvent dans la solution.
Dans la plupart des cas, c'est une bonne idée de valider des fichiers .sln pour 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.
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.
Nous le faisons parce que tout reste synchronisé. Tous les projets nécessaires sont situés ensemble, et personne n'a à se soucier d'en manquer un. Notre serveur de build (Ant Hill Pro) utilise également le sln pour déterminer les projets à construire pour une version.
Le seul cas où vous envisageriez même de ne pas le stocker dans le contrôle de source serait si vous aviez une grande solution avec de nombreux projets qui était en contrôle de source et que vous vouliez créer une petite solution avec certains des projets de la solution principale pour certains exigence transitoire privée.
Nous conservons ou fichiers de solution dans TFS Version Control. 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 génération.
Oui - Tout ce qui sert à générer votre produit doit être sous contrôle de source.
.slns est la seule chose que nous n'avons pas eu des problèmes avec dans tfs!