2008-11-23 11 views
8

Hace poco leí una pregunta sobre enlaces estáticos y dinámicos, que me recordó algunas preguntas que tuve al respecto. Desde esa publicación, puedo ver cuál es la diferencia técnica (incluidos los contenidos de los archivos de objeto directamente en lugar de solo señalarlo), pero me gustaría saber un poco más sobre los pros/contras de hacerlo.Ventajas de enlace estático

Hace un tiempo, un amigo mío que ha estado programando varios años se lamentaba de que C# no está vinculado de forma estática y diciendo que esa era la característica que más deseaba para una versión futura. Desafortunadamente soy un novato y realmente no entiendo esta afirmación.

¡Gracias por cualquier aclaración!

Respuesta

4

No estoy seguro si la vinculación estática es realmente una buena idea en C# para ser honesto, por un millón de razones. Una razón es que, a diferencia de los lenguajes como C o C++, C# tiene el concepto de ensamblados, que son básicamente archivos ejecutables o DLL.

Ahora, si quieres cosas de enlace estáticamente en .NET, ya sea

  • clases de mezcla de varios ensamblados en un solo conjunto. Eso rompería muchas cosas, como el modificador de acceso "internal".
  • Tiene más de un ensamblaje en el mismo ejecutable.Sin embargo, eso haría que todo el concepto de ensamblaje sea inútil y requeriría rediseñar el enfoque de la reflexión en .NET Framework.

Estoy seguro de que hay una manera inteligente de evitar estos problemas, pero no veo el punto de vincular estáticamente en un entorno administrado como .NET o Java. Quiero decir, la vinculación estática de hecho mejora el rendimiento, pero no tanto. Y de todos modos, no usamos lenguajes administrados para su velocidad de ejecución.

Otro problema es el infierno de DLL, pero en .NET, eso es casi un problema resuelto de todos modos.

+25

Querer tener un .exe en lugar de uno .exe y 30 .dll es una buena razón, mis clientes no deberían tener que arrastrar más de 30 archivos solo porque quería refactorizar mi software en múltiples proyectos. Y no veo por qué todo lo que dijiste * tiene * que sea como es, básicamente podrían almacenar el .dll en el .exe y cargarlo como un .dll cuando sea necesario. No hay una buena razón por la que no se pueda admitir la vinculación estática. –

+2

Acabo de enterarme recientemente de que F # de hecho lo admite. –

+0

Aquí hay una solución, solo asegúrese de que el nombre del recurso apunte a su ensamblado real: http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr -via-c-third-edition.aspx – Kaganar

7

Un ejecutable estáticamente contiene todos los objetos que necesita para que no se invoque una DLL externa cuando se ejecuta. La ventaja es que es portátil en muchas plataformas sin importar qué versión de DLL se haya instalado en ese sistema. La gran desventaja es que probablemente desperdicie espacio en el disco ya que está incluido en el código ejecutable que ya está presente en el sistema/DLL externos. Además, creo, pero no estoy muy seguro, que los archivos DLL se carguen en la memoria principal solo una vez, sin importar cuántos ejecutables los estén usando, pero si vincula estáticamente los objetos de la biblioteca dentro de su ejecutable, carga el mismo código dos veces (uno para el DLL utilizado por el resto de los programas y uno para su ejecutable). Por otro lado, esto podría ser una ventaja en lugar de una desventaja, ya que el ejecutable contiene solo los objetos de las bibliotecas externas que necesita, no toda la biblioteca. Una DLL se carga en la memoria como un todo cuando una aplicación lo necesita.

La vinculación estática es ideal para compilar aplicaciones pequeñas que desea transportar de un sistema a otro como una herramienta pequeña. Es decir. fue realmente útil para mí tener una versión compilada estáticamente de tcpdump cuando no estaba incluida en cada distribución de Linux. Estaba destinado a funcionar en todos los Linux, independientemente de la versión de Kernel, glibc u otras bibliotecas del sistema. Tal vez no tiene tanto sentido en el mundo de Windows ya que las plataformas son mucho más homogéneas. Si compila para Windows XP/NET vX.X funcionará en muchas computadoras. Si compila algo para Debian X.X, seguramente no funcionará en versiones anteriores o posteriores de Debian u otras distribuciones como Redhat.

Este thread también puede resolver sus dudas.

7

La ventaja de la vinculación estática es que elimina la dependencia externa de las bibliotecas, es decir, el comportamiento de la biblioteca que está utilizando nunca va a cambiar porque alguien cambió la biblioteca en el disco. Esa es también una de las desventajas de la vinculación estática; si el sistema operativo cambia y se necesita una nueva versión de la biblioteca para que funcione correctamente, debe proporcionar una versión actualizada de su archivo binario. De manera similar, si se agrega una corrección de errores a la biblioteca, no se obtiene automáticamente la corrección de errores si se ha vinculado estáticamente.

La mayoría de los sistemas operativos (de hecho, probablemente todos estos días) pueden cargar una copia de una biblioteca dinámica para procesos múltiples, por lo que en UNIX se denominan objetos compartidos.

1

Hay un buen ejemplo de la diferencia entre enlaces estáticos vs dinámicos. Si consulta el proyecto InkScape, encontrará InkscapePortable e InkScape. InkscapePortable se ejecutará en una memoria USB. InkScape no lo hará.

2

Todos los artículos necesarios se empaquetan en un archivo ejecutable. Por lo tanto,

  • No necesita instalar ningún otro producto. Solo copia y ejecuta. O corre donde está. Sin instalador, sin advertencias, sin errores extraños debido a la versión DLL incorrecta. Eso es todo.
  • También sus usuarios pueden disfrutar de esta simplicidad. Esto usualmente es mucho más importante. Nadie se alegra de instalar dependencias. Especialmente si es enorme como .NET framework.

Por supuesto, el tamaño del archivo ejecutable aumentará, pero debe ser menor que un montón de archivos de gráficos tontos.

+0

Las personas que piensan en minimizar el espacio en disco a expensas del infierno de la dependencia tienen sus prioridades al revés –

Cuestiones relacionadas