VS.NET: Ref. De proyecto vs. Ref. De ensamblaje

Question

Existe un debate aquí sobre cuál es mejor para hacer referencia a nuestra base de código común de otros proyectos: por proyecto o por ensamblado. Estoy a favor de hacer referencia al proyecto, especialmente porque tenemos pruebas unitarias automatizadas que prueban que el código común hace lo que necesita.

La idea del otro campamento es bloquear esos proyectos y solo lanzar montajes una vez al mes o algo así. Luego obligue a todos los proyectos a hacer referencia a las asambleas. Creen que esto los protegerá de implementar código no probado. Están "demasiado ocupados" para escribir pruebas unitarias automatizadas y configurar sus proyectos para una integración continua y no tengo influencia sobre eso, así que no se concentren en este aspecto.

Aquí están las razones por las que puedo pensar por qué las referencias de proyectos son la mejor solución. Estoy buscando otras opiniones también.

PROS:

• proyectos Hacer referencia asegura que está trabajando con el código más reciente. No tienes que esperar nada.
• Reducción de la duplicación. Sin tener el último código, hay una mayor posibilidad de reinventar la rueda.
• Si un desarrollador necesita algo y no puede agregarlo al ensamblaje al que pertenece, se creará en cualquier ubicación que funcione, creando muchas inconsistencias y duplicación de código.
• El desarrollo es más fácil porque puede ver/depurar fácilmente lo que está sucediendo en el código al que se hace referencia.
• Nuestras cosas en común no cambian con tanta frecuencia, pero cuando lo hace, suele ser algo útil. ¿Por qué agregar la carga adicional de mantenimiento y gestión de liberación de ensamblaje?

CONTRA:

• podría tomar más tiempo para cargar.
• Puede tomar un poco más de tiempo para agregar proyectos a una nueva solución y luego agregar referencias de ensamblaje.

Answer 1

Aquí hay un par de ventajas que se perdió

• Actualización en tiempo real: Características como IntelliSense se actualizarán automáticamente entre el proyecto a las referencias del proyecto como está cambiando las API
• Ir Definición: Si usted tiene una referencia de ensamblaje, la definición de GoTo lo llevará a la definición del código real. Con una referencia de ensamblado, lo llevará a la firma de metadatos generados.
• Buscar todas las referencias: Se procesará todo el código en las referencias del proyecto para el uso de una referencia. Para una referencia de ensamblado sólo verá usos dentro de los metadatos
• Búsqueda Rápida (2010 solamente): Similar a encontrar todas las referencias, simplemente funciona mejor en una referencia P2P

En respuesta a sus contras

• Sí: cargar un proyecto suele ser más lento que cargar una referencia.Con una cantidad razonable de proyectos, aunque esta diferencia de tiempo no es significativa y no debería afectar su rutina de desarrollo diario
• Sí: agregar agregar un proyecto a la solución es generalmente más lento que agregar una referencia. La diferencia, sin embargo, está en segundos y es un costo de una vez. Creo que es un error considerar esto como parte de los criterios.

Answer 2

Bueno, si está utilizando cualquier tipo de control de fuente puede satisfacer ambos campos. Usando Branching o Labeling (dependiendo de su control de fuente).

Básicamente si tiene un equipo que tiene el control de su código común, puede bifurcar/etiquetar una versión estable. Entonces sus proyectos usarían la versión estable. Esto lo protege de la implementación de código inestable para sus otros proyectos al tiempo que le brinda la capacidad de probar, depurar y ver todo el origen.

Siempre que su equipo de controles comunes cree una nueva versión estable, puede actualizar sus referencias de origen para extraer de la nueva rama.

La otra ventaja de este escenario es que podría tener un parche en el código común para no interferir con los esfuerzos actuales de desarrollo en curso. Por supuesto, esto agrega una carga adicional de administración para actualizar el código común en más de un lugar donde sea necesario.

Answer 3

REFERENCIAS ESTRATEGIA siempre será un problema común

