Definiciones de tipo .NET en conjuntos fusionados (ILMerge)

Question

Estoy fusionando varios ensamblados .NET utilizando ILMerge, incluidos algunos ensamblados de terceros. Desde entonces, he experimentado varios errores que se reducen al hecho de que las definiciones de tipos están vinculadas al ensamblado en el que están definidas.

Un ejemplo simple es la definición de sección de configuración de log4net en mi App.config. Utiliza type = "log4net.Config.Log4NetConfigurationSectionHandler, log4net", que no funcionará dado que el ensamblado log4net no existe una vez que se ha fusionado en mi ensamblado fusionado. Aunque no es un gran problema, cambio el nombre del ensamblaje a mi ensamblado combinado y funciona bien.

Un ejemplo un poco más complicado es el de los tipos serializados binarios. Mi sistema usa serialización binaria para enviar ciertos objetos entre procesos. Todos los objetos serializables se definen en un conjunto común al que hacen referencia todos los demás proyectos. Estaba usando la serialización binaria predeterminada, pero comenzó a fallar al deserializar los objetos con el error que indicaba que no podía encontrar el ensamblado fusionado que serializaba el objeto. Nuevamente, no es gran cosa, implementé una SerializationBinder personalizada que busca el tipo en cualquier ensamblaje cargado, no solo el que se proporciona.

El ejemplo anterior se volvió más complicado cuando el tipo serializado hace referencia a otros tipos serializables. Continué encontrándome con más y más problemas que son cada vez más difíciles de manejar.

El punto que trato de entender aquí es que el sistema de tipo .NET e ILMerge no parecen funcionar bien juntos. ¿Alguien tiene alguna experiencia con la forma en que han resuelto este problema? ¿Es posible decirle al tiempo de ejecución de .NET que no me importa en qué ensamblaje el tipo dice que debería estar, simplemente búscalo en cualquier lugar?

NOTA: Por favor, no responda preguntándome por qué estoy fusionando ensamblajes, ese no es el punto de esta pregunta.

Answer 1

Bienvenido a peligros de cuerdas y cuerdas (física) en la localización de código ..

Todas las herramientas de este tipo tienen problemas similares y que mejor que sea inteligente, ya que muchos desarrolladores y diseñadores de características de tiempo de ejecución tales como la unión y la serialización realmente no lo preveía, pero seguro que empujaron a ILMerge como una herramienta "inteligente". Es tan inteligente que ni siquiera puede podar tipos.

Tenga en cuenta que el control de versiones también entra en juego aquí, y la configuración,. * Y las estrellas en sus ojos, y la independencia de la versión de Redmond tampoco ayuda.

Seguramente seguirá teniendo problemas con terceros. Y créeme, sé que necesitas la fusión, ya que algunos patéticos y pequeños tipos pueden tomar años para que MS JIT actúe para aplicaciones grandes (y no, no quiero cargar NGEN o 3.5SP1 optimizado que sea aún más lento que antes debido a System.Core o el cielo, prohíbe la hinchazón de WPF).

La mejor opción, en mi humilde opinión, al menos a gran escala, es obtener una herramienta comercial decente que escanee y maneje esto (es decir, de la experiencia existente de dolor y ofuscación). A la larga, podrías terminar instrumentando el código IL existente si no tienes las fuentes.

[Luego hubo una cadena de INotifyPropertyChanged invención de modo que resolvió el problema del calentamiento global - Diseñado por Casio-Calc inventores]

Answer 2

Sí, hay una solución a este problema: construir módulos en lugar de asambleas!

Los compiladores para .net tienen una opción (/ destino: módulo para C# y VB) que crea un módulo en lugar de un ensamblaje.Múltiples módulos pueden pasar al compilador y usarse para construir el ensamblaje final.

Por supuesto, todo esto supone que tiene la fuente para esos conjuntos de terceros. Si no puede obtener eso, ¿tal vez una versión de .netmodule del ensamble de terceros puede ser adquirida por un tercero?

Si eso no funciona, aún tiene una última opción. Obviamente, ya estás desmontando una asamblea de terceros en IL. Elimine la información del ensamblado de ese archivo IL y use "ilasm/dll" para compilar un .netmodule que ahora debería poder usar como cualquier otro .netmodule.

Al usar módulos en lugar de ensamblajes, no debería tener más problemas basados ​​en el ensamblaje.

Es cierto que ya hemos resuelto su problema con ILMerge al no usar ILMerge, pero ¿no es realmente esa la mejor solución?

espero que funcione para usted, aquí hay algún vínculo práctico:
.netmodule instead of assembly
ILASM with .netmodules

(Y yo que pensaba que mi experiencia con .netmodules nunca sería útil para cualquier persona!)

Answer 3

Varios años después de la pregunta, me encontré con el mismo problema y encontré una solución. Puede agregar [assembly: log4net.Config.XmlConfigurator(ConfigFile = "logging.config", Watch = true)] en el archivo AssemblyInfo.cs y esto funcionará al fusionar el ensamblado log4net.