¿Se registra en las carpetas bin o depuración (y dlls) en su TFS?

Pregunta rápida sobre TFS: ¿ustedes registran carpetas bin / debug en TFS? (si es así, ¿por qué?) Dado que el contenido de esas carpetas se genera dinámicamente, ¿es mejor dejarlas fuera para que el programador no tenga problemas de solo lectura?

Como regla general, el control de fuente se usa mejor solo para la fuente, y los archivos generados no son fuente.

Hay excepciones. A veces (con Visual Studio) es posible que desee conservar el archivo .pdb para leer minivolcados. A veces no puede duplicar una cadena de herramientas, por lo que no necesariamente puede recrear los archivos generados con precisión. En estos casos, le interesa principalmente hacer esto para el software lanzado, no para cada cambio de VCS, y en cualquier caso, estos pueden residir fácilmente en carpetas versionadas. (Estos son típicamente archivos binarios, de todos modos, y no tienen cambios comprensibles de una versión a otra, y no se benefician mucho de estar en un VCS).

Respuesta simple? No. ¡No lo hagas! No puedo pensar en muchas razones para no hacerlo, pero no hay ninguna razón por la que quieras hacerlo.

La única vez que puedo pensar que revisarías un archivo DLL es si es de una biblioteca de terceros que no esperas que cada desarrollador haya instalado para compilar. Pero aún así, eso no se encuentra en la carpeta bin.

Dicho esto, trabajé en una compañía que requería que cada paquete de implementación se pusiera en control de origen, pero eso fue para que pudiéramos rastrear las diversas compilaciones que le dimos a nuestro cliente y podríamos retroceder fácilmente si fuera necesario.

No registramos la carpeta bin en TFS. Como probablemente haya notado, si lo hace, cada vez que un desarrollador construya la solución, verificará la carpeta bin. No está bien. Sin embargo, hay bibliotecas que el proyecto necesita para compilar y ejecutar, y nuestra regla es que cualquier proyecto debe poder abrirse desde el control de origen, y debe compilarse y ejecutarse. Entonces, lo que hacemos es crear una carpeta "BinRef" para cualquier archivo DLL al que el proyecto debe tener referencia, y crear las referencias del proyecto a la copia en la carpeta BinRef. La carpeta BinRef está registrada en TFS.

La otra ventaja de este enfoque es que BinRef siempre está en el nivel raíz del proyecto web. Si mi proyecto vive C:\Projects\Marcie\SomeProjectCategory\ProjectAy creo una referencia a un archivo DLL que se encuentra C:\DLLsThatILike, la referencia terminará pareciéndose a

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

. Puede conservar sus archivos de proyecto, lo C:\ProjectAque significa que la referencia del proyecto a NiceThing explotará en su máquina. Espero que la gente no haga referencias de esta manera, pero lo he visto suceder.

Registramos el contenido de los directorios bin como parte de nuestro proceso de Solicitud de cambio. Para evitar los problemas de solo lectura, copiamos el contenido a una carpeta separada y los registramos desde allí. Nuestra política corporativa requiere que todos los archivos binarios que van a producción se registren por separado de la fuente. No es la mejor solución, pero funciona y nos da los archivos exactos que están en producción.

Dudo en verificar cualquier archivo que no sea de texto en el control de origen. Especialmente los que deberían ser generados por el desarrollador. También me gusta mantener otros archivos binarios, como imágenes y PDF, comprimidos y almacenados en otro lugar para cada etiqueta / lanzamiento.

No, pero nuestra herramienta de control de proyectos interna lo hace automáticamente, lo que me molesta muchísimo.

Mi solución es marcar todos los archivos en versión y depuración como editables y cuando TFS se queja, le digo que ignore los archivos, por lo que nunca tengo un problema con una falla de compilación.

Evito ingresarlos en el control de la fuente. Son información redundante, los binarios pueden ser construidos por el código fuente en esa revisión. Además, el código fuente siempre está actualizado, las compilaciones pueden no estar en commit.

Guardo algunos archivos binarios generados, como interops .NET de otro proyecto. Entonces, si tengo un proyecto A que crea un objeto COM, y luego usa ese objeto COM en un proyecto B muy poco relacionado que lo usa a través de interoperabilidad .NET, verifico esa interoperabilidad generada desde el proyecto A en el proyecto B. Es no es una buena idea, pero tiene que ir a algún lado porque AFAIK Visual Studio no creará la interoperabilidad automáticamente durante la compilación.

En mi opinión, no almacenar binarios en el control de código fuente es uno de los errores más comunes. Deben almacenarse, versionarse, basarse / etiquetarse junto con las fuentes y también construir herramientas. Suite con software de construcción no rastreable ...