El estado de Linkers para aplicaciones .NET (también conocido como “Please Sir, May I have a Linker” edición 2009)

Mucha gente aquí probablemente esté familiarizada con una de las publicaciones de blog más populares de Joel Spolsky , ” Por favor , señor, puedo tener un enlazador” , donde solicita una forma de eliminar las dependencias en el marco .NET para que se pueda desarrollar una aplicación independiente. vendido.

Jason Zander, del equipo de desarrollo de Visual Studio, en ese momento, respondió con sus puntos de vista sobre el tema , argumentando que el tema es algo discutible: la capacidad de solucionar problemas de seguridad en el tiempo de ejecución (entre otros puntos) era su principal preocupación. En general, la pequeña sobrecarga valió la pena.

Avancemos hasta 2009. Hay algunos grupos que ahora dicen tener enlaces de C #. (Jason Zander incluso dijo que no tardaría mucho en implementar uno.) En lugar de la linda descarga de .NET 1.0 de doce docenas, ahora tenemos un instalador .NET 3.5 completo y multiplataforma de 200-300 mb que contiene versiones de .NET para x86, x64 e ia64. Las sugerencias de Microsoft para disminuir el tamaño del tiempo de ejecución incluyen:

  • Desempaquete la redistribución, elimine las plataformas de destino que no desea y vuelva a armarlas
  • Utilice el progtwig de arranque web que solo descarga las bibliotecas para su plataforma
  • Utilice el instalador de Client Profile (nuevo a fines de 2008) que tiene bibliotecas limitadas y solo funciona para x86.

Para empeorar las cosas, según lo entiendo (corríjanme si me equivoco), el perfil del cliente ni siquiera se registra con Windows como si tuviera .NET 3.5 instalado. Esto significa que si hay múltiples aplicaciones cliente .NET 3.5 instaladas en la computadora, ninguna se verá y el tiempo de ejecución se volverá a instalar una y otra vez.

Realmente no sé lo que Microsoft está pensando aquí. Incluso suponiendo que la instalación en el peor de los casos será para una plataforma de destino (por ejemplo, x64) y solo se deben incluir esas bibliotecas, aún está viendo más de 60 MB de sobrecarga en su aplicación. Incluso una de las aplicaciones .NET más conocidas, Paint.NET, estaba plagada de dificultades para instalar la aplicación debido a las enormes dependencias de .NET. Si TIENEN problemas para distribuir una aplicación gratuita, ¿qué hay del rest del mundo? Al final, tuvieron que hacer un bootstrapper que instaló Microsoft Installer 3.1, el arrancador de tiempo de ejecución de .NET y todos sus otros librairs dependientes antes de que pudieran instalar su propia aplicación.

Entonces que tal. Un enlazador. ¿Existen algunos buenos, o una herramienta que simplemente hace posible la creación de una aplicación C # sin requerir que el usuario instale el masivo .NET runtime?

Actualización: por lo tanto, parece que hay un par de opciones:

Mono:

  • Mono tiene su propio enlazador . De la respuesta a continuación, parece que funciona bastante bien.

.RED:

  • Xenocode parece ser uno que está disponible y funciona.
  • Thinstall es otro recomendado, y es de VMware.
  • Hay otro enlazador de Remotesoft . Lo cargan como un “ofuscador”. ¿Algún pensamiento allí?
  • Encontré otra por Rustemsoft llamada Skater .NET Obfuscator . ¿Alguien familiarizado con ellos?
  • También se sugirió ILmerge de Microsoft ; esto parece que solo realiza una parte de la tarea (es decir, fusionar bibliotecas, no eliminar los bits no utilizados).

Parece que las herramientas Mono se están usando; ¿Qué tal las herramientas basadas en .NET? ¿Alguna otra experiencia con ellos, o tendremos que esperar a que Microsoft lo saque a 3.5? Me estremezco al pensar cuánto tiempo tardará en salir .NET 4.0 …

El caso del Mono Linker .

No puedo hablar mucho sobre las otras piezas de software que se enumeran aquí, pero como autor de Mono Linker, puedo decir lo que hace y lo que no.

