Pregunta

¿Utilizas ILMerge?¿Utiliza ILMerge para fusionar múltiples ensamblajes para facilitar la implementación de dll?¿Ha encontrado problemas con la implementación/control de versiones en producción después de IL fusionar ensamblajes?

Estoy buscando algunos consejos sobre el uso de ILMerge para reducir la fricción en la implementación, si es que eso es posible.

¿Fue útil?

Solución

Utilizo ILMerge para casi todas mis diferentes aplicaciones.Lo tengo integrado directamente en el proceso de compilación de la versión, por lo que termino con un archivo ejecutable por aplicación sin archivos DLL adicionales.

No puede ILMerge ningún ensamblado de C++ que tenga código nativo.Tampoco puede ILMerge ningún ensamblado que contenga XAML para WPF (al menos no he tenido éxito con eso).Se queja en tiempo de ejecución de que no se pueden localizar los recursos.

Escribí un ejecutable contenedor para ILMerge donde paso el nombre del archivo ejecutable de inicio para el proyecto que quiero fusionar y un nombre del archivo ejecutable de salida, y luego refleja los ensamblados dependientes y llama a ILMerge con los parámetros de línea de comando apropiados.Es mucho más fácil ahora, cuando agrego nuevos ensamblados al proyecto, no tengo que acordarme de actualizar el script de compilación.

Otros consejos

Introducción

Esta publicación muestra cómo reemplazar todos .exe + .dll files con un solo combined .exe.También mantiene la depuración. .pdb archivo intacto.

Para aplicaciones de consola

Aquí está lo básico. Post Build String para Visual Studio 2010 SP1, usando .NET 4.0.Estoy creando una consola .exe con todos los archivos sub-.dll incluidos.

"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards

Consejos básicos

  • La salida es un archivo "AssemblyName.all.exe"que combina todos los subdlls en un solo .exe.
  • Observe la ILMerge\ directorio.Debe copiar la utilidad ILMerge en el directorio de su solución (para poder distribuir el código fuente sin tener que preocuparse por documentar la instalación de ILMerge) o cambiar esta ruta para que apunte a donde reside ILMerge.exe.

Consejos avanzados

Si tienes problemas con que no funcione, enciende Output, y seleccione Show output from: Build.Verifique el comando exacto que realmente generó Visual Studio y verifique si hay errores.

Script de compilación de muestra

Este script reemplaza todos .exe + .dll files con un solo combined .exe.También mantiene intacto el archivo .pdb de depuración.

Para usarlo, pega esto en tu Post Build paso, debajo del Build Events pestaña en un proyecto de C# y asegúrese de ajustar la ruta en la primera línea para que apunte a ILMerge.exe:

rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0

Usamos ILMerge en los bloques de aplicaciones de Microsoft; en lugar de 12 archivos DLL separados, tenemos un solo archivo que podemos cargar en nuestras áreas de clientes, además la estructura del sistema de archivos es mucho más ordenada.

Después de fusionar los archivos, tuve que editar la lista de proyectos de Visual Studio, eliminar los 12 ensamblajes separados y agregar el archivo único como referencia; de lo contrario, se quejaría de que no podía encontrar el ensamblaje específico.Sin embargo, no estoy muy seguro de cómo funcionaría esto después de la implementación; podría valer la pena intentarlo.

Sé que esta es una vieja pregunta, pero no solo usamos ILMerge para reducir la cantidad de dependencias sino también para internalizar las dependencias "internas" (por ejemplo, automapper, restsharp, etc.) que utiliza la utilidad.Esto significa que están completamente abstraídos y el proyecto que utiliza la utilidad fusionada no necesita conocerlos.Esto nuevamente reduce las referencias requeridas en el proyecto y le permite usar/actualizar su propia versión de la misma biblioteca externa si es necesario.

Usamos ILMerge en bastantes proyectos.El Fábrica de software de servicios web, por ejemplo, produce algo así como 8 ensamblajes como salida.Fusionamos todas esas DLL en una sola DLL para que el host del servicio solo tenga que hacer referencia a una DLL.

Hace la vida algo más fácil, pero tampoco es gran cosa.

