Silverlight assemblies are not binary compatible with "normal" .NET assemblies. How can it be, considering the fact that the same compiler is used to create both types of assemblies (even though mscorlib.dll is not referenced for Silverlight)?
views:
197answers:
3
+1
A:
The IL code is the same. However the core libraries are different so even the simplest operation in a library compiled for .NET won't work in Silverlight since the library will be referencing external libraries not present in Silverlight.
AnthonyWJones
2009-11-16 12:43:41
This could mean that, for example in Silverlight System.Object could be different and if .NET type would be referenced from Silverlight there could be unpredicted behavior. But restriction, that .NET assembly cannot be referenced from Silverlight assembly is put into IDE and calling csc.exe in command-line would still compile in this case?
Konstantin
2009-11-16 13:27:22
The more correct way to put it probably is that any .NET assembly references mscorlib.dll (at least because any type inherits from System.Object). But mscorlib.dll is not available for Silverlight. Am I right?
Konstantin
2009-11-16 14:34:10
The version of mscorlib used by SL is a different one from the one used by full .NET. You are correct that the referencing restriction is actually one imposed by the IDE.
AnthonyWJones
2009-11-16 15:17:27
A:
The aren't compatible, because Silverlight uses a light weight version of mscorlib.dll. However you can reuse your code written for "normal" .NET on Silverlight with some tricks.
Boris Modylevsky
2009-11-16 12:51:21
What if microsoft had not made it use a light weight version of mscorlib.dll hugh? What would have happen do you thing?
abmv
2009-11-16 12:54:01
If Silverlight used a "normal" set of libraries, users would have to install the whole bunch .NET Framework, when they want to use Silverlight based web sites.
Boris Modylevsky
2009-11-16 14:35:26
+7
A:
Right, so, good question. There's a lot of misconception in this area and it's important to separate fact from fiction.
Fiction: Silverlight assemblies are compiled by magical microsoft gnomes and that makes them incomptiable with the .Net desktop CLR.
Fact: The CLR has this beautifully articulated system called "Fusion".
Each assembly has an assembly manifest embedded as part of the DLL/EXE.
The assembly manifest contains a bunch of stuff (Names of Embbeded Resource, Type System information, etc) and also which other Assemblies are required for this assembly.
Fusion is the part of the CLR responsible for taking that Assembly Manifest dependency and finding the corresponding physical file.
Fusion for Silverlight Assemblies on the Desktop .Net CLR - just works. (assuming all dependencies are present)
Fusion on the Silverlight CLR for desktop assemblies - won't work.
Mainly because the .Net BCL (Base Class Library) DLLs just aren't there. As was mentioned, it's a different mscorlib.dll, agcorlib.dll, System.dll, System.Windows.dll, etc.
The reason those DLLs are different is primarily security. The normal BCLdoes all kind of nasty stuff with pointers, platform specific p/invokes, files, registry and what not. And we can't have that just running the browser.
So, summing up:
Silverlight Asemblies --> Runing on Desktop CLR == Works
Desktop Assemblies --> Running on the Silverlight CLR == Doesn't work
If you'd like a real world example of Silverlight assemblies running on the desktop CLR, check out my article from a year ago @ SILVERLIGHT DLLS ON THE DESKTOP CLR
JustinAngel
2009-11-16 14:24:09
Completely agree with you, Angel, however there are creative ways for coding reusable code that works on both platforms.
Boris Modylevsky
2009-11-16 14:37:25
@Boris: Yes the correct approach would be to use linked source files in VS. Thus generating two assemblies from the same source code.
AnthonyWJones
2009-11-16 15:19:45
@Justin: "Right, so, good question", not good enough for an upvote from you though? ;)
AnthonyWJones
2009-11-16 15:21:23