El Mono Linker es solo un enlazador administrado, por lo que, por definición, toma ensamblajes y elimina lo que no es necesario para ejecutar un progtwig. No fusiona ensamblajes todos juntos, y no hace un progtwig nativo de ellos.

Hay un clon Mono.Merge de ILMerge, pero no está completo y su autor no lo está manteniendo. Para generar un progtwig nativo que contenga el tiempo de ejecución Mono y los ensamblajes, Mono proporciona la herramienta mkbundle .

Además, como solo se trata de una herramienta administrada, que está alterando ensamblajes, si le da ensamblajes con nombres fuertes y no tiene las claves privadas para volver a iniciar sesión, tendrá problemas para ejecutar dichos ensamblajes.

Escribí un par de publicaciones en el blog sobre el enlazador:

  • Una presentación del enlazador
  • Un combinado usado del enlazador y mkbundle

Sobre nuestra experiencia con el Enlazador. El Enlazador se usa actualmente en dos partes del proyecto Mono. Se usa para generar el ensamblado que distribuimos para que las personas incorporen nuestro comstackdor de C #, Mono.CSharp.dll. Puede ver la presentación de Miguel en el PDC, que describe cómo lo hacemos. Es bastante sencillo, y es un uso básico del Enlazador, que es una herramienta personalizable, y es bastante fácil escribir pasos personalizados para él.

Un uso más complejo del Linker es la forma en que creamos nuestros ensamblajes Moonlight . Moonlight es nuestra implementación de Silverlight, los ensamblajes son un subconjunto de los ensambles de escritorio. Así que vinculamos nuestros ensambles de escritorio para reducir sus tamaños y, mediante pasos personalizados, estamos transformando la API pública para que coincida con la de Silverlight.

Así que sí, el Enlazador tiene algunos bordes bastante toscos, como la interfaz de línea de comando, por ejemplo, o el hecho de que tienes que saber realmente lo que estás haciendo, o puedes terminar con ensamblajes extraños, pero en general, funciona realmente bien para nosotros

FWIW

Mono ha tenido un enlazador durante bastante tiempo.

Aquí hay un ejemplo de cómo usar mkbundle.

http://www.xenocode.com/

Esto es lo que usamos. Hasta ahora, después de un año o de un uso algo limitado (tal vez 500 instalaciones en la naturaleza), cero problemas.

Y tiene un precio bastante razonable. Tienen un software de virtualización completo más caro (que agrupa su aplicación con otras aplicaciones e incluso una O / S). Pero no necesitamos todo eso. Nuestro costo hace aproximadamente un año era de $ 400. Creo que ahora es un poco más caro, pero mucho menos que Thinstall.

Y tienen excelentes demostraciones que puedes descargar, como IE 8. No requiere instalación.

El perfil del cliente se registra con Windows, pero de una manera especial, ya que no desea confundir una máquina con solo el perfil del cliente con una máquina con .net 3.5 completo.

Perfil del cliente:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\DotNetClient\v3.5\Install 

Full .net 3.5:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5\Install 

Este es el principal que escuché hace mucho tiempo en .NET Rocks. En realidad, nunca me dieron un cambio para probarlo

http://www.remotesoft.com/linker/

Nunca lo usé, pero he oído que puedes hacer cosas similares con .NET Reactor

Estuve discutiendo (bajo mi seudónimo “Mr Analogy”) la necesidad de un enlazador en el foro de Joel por un tiempo antes de escribir ese artículo. La proliferación de enlazadores parece haber justificado mi preocupación (tristemente).

http://www.thinstall.com/

De las personas con las que he hablado, se las considera bastante bien, aunque la última vez que revisé la licencia era onerosa ($ 2k / año por licencia de la aplicación). Parecen dirigirse a tiendas de TI en lugar de al desarrollador de SW. El hecho de que no pueda encontrar precios en su sitio sugiere (para mí) que es costoso.

Hay un excelente artículo sobre CodeProject que habla sobre algunos de los “vinculadores” y cómo funcionan.

http://www.codeproject.com/KB/dotnet/internals_native.aspx