Estoy de acuerdo con el análisis de Aequitarum. Solo un par de puntos adicionales:
El motor es código compartido para todos los procesos, entonces supongo que puede ser un ensamblado compartido.
Eso parece razonable.
Si un conjunto compartido está en la misma solución que un proyecto que lo consume, ¿cómo se consume si se supone que está en el GAC?
Magic.
OK, no es mágico. Supongamos que en su solución su proceso proyecto tiene una referencia al motor proyecto. Cuando construya la solución, producirá un proyecto ensamblado que tiene una referencia al ensamblaje del motor . Visual Studio luego copia los diversos archivos en los directorios correctos. Cuando ejecuta el ensamblado de proceso, el cargador de tiempo de ejecución sabe buscar en el directorio actual para el ensamblaje del motor. Si no puede encontrarlo allí, se ve en el caché de ensamblaje global. (Esta es una vista muy simplificada de la política de carga, la política real es considerablemente más compleja que eso.)
Las cosas en el GAC deben ser verdaderamente global código; código que razonablemente espera que use un gran número de proyectos dispares.
¿Eso significa que engine.dll tiene que ser reployed en cada compilación?
No estoy seguro de lo que quiere decir con "redeployed". Como dije, si tiene una referencia de proyecto a proyecto, el sistema de compilación copiará automáticamente los archivos en los lugares correctos.
la razón principal que nos separamos el filtro del proceso (sólo un proceso que utiliza) es por lo que podemos desplegar el filtro independientemente del proceso para que el proceso ejecutable no necesita ser actualizado
Me pregunto si eso es realmente valioso. Escenario uno: sin ensamblaje de filtro, todo el código de filtro está en project.exe. Desea actualizar el código de filtro; usted actualiza project.exe. Escenario dos: filter.dll, project.exe. Desea actualizar el código de filtro; usted actualiza filter.dll. ¿Cómo es el escenario dos más barato o más fácil que el escenario uno? En ambos casos, está actualizando un archivo; ¿Por qué importa cuál es el nombre del archivo?
Sin embargo, quizás sea realmente más barato y más fácil para su situación particular. La clave para entender sobre los ensambles es que los ensambles son la unidad más pequeña de , independientemente del código configurable y redistribuible. Si tiene dos cosas y tiene sentido para la versión y enviarlas independientemente una de la otra, entonces deberían estar en ensamblajes diferentes; si no tiene sentido hacer eso, entonces deberían estar en el mismo conjunto.
He leído que las asambleas enlazan a versiones específicas de otros conjuntos, por lo que si puedo actualizar el archivo DLL única, en realidad es considerada la manipulación. ¿Cómo puedo actualizar la DLL sin cambiar el EXE? ¿Para eso sirve una política de editor?
Un conjunto puede recibir un "nombre seguro". Cuando nombra a su conjunto Foo.DLL, y escribe Bar.EXE para decir "Bar.EXE depende de Foo.DLL", entonces el tiempo de ejecución cargará todo lo que pasa por llamarse Foo.DLL; los nombres de los archivos no son fuertes Si un hacker malvado obtiene su propia versión de Foo.DLL en la máquina cliente, el cargador la cargará. Un nombre seguro le permite a Bar.EXE decir "Bar.exe versión 1.2 escrita por Bar Corporation depende de Foo.DLL versión 1.4 escrita por Foo Corporation", y todas las verificaciones se realizan contra las claves criptográficas fuertes asociadas con Foo Corp y Bar Corp.
Así que sí, un ensamblaje puede configurarse para vincularse únicamente con una versión específica de una empresa específica, para evitar manipulaciones. Lo que puede hacer para actualizar un ensamblaje para usar una versión más nueva es crear un pequeño archivo XML que le diga al cargador "¿sabe cómo dije que quería Foo.DLL v1.4? Bueno, en realidad si 1.5 está disponible, está bien usarlo eso también."
¿Qué debo buscar? Veo muchos libros sobre C# y .NET, pero ninguno sobre implementación, construcción o pruebas o cosas que no están relacionadas con el lenguaje en sí.
El despliegue se omite con frecuencia en los libros, estoy de acuerdo.
Comenzaré buscando "ClickOnce" si está interesado en la implementación de aplicaciones administradas de Windows.
un buen libro que describe exactamente qué archivos, ensamblajes y módulos son es CLR a través de C# por Jeffrey Richter. En mi humilde opinión, este libro es irremplazable como fuente para aprender los fundamentos de .NET –