Merci pour votre soutien

Pratique exemplaire: environnement collaboratif, répertoire Bin, SVN

Quelles sont les meilleures pratiques pour vérifier les répertoires BIN dans un environnement de développement collaboratif utilisant SVN? Les références de niveau projet doivent-elles être exclues de l'archivage? Est-il plus facile d'ajouter simplement tous les répertoires bin?

Je développe beaucoup de sites DotNetNuke et il me semble que dans un environnement multi-développeurs, c'est toujours une tâche énorme que de configurer l'environnement correctement.

Le but ultime (bien sûr) est d'avoir un nouveau développeur qui vérifie le tronc de SVN, restaure la base de données DNN et fait tout simplement 'travailler' ...

0
ajouté édité
Vues: 1

5 Réponses

Tout assembly attendu dans le GAC doit rester dans le GAC. Cela inclut System.web.dll ou toute autre DLL tierce que vous allez déployer dans le GAC en production. Cela signifie qu'un nouveau développeur devrait installer ces assemblages.

Toutes les autres assemblées tierces doivent être des références via un chemin relatif. Ma structure typique est:

-Project
--Project.sln
--References
---StructureMap.dll
---NUnit.dll
---System.Web.Mvc.dll
--Project.Web
---Project.Web.Proj
---Project.Web.Proj files
--Project
---Project.Proj
---Project.Proj files

Project.Web et Project référencent les assemblys dans le dossier racine / Références relativement. Ces fichiers .dll sont vérifiés dans subversion.

En dehors de cela, * / bin * / bin / * obj devrait être dans votre chemin global ignorer.

Avec cette configuration, toutes les références aux assemblages sont soit à travers le GAC (donc devrait fonctionner sur tous les ordinateurs), ou par rapport à chaque projet au sein de votre solution.

0
ajouté

Maven aide beaucoup avec ce problème quand je suis en train de coder Java. Nous validons le pom.xml dans le scs et le référentiel maven contient toutes nos dépendances. Pour moi, cela semble être une bonne façon de le faire.

0
ajouté

Nous suivons la pratique consistant à utiliser un répertoire de fournisseurs qui contient tous les en-têtes et les binaires spécifiques au fournisseur. L'objectif est que tout le monde devrait être capable de construire le produit juste en le vérifiant et en exécutant un script de construction de haut niveau.

0
ajouté

Est-ce une question spécifique .Net?

Généralement, la meilleure pratique consiste à ne pas archiver les éléments générés automatiquement à partir de fichiers déjà présents dans SCM. Tout cela est idéalement créé dans le cadre de votre processus de construction automatique.

Si le répertoire bin auquel vous faites référence contient des fichiers binaires tiers plutôt qu'une version de votre projet, ignorez (downvote?) Ce conseil.

0
ajouté

Tree Surgeon is a great tool which creates an empty .NET development tree. It has been tweaked over years of use and implements lots of best practices.

0
ajouté