web-dev-qa-db-fra.com

Meilleures pratiques pour les projets Subversion et Visual Studio

J'ai récemment commencé à travailler sur divers projets C # dans Visual Studio dans le cadre d'un plan pour un système à grande échelle qui sera utilisé pour remplacer notre système actuel qui est construit à partir d'un mélange de divers programmes et scripts écrits en C et Perl. Les projets sur lesquels je travaille maintenant ont atteint une masse critique pour s'engager dans Subversion. Je me demandais ce qui devait et ne devait pas être validé dans le référentiel pour les projets Visual Studio. Je sais que cela va générer divers fichiers qui ne sont que des build-artefacts et n'ont pas vraiment besoin d'être validés, et je me demandais si quelqu'un avait des conseils pour utiliser correctement SVN avec Visual Studio. Pour le moment, j'utilise un serveur SVN 1.6 avec Visual Studio 2010 beta. Tout conseil, avis sont les bienvenus.

c#visual-studio-2010svnsvnignore
60
Alex Marshall

Selon MSDN :

Vous pouvez ajouter les fichiers suivants au contrôle de code source de Visual Studio:

  • Fichiers de solution (*.sln).
  • Fichiers de projet, par exemple, *.csproj, *.vbproj des dossiers.
  • Fichiers de configuration d'application, basés sur XML, utilisés pour contrôler le comportement au moment de l'exécution d'un projet Visual Studio.

Les fichiers que vous ne pouvez pas ajouter au contrôle de code source sont les suivants:

  • Fichiers d'options utilisateur de la solution (*.suo).
  • Fichiers d'options utilisateur du projet, par exemple, *.csproj.user, *.vbproj.user des dossiers.
  • Fichiers d'informations Web, par exemple, *.csproj.webinfo, *.vbproj.webinfo, qui contrôle l'emplacement racine virtuel d'un projet Web.
  • Créez des fichiers de sortie, par exemple, *.dll et *.exe des dossiers.
89
Justin R.

Je suggère d'utiliser AnkhSVN - un plugin de contrôle de source Subversion pour Visual Studio 2008/2010.

Vous pouvez l'utiliser pour effectuer votre ajout et validation initiaux de la solution, des projets et des sources dans le référentiel et il n'ajoutera aucun des artefacts de génération. Il n'ajoutera rien généré par votre build, uniquement les fichiers référencés par votre solution. S'il y a d'autres morceaux dont vous avez besoin qui ne sont pas dans votre solution, vous pouvez les ajouter par la suite.

16
GraemeF

Mettez les fichiers suivants dans le contrôle de version:

  • .dsw (espace de travail VS6)
  • .dsp (projet VS6)
  • .sln (solution VS)
  • . * proj (fichiers VS Project de différents types)
  • bien sûr, vos fichiers source et autres artefacts que vous créez

Ne pas mettre les fichiers suivants en contrôle de version:

  • .ncb (quelque chose à voir avec la navigation ou l'intelligence)
  • .suo (paramètres de l'espace de travail utilisateur comme le placement des fenêtres, etc. - je pense)
  • .user (paramètres de projet utilisateur comme les points d'arrêt, etc. - je pense)

En outre, ne placez aucun fichier objet, exécutable, fichier généré automatiquement (comme les en-têtes qui pourraient être générés).

Comme pour les exécutables et autres fichiers générés - il peut y avoir une exception si vous voulez pouvoir archiver les versions. Cela pourrait être une bonne idée, mais vous voudrez probablement gérer cela un peu différemment et éventuellement à un endroit différent de votre code source. Si vous faites cela, archivez également vos fichiers .pdb afin de pouvoir déboguer plus tard. vous souhaiterez peut-être utiliser un serveur de symboles pour stocker vos symboles archivés (voir Outils de débogage pour Windows pour le serveur de symboles et sa documentation).

Voici ma liste de fichiers spécifiques à VS que j'exclus de SVN:

Ankh.Load
*.projdata
*.pdb
*.positions
*proj.user
*proj.*.user
*.ncb
*.suo
*.plg
*.opt
*.ilk
*.pch
*.idb
*.clw
*.aps
15
Michael Burr

Niveau de solution:

  • ajouter le .sln fichier de solution
  • ignore le .suo fichier d'options utilisateur de la solution

Niveau projet:

  • ajouter le .csproj, .vbproj (et c ++ proj?) fichiers
  • ignore le .csproj.user, .vbproj.user des dossiers
  • ignorer le répertoire bin
  • ignorer le répertoire obj
  • ignorer tous les fichiers/répertoires générés pendant l'exécution (c.-à-d. journaux)

Si vous utilisez des compléments VS, ils peuvent générer des fichiers qui doivent également être ignorés (par exemple, ReSharper génère .resharper et .resharper.user des dossiers).

Les éléments ignorés peuvent être ignorés explicitement par nom de fichier (c'est-à-dire. MyProject.csproj), ou par un caractère générique (par exemple. *.csproj.user).

Une fois que vous avez configuré vos ignorés, vérifier une copie propre de votre source, puis la construction ne doit alors afficher aucune modification (c'est-à-dire aucun nouveau fichier non versionné).

11
adrianbanks

Je voudrais inclure manuellement tous les fichiers que je pense que je ne devrais pas contrôler la version.

Mon modèle global d'ignorance est:

.dll .pdb .exe .cache .webinfo .snk bin obj debug _Resharper .user resharper

5
Andre Gallo

Dans le cas où vous utilisez ignorer la liste, SVN est sensible à la casse. N'oubliez donc pas d'ignorer les dossiers bin et Bin séparément.

De plus, j'avais une question .. pourquoi faut-il beaucoup de temps pour actualiser l'icône d'état? Parfois, cela devient très déroutant.

2
Manoj

Voir Mercurial .hgignore pour les projets Visual Studio 2008 pour une liste d'ignorance Mercurial. Je ne connais pas la syntaxe de la liste d'ignorance SVN, mais ce fil a quelques bonnes listes de ce qu'il faut ignorer dans Visual Studio.

1
CAD bloke