This post originated from an RSS feed registered with .NET Buzz by Ashish Shetty. Original Post: How to tell a Silverlight assembly from a .NET Framework one? Feed Title: Even a chimp can write code Feed URL: http://nerddawg.blogspot.com/rss.xml Feed Description: Ideas on software and elsewhere by Ashish Shetty: erstwhile chimp and occasional re-inventor of the wheel. Latest .NET Buzz Posts Latest .NET Buzz Posts by Ashish Shetty Latest Posts From Even a chimp can write code

Silverlight 2 application code is compiled to Common IL and packaged into assemblies (.dll) which are in turn deflated into a Zip file (container with .xap extension). The IL is a CPU- and platform- independent instruction set. The Silverlight runtime has in it the Core CLR which executes this IL. Given that .NET Framework involves much of the same things save for the .xap packaging, how does one tell between a DLL built for Silverlight versus one for .NET Framework?

Well, the answer is in one of the security assumptions that Silverlight's Core CLR makes to distinguish a core platform assembly from a transparent code app assembly. The mscorlib.dll in Silverlight is signed with a different key than it's namesake in .NET Framework. This is apparent in it's full name, or specifically it's public key token.

The public key token for mscorlib in Silverlight is:

while the public key token for mscorlib in .NET Framework is:

So the trick to sniffing out an arbitrary managed code assembly for its allegiance - Silverlight or .NET Framework - is to look through it's list of referenced assemblies, locate mscorlib and then check the public key token. Here is a sample application that does that.