Conservez-vous des dossiers bin ou de débogage (et des dll) dans votre TFS?

Question rapide à propos de TFS - Les gars, archivez-vous les dossiers bin / debug dans TFS? (si oui, pourquoi?) Étant donné que le contenu de ces dossiers est généré dynamiquement, est-il préférable de les laisser de côté afin que le programmeur ne rencontre pas de problèmes de lecture seule?

En règle générale, le contrôle de source est mieux utilisé pour la source uniquement et les fichiers générés ne sont pas source.

Il y a des exceptions. Parfois (en utilisant Visual Studio), vous souhaiterez peut-être conserver le fichier .pdb pour lire les mini-vidages. Parfois, vous ne pouvez pas dupliquer une chaîne d'outils, de sorte que vous ne pouvez pas nécessairement recréer avec précision les fichiers générés. Dans ces cas, vous êtes principalement intéressé à le faire pour les logiciels publiés, pas pour chaque changement VCS, et dans tous les cas, ceux-ci peuvent facilement résider dans des dossiers versionnés. (Ce sont généralement des fichiers binaires, de toute façon, et n'ont pas de changements compréhensibles d'une version à l'autre, et ne bénéficient pas beaucoup de la présence dans un VCS.)

Réponse simple? Non, ne fais pas ça! Je ne peux pas penser à beaucoup de raisons de ne pas le faire, mais aucune raison pour laquelle vous voudriez.

La seule fois où je peux penser que vous archiveriez une dll, c'est si c'est à partir d'une bibliothèque tierce que vous ne vous attendez pas à ce que tous les développeurs aient installé pour construire. Mais même encore, cela ne se trouve pas dans le dossier bin.

Cela étant dit, je travaillais dans une entreprise qui exigeait que chaque package de déploiement soit placé sous contrôle de source, mais c'était pour que nous puissions suivre les différentes versions que nous avions données à notre client et que nous pouvions facilement annuler si nous le devions.

Nous n'archivons pas le dossier bin dans TFS. Comme vous l'avez probablement remarqué, si vous faites cela, chaque fois qu'un développeur crée la solution, il extrait le dossier bin. Pas bon. Cependant, il existe des bibliothèques dont le projet a besoin pour compiler et exécuter, et notre règle est que tout projet doit pouvoir être ouvert à partir du contrôle de code source, et il doit être compilé et exécuté. Donc, ce que nous faisons est de créer un dossier "BinRef" pour toutes les DLL auxquelles le projet doit avoir une référence et de créer les références du projet à la copie dans le dossier BinRef. Le dossier BinRef est archivé dans TFS.

L'autre avantage de cette approche est que BinRef est toujours au niveau racine du projet Web. Si mon projet existe C:\Projects\Marcie\SomeProjectCategory\ProjectAet que je crée une référence à une DLL qui s'y trouve C:\DLLsThatILike, la référence finira par ressembler à quelque chose comme

\..\..\..\NiceThing.dll

. Vous pouvez conserver vos fichiers de projet dans C:\ProjectAce qui signifie que la référence du projet à NiceThing va exploser sur votre machine. J'espère que les gens ne font pas de références de cette façon, mais je l'ai vu se produire.

Nous archivons le contenu des répertoires bin dans le cadre de notre processus de demande de changement. Pour éviter les problèmes de lecture seule, nous copions le contenu dans un dossier séparé et les archivons à partir de là. Notre politique d'entreprise exige que tous les fichiers binaires qui entrent en production soient enregistrés séparément de la source. Ce n'est pas la meilleure solution mais cela fonctionne et cela nous donne les fichiers exacts qui sont en production.

J'hésite à vérifier tout fichier non textuel dans le contrôle de code source. Surtout ceux qui devraient être générés par le développeur. J'aime aussi garder d'autres fichiers binaires, tels que des images et des PDF, zippés et stockés ailleurs pour chaque balise / version.

Non, mais notre outil de contrôle de projet interne le fait automatiquement, ce qui me dérange énormément.

Ma solution est de marquer tous les fichiers dans la version et le débogage comme accessibles en écriture et lorsque TFS se plaint, je lui dis d'ignorer les fichiers, donc je n'ai jamais de problème avec un build échoué.

J'évite de les entrer en contrôle de source. Ce sont des informations redondantes, les binaires peuvent être créés par le code source de cette révision. De plus, le code source est toujours à jour, les builds peuvent ne pas être en commit.

J'enregistre certains fichiers binaires générés, comme les inter-interruptions .NET d'un autre projet. Donc, si j'ai un projet A qui crée un objet COM, puis que vous utilisez cet objet COM dans un projet B très vaguement lié qui l'utilise via .NET interop, je vérifie que l'interop généré à partir du projet A dans le projet B. Il est ce n'est pas une bonne idée, mais cela doit aller quelque part car AFAIK Visual Studio ne créera pas automatiquement l'interopérabilité pendant la construction.

À mon avis, ne pas stocker de fichiers binaires dans le contrôle de code source est l'une des erreurs les plus courantes. Ils doivent être stockés, versionnés, référencés / étiquetés avec les sources et également créer des outils. Associez-vous à la construction de logiciels non traçables ...