¿Cuándo se debe usar una referencia de proyecto opuesta a una referencia binaria?

Question

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

Algunos argumentos a favor de las referencias del proyecto:

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

Algunos argumentos a favor de las referencias binarias:

• referencias binarios podrían simplificar las soluciones y hacer que para los tiempos de carga más rápidos solución.
• Las referencias binarias permitirían a los desarrolladores centrarse en el nuevo código en lugar de distraerse potencialmente por un código que ya está horneado y probado como estable.
• Las referencias binarias nos obligarían a alimentar apropiadamente nuestras cosas, ya que estaríamos usando la biblioteca común tal como se requeriría que hicieran los que están fuera de nuestra organización.
• Dado que una referencia binaria no se puede depurar (intercalar), uno se vería obligado a replicar y solucionar problemas extendiendo los proyectos de prueba existentes en lugar de probar y solucionar en el contexto de la aplicación consumidora sola.
• Las referencias binarias asegurarán que el desarrollo concurrente en el proyecto de biblioteca de clases no tendrá 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 influx. Sería la decisión del líder del proyecto si incorporar o no una versión más nueva del componente si es necesario.

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

Answer 1

Me parece que ha cubierto todos los puntos principales. Hemos tenido una discusión similar en el trabajo recientemente y todavía no estamos del todo decididos.

Sin embargo, una cosa que hemos investigado es hacer referencia a los archivos binarios para obtener todas las ventajas que nota, pero tener los binarios construidos por 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 sentadas en la red en el trabajo), de modo que cualquier depuración puede 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 hacer que el depurador las salte por completo, porque cualquier depuración se hace en sus propias clases (en el nivel que ' re developing) solo sería enormemente desproporcionado por el código de las bibliotecas base. De esta forma, cuando acierte al Ingrese a tecla de acceso directo a la depuración en una clase de biblioteca, resurja en el siguiente fragmento de código en su nivel actual, en lugar de tener que recorrer toneladas de código de biblioteca.

Básicamente, definitivamente voto en voz alta (en términos de SO) tus comentarios sobre mantener el código de la biblioteca comprobada fuera del alcance 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 de referencia común para su desarrollo. Asumo que las bibliotecas están cambiando. Si ese es el caso, compilarlos y asegurarse de que estén versionados le proporcionará 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 solo en algunas máquinas.

Answer 3

Creo que si el proyecto no es parte de la solución, no debe incluir allí ... pero eso es sólo mi opinión

separo por concepto de corto

Answer 4

cuando Don No lo quiere en su solución, ni tiene el potencial de dividir su solución, envíe toda la salida 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 para ganar, y cosas de Silverlight, y las bibliotecas de control web están en soluciones separadas que incluyen los proyectos que necesita al analizarlos, pero nant puede construirlo todo.

Answer 5

Creo que su pregunta es realmente acerca de cuándo los proyectos van de la mano 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 deben contener proyectos que se desarrollan estrechamente juntos. Como sus ensamblajes API y sus implementaciones de esas API.

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

Answer 6

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" un lanzamiento de la biblioteca, se copia a una ubicación central disponible para todos los desarrolladores. Depende de cada proyecto decidir qué versión de la biblioteca consumir copiando los binarios en una carpeta de proyecto y utilizando 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 VS. Esto le permitiría depurar a través del código y aún así tener los beneficios de utilizar referencias binarias.

En cuanto a los beneficios que menciona para referencias de proyectos, no estoy de acuerdo con su segundo punto. Para mí, es importante que los proyectos consumidores explícitamente conozcan 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 recoja accidentalmente cambios en la biblioteca que no se hayan completado o probado.