Sé que esto es una pregunta muy antigua pero siempre será una cuestión relevante con respuestas relativas y recuerdo tener esta misma pregunta hace unos años y la impacto de las dos opciones (proyecto versus ensamblaje referencias) solo se hizo evidente para mí durante los últimos dos años mientras trabajaba a tiempo completo en un generador para un sistema con más de 800 proyectos en más de 300 soluciones para una sola aplicación WPF.

referencias del proyecto son ideales para VISUAL STUDIO

Proyectos de referencia son ideales porque le das el IDE más información sobre los detalles de su código, porque le está diciendo explícitamente Visual Studio donde el proyecto de referencia y la totalidad de su el código es Si está trabajando en un sistema con menos de 200 módulos de proyectos y puede permitirse tener solo algunas soluciones (agrupaciones de proyectos), busque referencias de proyectos porque Visual Studio puede hacer más por usted con esa información adicional durante el tiempo de diseño, como mostrarle el código en lugar de reflejar conjuntos referenciados.

Referencias montaje se escalan mejor

Si el sistema es mucho más grande que 200 proyectos, tus construcciones, pueden ser muy lento. He visto 20 minutos por construcción y eso realmente apesta. Entonces, si puede hacer referencia a una DLL que no cambia, le está diciendo a "NO" a Visual Studio que la cree, y eso obviamente tiene algún impacto en el tiempo de compilación.

referencias de ensamblado crear una ilusión de A desacoplado SISTEMA

Proyectos de referencia ofrecerle una IDE inteligente que siempre sabe dónde y en cuántos lugares se utiliza un tipo, donde el código se puede encontrar, y alguna otra estadísticas útiles porque todos los proyectos están referenciados directamente. También puede advertirle cuando, inadvertidamente, intentó crear una referencia circular.

PROS de referencias de ensamblado:

1. Mediante el tratamiento de algunos proyectos como dependencias externas, se pueden crear soluciones más pequeñas y las agrupaciones más pequeñas de proyectos relacionados, ya que los proyectos no relacionados son tratados como conjuntos externos
2. permite a Visual Estudio para manejar sistemas modulares muy grandes bastante bien.
3. Te obliga a elaborar una estrategia de almacenamiento en dll/ensamblaje durante el proceso de compilación.

desventajas de referencias de ensamblado:

• referencias circulares se hacen posibles, y sus desarrolladores con menos experiencia no notarán esas referencias inicialmente.

  Puede evitar este desafío de referencias circulares tratando uno de sus ensamblajes como un ensamblado de terceros que está registrado, transfiriéndolo a la próxima versión y compilándolo al final. Cuando una compilación falla en un proyecto que usa este ensamblado excluido, puede decidir reconstruir ese proyecto nominado y muchas veces administrar la dependencia circular. (NO SE RECOMIENDA, pero es posible)

• Las referencias de marcos ascendentes también se hacen posibles porque agrega referencias a dlls que se compilan contra un .NET Framework superior, y Visual Studio no le da mensajes claros de causa raíz cuando esto sucede, intentarás solucionar el problema y fallarás muchas veces antes de resolver las versiones del framework.

  Nuevos proyectos predeterminados a la última versión del .NET Framework sin considerar el hecho de que todos los proyectos en la solución actual todavía están en una versión anterior de .net, por lo que cuando agrega una referencia a ese proyecto usando un ensamblado de referencia, a menudo obtendrá un error extraño que no es tan fácil de entender.

• Las referencias entre ramas también son posibles porque probablemente trabaje en más de una rama al mismo tiempo y, a veces, se confunda al agregar una referencia.

  Haz clic en "agregar referencia", sube algunos directorios, baja algunos directorios, selecciona el dll y haz clic en agregar sin darte cuenta de que el dll está demasiado arriba y abajo en otra rama en la que también trabajas en. Este problema solo se pondrá de manifiesto mucho más tarde cuando el servidor de compilación intente resolver ese ensamblaje y falle. Y el error "espacio de nombres desconocido, ¿te falta una referencia de ensamblado?" no te ayudará en absoluto a perder el tiempo de todo tu equipo.