The reason why Silverlight assembly is not binary compatible with "normal" .NET assemblies

Question

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)?

Answer 1

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