¿No debería tratar la carpeta bin como transitoria?

Question

Siempre me he enseñado a mí mismo y a otros a pensar en la carpeta bin como transitoria.

Debería poder eliminarlo y la próxima vez que lo reconstruya se volverá a crear y todas las referencias se copiarán en él sin ningún tipo de molestia Y no colocar todos los huevos en una sola cesta. O en este caso, no coloque todos los dlls necesarios directamente en la carpeta bin. Tenerlos en otro lugar y solo hacer referencia a ellos.

He visto gente caerse cuando ponen dlls directamente en la carpeta bin y hacer referencia a ellos allí. Así que trato de evitar esto y poner todas mis dlls requeridas en una carpeta llamada Refs y agregar referencias a los dlls allí. En tiempo de compilación, se copiarán en la carpeta bin de todos modos.

¿Estoy loco? ¿Esto es ser demasiado cuidadoso? ¿sentido común?

¿Cuál es la mejor práctica en este escenario?

Saludos,

- Lee

Actualización: Resulta que yo no estoy loco

Saludos muchachos que han recogido en algunos puntos me olvidó mencionar.

Principalmente:

• No verificar la carpeta bin en control de código fuente

Answer 1

Así es, no quiere poner dlls referenciadas en la carpeta bin.Si está utilizando el control de versiones, las carpetas bin y obj siempre deben estar completamente excluidas.

Todos los archivos DLL a los que se hace referencia se deben incluir bajo control de versiones, preferiblemente en un subdirectorio bajo el proyecto trunk, para que todos tengan todas las fuentes y referencias necesarias para cada reconstrucción limpia. La carpeta bin debe ser fácilmente recreada desde cero.

Eso es algo que creo que la mayoría de la gente va a esperar al verificar su fuente.

También incluyen un archivo _READ_ME.txt en la raíz del proyecto, indicando información adicional sobre las herramientas y otras cosas necesarias para lotes construir el proyecto (nant, perl, etc.), por lo que puede haber algunas diferencias específicas de vez en tiempo, pero nunca sorpresas de este tipo.

Answer 2

No, esto tiene mucho sentido y es una práctica yo mismo implemento en proyectos personales. Todo lo que se encuentre debajo de la carpeta bin se debe tratar como propiedad del entorno msbuild/Visual Studio.

Si bien ambos tienen mucho cuidado de solo eliminar las salidas que conocen, es posible que el usuario no entienda completamente cuál es la salida de compilación y copie una salida de construcción y en consecuencia la borre durante un estilo "Limpio" operación. También es posible que otras herramientas sean más agresivas aquí en la limpieza de DLL. Yo mismo tiendo a nukear el directorio bin de vez en cuando si creo que el proceso de compilación está buscando datos obsoletos.

Además, la ubicación de una referencia le brinda un lugar único para actualizar las referencias de una colección de proyectos dentro de una solución. Para mí es una construcción muy natural.

Answer 3

No tengo idea si estás loco, pero seguimos las mismas prácticas en el último lugar donde trabajé y las llevé a mi propio trabajo. Las carpetas/bin y/obj están fuera del control de la versión y son algo que nunca toco. Básicamente no existen por lo que a mí respecta durante el desarrollo. Todos los archivos DLL incluidos se sientan en otra carpeta y se hace referencia a ellos.

Answer 4

Creo que la carpeta bin es transitoria, es un lugar para la aplicación completa compilada para funcionar.

Colocamos cualquier ensamblaje externo en un directorio llamado Ensamblajes. Muchos otros usan un directorio llamado lib. Esto separa la idea de algo que se necesita para compilar la aplicación desde la propia aplicación compilada.