de haber tocado en un muy gran tema, que realmente puede conseguir tan complicado como lo permitirá.
En última instancia, el enfoque de control de versiones que elija dependerá de lo que necesite lograr y de cuánto tiempo tenga que dedicar a su mantenimiento. Los dos están directamente relacionados.
Los dos objetivos principales del control de versiones, es la ejecución lado a lado y el seguimiento. Side-by-side (SxS) está permitiendo que se ejecuten varias versiones de la misma DLL dentro de la misma aplicación. Sin el cambio de un número de versión de ensamblaje, esto no es posible. El seguimiento es simplemente poder determinar la instantánea de código exacta que se ejecuta en una máquina de clientes. Ambos se pueden lograr cambiando la versión de ensamblaje, pero la primera se puede lograr solo cambiando la versión de ensamblaje.
Muchos le recomendarán que comparta los números de versión en todas las DLL/EXEs: esta es una buena manera de hacerlo, ya que es el enfoque más simple, también logra la menor flexibilidad de implementación.
Por ejemplo, si está utilizando cualquier forma de abstracción de contrato (definiendo dependencias entre DLL a través de interfaces en lugar de tipos concretos), puede dividir su aplicación en múltiples 'silos de control de versiones'. Un ejemplo de esto sería el cliente y el servidor, donde la interdependencia, si se define en un tercer conjunto, sus contratos de WCF. Si todas las versiones están por separado, puede lanzar una nueva versión del servidor (siempre que cumpla con el mismo contrato), sin afectar al cliente. Y viceversa.
Como puede ver, aumentará la granularidad de su versión a medida que crezca su demanda, pero se escuchará por casualidad.
Lo mejor que puede hacer es exactamente lo que está haciendo, siéntese y planifique sus necesidades, luego planifique sus límites de control de versiones (qué componentes pueden separarse mediante contratos).
Lo siguiente depende del tamaño de su departamento de pruebas, pero también le recomiendo que considere que la versión del archivo refleje (al menos en parte) el número de compilación/fecha. Solo aumentará la versión de ensamblaje una vez por versión de cliente, pero debe tener una versión de archivo diferente para cada colección de DLL que surja de la compilación. Esto se debe a que cuando realiza una prueba y detecta un problema, al tener estas DLL identificables de forma única, se eliminará cualquier duda sobre la creación exacta de la DLL.
Depende de si las DLL son una parte integral de la aplicación, o un proyecto en sí mismo. Actualmente estoy trabajando en una aplicación que tiene una DLL de biblioteca que se puede usar en otros proyectos. La biblioteca DLL tiene su propia información de ensamblaje y no garantizamos que su número de versión coincida con el número de versión de cada otro proyecto en el que se usa. –
@Robert Harvey, sí, por supuesto. Si el dll no es una parte integral de la aplicación, entonces no puede hacer que use el conjunto de información compartido. Pero en esta pregunta en particular parece que el dll es una parte de la aplicación. – Illuminati