Meilleures pratiques pour stocker un site Web ASP.NET dans Subversion?

Question

Je travaille actuellement sur un projet ASP.NET avec plusieurs développeurs utilisant Subversion pour la distribution de code, mais il est franchement totalement raté pour le moment. La personne qui a configuré le dépôt Subversion a inclus des fichiers de configuration spécifiques à son ordinateur, des répertoires bin \ * et d'autres choses de ce genre. Moi, étant le gars qui doit vérifier ce référentiel et le faire fonctionner sur mon ordinateur, je suis assez frustré par cela car il m'a fallu du temps pour le trier du tout pour le compiler du tout. Maintenant, je pense à écrire un document pour les directives de Subversion à envoyer au responsable technique de mon entreprise afin que nous puissions normaliser le processus et éviter ce genre de problèmes.

Ce que je cherche, c'est d'entrer les lignes directrices. Voici le début pour eux, et nous espérons que nous pouvons faire quelque chose de bien de celui-ci:

La structure du fichier doit être mis en place pour avoir des bibliothèques tierces vérifiées dans l'extérieur des répertoires de sortie de construction (car ils ne seront pas inclus dans le référentiel.) Le nom de ce répertoire doit être "Bibliothèques".

Aucun fichier spécifique à l'ordinateur ne doit être inclus dans Subversion. Par conséquent, seul un modèle de Web.config est archivé, ce qui est personnalisé par les développeurs en fonction de leur machine. Ce comportement est inclus dans Visual Studio 2010 par défaut et les fichiers de configuration individuels (Web.Local.config) ont automatiquement le modèle (Web.config) appliqué. Le fichier de configuration local ne doit toujours pas être inclus dans Subversion, à condition qu'il s'applique à une machine spécifique. Les fichiers de solution et de projet ne doivent contenir aucun chemin absolu.

Une liste d'ignorés doit être configurée. Commencez par:

' 
*.user 
obj 
' 

Exemple de structure de fichier pour un site Web ASP.NET 2.0 avec une bibliothèque de classe spécifique au site Web et une bibliothèque tiers:

' 
/trunk/ 
    Libraries/ 
     ThirdParty.dll 
    MyClassLibrary/ 
     bin/ [Ignore] 
     obj/ [Ignore] 
     Properties/ 
      AssemblyInfo.cs 
     SomeClass.cs 
     MyClassLibrary.csproj 
      - Holds references to third-party libraries. For example: 
       ../Libraries/ThirdParty.dll 
    MyWebApplication/ 
     bin/ 
      ThirdParty.dll [Ignore; copied by build process] 
      ThirdParty.dll.refresh 
       - Contains "../Libraries/ThirdParty.dll" 
     Default.aspx 
     Default.aspx.cs 
     Web.config [Ignore] 
     Web.config.template 
    MySolution.sln 
     - Holds list of projects. 
     - Has reference information for projects. 
' 

Une alternative à l'utilisation Web.config.template serait être d'inclure un fichier Local.config de Web.config, mais cela pourrait être moins flexible. Lors de l'utilisation d'un projet d'application Web plutôt que d'un projet de site Web, les références seront stockées dans le fichier de projet au lieu de dans les fichiers .refresh, de sorte que le bin/dossier sera ignoré.

Quelqu'un peut-il voir des erreurs dans les suggestions ci-dessus? Quelque chose manque? Quelqu'un at-il des suggestions pour la liste des ignorés? Je viens de commencer avec quelques entrées pour le moment.

Answer 1

Je pense que vous êtes une bonne étape sur le chemin. Mais pourquoi ne pas mettre un ignorer sur le dossier bin entier dans/MyWebApplication, au lieu des fichiers? Vous n'ajouteriez pas votre sortie de build à subversion, n'est-ce pas? Je considérerais certainement que c'est une mauvaise pratique.

De plus, si possible, vous pouvez ajouter le fichier web.config à la subversion, mais dans l'élément de référence un nouveau fichier avec appsettings: par exemple

<appSettings file="local.config"> 

Alors que le fichier local.config être ignoré par svn. Voilà comment je fonctionne toujours.Bien sûr, cela ne fonctionne que si chaque paramètre configurable est dans appSettings (une des raisons pour lesquelles je n'aime pas le modèle de fournisseur, car tous les fournisseurs doivent obtenir des chaînes de connexion d'un élément connectionString, et vous ne pouvez pas les reconfigurer prendre une chaîne de connexion de appsettings)

Edit: troethom m'a éclairé et a fait remarquer, que vous pouvez également remplacer les paramètres de configuration connectionString dans un fichier séparé

<connectionStrings configSource="ConnectionStrings.config"/>. 

donc, la chose que je ferais est pla ce le fichier web.config réel sous contrôle subversion, mais laissez les autres fichiers qui remplacent les paramètres localement être ignorés par svn.

Answer 2

Vous devez ajouter les fichiers .refresh; pas les vraies DLL.

Le système de projet Visual Studio envoie une liste de fichiers à ajouter au contrôle de source aux fournisseurs SCC. AnkhSVN est un fournisseur SCC Subversion qui utilise cette information pour suggérer d'ajouter ces fichiers (et pas les autres fichiers).

VisualSVN et les autres clients Subversion qui ne consultent que les extensions de fichier n'obtiennent pas cette information d'ASP.Net.

(Remarque: si vous supprimez le fichier .Refresh, Visual Studio ajoutera la DLL à la liste des fichiers qui doivent être engagés)