¿Cuándo se debe utilizar una referencia de proyecto en lugar de una referencia binaria?

Question

Mi empresa tiene una biblioteca de códigos común que consta de muchos proyectos de biblioteca de clases junto con proyectos de prueba de soporte.Cada proyecto de biblioteca de clases genera un único binario, p.Company.Common.Serialization.dll.Dado que somos propietarios de los binarios compilados y probados, así como del código fuente, existe un debate sobre si nuestras aplicaciones consumidoras deben usar referencias binarias o de proyecto.

Algunos argumentos a favor de las referencias del proyecto:

• Las referencias de proyectos permitirían a los usuarios depurar y ver todo el código de la solución sin la sobrecarga de cargar proyectos/soluciones adicionales.
• Las referencias del proyecto ayudarían a mantenerse al día con los cambios de componentes comunes comprometidos con el sistema de control de fuente, ya que los cambios serían fácilmente identificables sin la solución activa.

Algunos argumentos a favor de las referencias binarias:

• Las referencias binarias simplificarían las soluciones y acelerarían los tiempos de carga de las soluciones.
• Las referencias binarias permitirían a los desarrolladores centrarse en el código nuevo en lugar de distraerse potencialmente con el código que ya está preparado y ha demostrado ser estable.
• Las referencias binarias nos obligarían a analizar adecuadamente nuestras cosas, ya que estaríamos usando la biblioteca común tal como se les exigiría a aquellos fuera de nuestra organización.
• Dado que una referencia binaria no se puede depurar (intervenir), uno se vería obligado a replicar y solucionar problemas ampliando los proyectos de prueba existentes en lugar de probarlos y solucionarlos únicamente dentro del contexto de la aplicación consumidora.
• Las referencias binarias garantizarán que el desarrollo simultáneo en el proyecto de biblioteca de clases no tenga ningún impacto en la aplicación consumidora, ya que se hará referencia a una versión estable del binario en lugar de a una versión influyente.Sería decisión del líder del proyecto incorporar o no una versión más reciente del componente si fuera necesario.

¿Cuál es su política/preferencia cuando se trata de utilizar referencias binarias o de proyectos?

Answer 1

Me parece que has cubierto todos los puntos principales.Tuvimos una discusión similar en el trabajo recientemente y aún no estamos del todo decididos.

Sin embargo, una cosa que hemos analizado es hacer referencia a los archivos binarios, para obtener todas las ventajas que observa, pero tener los binarios compilados mediante un sistema de compilación común donde el código fuente está en una ubicación común, accesible desde todas las máquinas de desarrollo ( al menos si están conectados a la red en el trabajo), de modo que cualquier depuración pueda de hecho sumergirse en el código de la biblioteca, si es necesario.

Sin embargo, en la misma nota, también hemos etiquetado muchas de las clases base con atributos apropiados para que el depurador las omita por completo, porque cualquier depuración que realice en sus propias clases (en el nivel que está desarrollando) sólo será enormemente sobredimensionado por el código de las bibliotecas base.De esta manera cuando golpeas el Entrar en Al depurar una tecla de acceso directo en una clase de biblioteca, reaparece en el siguiente fragmento de código en su nivel actual, en lugar de tener que leer toneladas de código de biblioteca.

Básicamente, definitivamente voto a favor (en términos SO) sus comentarios sobre mantener el código de biblioteca probado fuera de la vista del desarrollador normal.

Además, si cargo el archivo de solución global, que contiene todos los proyectos y básicamente todo, ReSharper 4 parece tener algún tipo de problema coronario, ya que Visual Studio prácticamente se paraliza.

Answer 2

En mi opinión, el mayor problema con el uso de referencias de proyectos es que no proporciona a los consumidores una base común para su desarrollo.Supongo que las bibliotecas están cambiando.Si ese es el caso, compilarlos y asegurarse de que tengan versiones le brindará un entorno fácilmente reproducible.

No hacer esto significará que su código se romperá misteriosamente cuando cambie el proyecto al que se hace referencia.Pero sólo en algunas máquinas.

Answer 3

Tiendo a tratar bibliotecas comunes como esta como recursos de terceros.Esto permite que la biblioteca tenga sus propios procesos de compilación, pruebas de control de calidad, etc.Cuando QA (o quien sea) "bendice" una versión de la biblioteca, se copia en una ubicación central disponible para todos los desarrolladores.Luego, depende de cada proyecto decidir qué versión de la biblioteca consumir copiando los archivos binarios a una carpeta de proyecto y usando referencias binarias en los proyectos.

Una cosa que es importante es crear archivos de símbolos de depuración (pdb) con cada compilación de la biblioteca y ponerlos a disposición también.La otra opción es crear un almacén de símbolos local en su red y hacer que cada desarrollador agregue ese almacén de símbolos a su configuración de VS.Esto le permitiría depurar el código y seguir teniendo los beneficios de utilizar referencias binarias.

En cuanto a los beneficios que mencionas para las referencias de proyectos, no estoy de acuerdo con tu segundo punto.Para mí, es importante que los proyectos consumidores sepan explícitamente qué versión de la biblioteca común están consumiendo y que den un paso deliberado para actualizar esa versión.Esta es la mejor manera de garantizar que no seleccione accidentalmente cambios en la biblioteca que no se hayan completado o probado.

Answer 4

cuando no lo quiera en su solución, o tenga potencial para dividir su solución, envíe todos los resultados de la biblioteca a un directorio bin común y haga referencia allí.

He hecho esto para permitir a los desarrolladores abrir una solución ajustada que solo tenga el dominio, las pruebas y los proyectos web.Nuestros servicios Win, material Silverlight y bibliotecas de control web se encuentran en soluciones separadas que incluyen los proyectos que necesita al analizarlos, pero Nant puede crearlos todos.

Answer 5

Creo que su pregunta es en realidad sobre cuándo los proyectos van juntos en la misma solución;La razón es que los proyectos en la misma solución deben tener referencias de proyecto entre sí, y los proyectos en diferentes soluciones deben tener referencias binarias entre sí.

Tiendo a pensar que las soluciones deberían contener proyectos que se desarrollen en estrecha colaboración.Como sus ensamblajes de API y sus implementaciones de esas API.

Sin embargo, la cercanía es relativa.Un diseñador para una aplicación, por definición, está estrechamente relacionado con la aplicación; sin embargo, no querrás tener el diseñador y la aplicación dentro de la misma solución (si son complejos, claro está).Probablemente desee desarrollar el diseñador en una rama del programa que se fusiona en intervalos más espaciados que la integración diaria normal.

Answer 6

Creo que si el proyecto no es parte de la solución, no deberías incluirlo allí...Pero esa es solo mi opinión

Lo separo por concepto en resumen