Tuvimos el mismo problema al combinar dependencias de WPF...ILMerge no parece ocuparse de estos.Sin embargo, Costura.Fody funcionó perfectamente para nosotros y tardó unos 5 minutos en ponerse en marcha...una muy buena experiencia.

Simplemente instálelo con Nuget (seleccionando el proyecto predeterminado correcto en la Consola del Administrador de paquetes).Se introduce en el proyecto de destino y la configuración predeterminada funcionó de inmediato para nosotros.

Combina todas las DLL marcadas como "Copiar local" = verdadero y produce un .EXE combinado (junto con la salida estándar), cuyo tamaño está muy comprimido (mucho menos que el tamaño total de salida).

La licencia es MIT, por lo que puede modificarla/distribuirla según sea necesario.

https://github.com/Fody/Costura/

Tenga en cuenta que para los programas GUI de Windows (por ejemplo, WinForms) querrá utilizar /target:winexe cambiar.
El objetivo:exe El interruptor crea un fusionado. consola solicitud.

Tuvimos problemas al fusionar archivos DLL que tienen recursos en el mismo espacio de nombres.En el proceso de fusión se cambió el nombre de uno de los espacios de nombres de recursos y, por lo tanto, no se pudieron ubicar los recursos.Tal vez simplemente estemos haciendo algo mal y todavía estamos investigando el problema.

Acabamos de empezar a utilizar ILMerge en nuestras soluciones que se redistribuyen y utilizan en nuestros otros proyectos y hasta ahora todo bien.Todo parece funcionar bien.Incluso ofuscamos directamente el ensamblaje empaquetado.

Estamos considerando hacer lo mismo con los ensamblajes de MS Enterprise Library.

El único problema real que veo es el control de versiones de ensamblajes individuales del paquete.

Recientemente tuve un problema en el que había fusionado el ensamblaje en el ensamblaje. Tenía algunas clases que se llamaban mediante reflexión en el CMS de código abierto de Umbraco.

La información para realizar la llamada mediante reflexión se tomó de la tabla db que tenía el nombre del ensamblado y el espacio de nombres de la clase que implementó la interfaz.El problema era que la llamada de reflexión fallaba cuando se fusionaba dll; sin embargo, si dll estaba separado, todo funcionaba bien.¿Creo que el problema puede ser similar al que está teniendo Longeasy?

Recién estoy comenzando a usar ILMerge como parte de mi compilación de CI para combinar muchos contratos WCF detallados en una sola biblioteca.Funciona muy bien, sin embargo, la nueva biblioteca fusionada no puede coexistir fácilmente con sus bibliotecas de componentes u otras bibliotecas que dependen de esas bibliotecas de componentes.

Si, en un nuevo proyecto, hace referencia tanto a su biblioteca ILMerged como a una biblioteca heredada que depende de una de las entradas que proporcionó a ILMerge, encontrará que no puede pasar ningún tipo de la biblioteca ILMerged a ningún método en la biblioteca heredada sin realizar algún tipo de mapeo de tipos (p. ej.mapeador automático o mapeo manual).Esto se debe a que una vez que todo está compilado, los tipos se califican efectivamente con un nombre de ensamblado.

Los nombres también colisionarán, pero puedes solucionarlo usando alias externo.

Mi consejo sería evitar incluir en su ensamblaje fusionado cualquier biblioteca disponible públicamente que exponga su ensamblaje fusionado (p. ej.a través de un tipo de retorno, parámetro de método/constructor, campo, propiedad, genérico...) a menos que esté seguro de que el usuario de su ensamblado fusionado no depende ni dependerá nunca de la versión independiente de la misma biblioteca.

Me parece que la mejor práctica número uno de ILMerge es no utilizar ILMerge.En su lugar, utilice Asamblea inteligente.Una razón para esto es que la mejor práctica número 2 de ILMerge es ejecutar siempre PEVerify después de realizar un ILMerge, porque ILMerge no garantiza que fusionará correctamente los ensamblados en un ejecutable válido.

Otras desventajas de ILMerge:

  • al fusionar, elimina los comentarios XML (si esto me importara, usaría una herramienta de ofuscación)
  • no maneja correctamente la creación de un archivo .pdb correspondiente

Otra herramienta a la que vale la pena prestar atención es Mono.Cecil y la herramienta Mono.Linker [2].

[2]:http://www.mono-project.com/Linker

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top