2009-11-16 4 views
6

Los ensambles Silverlight no son compatibles con los ensamblajes .NET "normales". ¿Cómo puede ser, teniendo en cuenta el hecho de que se utiliza el mismo compilador para crear ambos tipos de ensamblados (aunque no se hace referencia a mscorlib.dll para Silverlight)?La razón por la que el ensamblaje de Silverlight no es compatible con los ensamblajes .NET "normales"

+2

¿Qué quieres decir con 'compatible binario'? –

+0

La frase "No compatible con binarios" se usa comúnmente para describir el hecho de que no se puede hacer referencia al ensamblaje "normal" desde el ensamblaje de Silverlight y viceversa. – Konstantin

Respuesta

9

Bien, entonces, buena pregunta. Hay una gran cantidad de conceptos erróneos en esta área y es importante separar los hechos de la ficción.

Ficción: Los ensambles Silverlight son compilados por gnomos mágicos de Microsoft y los hacen incomptibles con .Net desktop CLR.

Hecho: El CLR tiene este sistema bien articulado denominado "Fusión ".
Cada conjunto tiene un manifiesto de ensamblado integrado como parte de la DLL/EXE.
El manifiesto de ensamblaje contiene un montón de cosas (nombres de recurso embebido, información de sistema de tipo, etc.) y también qué otros ensamblajes se requieren para este ensamblaje.

Fusion es la parte del CLR responsable de tomar esa dependencia del Manifiesto de ensamblaje y encontrar el archivo físico correspondiente.

Fusion for Silverlight Ensambles en el escritorio .Net CLR - solo funciona. (suponiendo que todas las dependencias están presentes)

Fusion en el Silverlight CLR para ensamblajes de escritorio: no funcionará.
Principalmente porque las DLL de .Net BCL (Biblioteca de clases base) simplemente no existen. Como se mencionó, es un mscorlib.dll diferente, agcorlib.dll, System.dll, System.Windows.dll, etc.
El motivo por el que esas DLL son diferentes es principalmente security. El BCL normal tiene todo tipo de cosas desagradables con punteros, p/invocaciones específicas de la plataforma, archivos, registro y otras cosas. Y no podemos tener eso simplemente ejecutando el navegador.

Así, resumiendo:
Silverlight Asemblies -> Runing en el escritorio CLR == funciona
Asambleas de Escritorio -> Ejecutar en el CLR de Silverlight == No funciona

Si desea un ejemplo del mundo real de los ensamblajes de Silverlight que se ejecutan en el escritorio CLR, echa un vistazo a mi artículo de hace un año @SILVERLIGHT DLLS ON THE DESKTOP CLR

+0

Estoy totalmente de acuerdo contigo, Angel, sin embargo, hay formas creativas para codificar código reutilizable que funciona en ambas plataformas. –

+0

@ Boris: Sí, el enfoque correcto sería usar archivos fuente vinculados en VS. Generando así dos ensambles a partir del mismo código fuente. – AnthonyWJones

+0

@Justin: "Bien, entonces, buena pregunta", ¿no es lo suficientemente bueno para un voto de tu parte? ;) – AnthonyWJones

0

El código IL es el mismo. Sin embargo, las bibliotecas principales son diferentes, por lo que incluso la operación más simple en una biblioteca compilada para .NET no funcionará en Silverlight, ya que la biblioteca hará referencia a bibliotecas externas que no están presentes en Silverlight.

+0

Esto podría significar que, por ejemplo, en Silverlight System.Object podría ser diferente y si se hace referencia al tipo .NET desde Silverlight, podría haber un comportamiento imprevisto. Pero la restricción, que el ensamblado de .NET no puede ser referenciado desde el ensamblado de Silverlight, se pone en IDE y se llama a csc.exe en la línea de comandos todavía compilaría en este caso? – Konstantin

+0

La forma más correcta de expresarlo es que cualquier ensamblado .NET hace referencia a mscorlib.dll (al menos porque cualquier tipo hereda de System.Object). Pero mscorlib.dll no está disponible para Silverlight. ¿Estoy en lo cierto? – Konstantin

+0

La versión de mscorlib utilizada por SL es diferente de la utilizada por .NET completo. Tiene razón en que la restricción de referencia es en realidad una impuesta por el IDE. – AnthonyWJones

0

No son compatibles, porque Silverlight usa una versión liviana de mscorlib.dll. Sin embargo, puede reutilizar su código escrito para .NET "normal" en Silverlight con algunos trucos.

+0

¿Qué pasa si Microsoft no lo hizo usar una versión ligera de mscorlib.dll hugh? ¿Qué hubiera pasado? ¿Lo crees? – abmv

+0

Si Silverlight utilizaba un conjunto "normal" de bibliotecas, los usuarios tendrían que instalar todo el conjunto .NET Framework, cuando quisieran utilizar sitios web basados ​​en Silverlight. –

Cuestiones relacionadas