A word of warning, my experience on this comes from developing for Windows Phone 7, so this might be subtly different from normal Silverlight 3.
JaredPar has pointed out the Silverlight CLR is incompatible with normal CLR. This is not 100% correct as assemblies compiled as Windows libraries will still work under silverlight assuming that they use supported APIs. You can manually edit the silverlight project and add a reference to the normal .NET assembly. Note that you can only add a reference to a compiled assembly and not the project.
The silverlight app will compile and run, but as soon as it tries to use a class that is not present in Silverlight, you get a run-time error.
To demonstrate the difference in APIs, have a look at following screenshots. As you can see the two assemblies have some common APIs, but the Silverlight one has a few missing. As soon as your assembly tries to hit those API the app goes BOOM!
Full .NET 4.0 mscorlib (System.serialization
namespace):
Silverlight 3 mscorlib (System.serialization
namespace):
The disadvantage of linking a full .NET assembly is that you wouldn't know until runtime which APIs are not supported. Considering that potentially some supported system API can use unsupported system API, there is no easy way to work this out ahead of time.
There are things you can do to make parallel development easier. The approach recommended by Microsoft is to have separate project for .NET and Silverlight that share the same source code. You can do it manually by adding files as links to the project. It's a bit of a maintenance nightmare, but at least most errors will be caught at compile time.
So now when you compile something that references API missing in Silverlight you get an error:
public class SerializableExample: IEquatable<string>, System.Runtime.Serialization.ISerializable
{
}
error CS0234: The type or namespace name 'ISerializable' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?)
With help of conditional compilation (a-la good ol' C/C++ days) you can disable stuff that is not supported:
public class SerializableExample: IEquatable<string>
#if !SILVERLIGHT
, System.Runtime.Serialization.ISerializable
#endif
{
}
Microsoft also provide a Project linker tool that allows for automatic maintenance of projects that have linked files. Unfortunately the current release does not run on VS2010, you can probably compile the source and make it happen, but I haven't tried.
http://msdn.microsoft.com/en-us/library/dd458870.aspx
Direct download link:
http://download.microsoft.com/download/6/3/8/6382E28D-2EBD-4A4E-BB76-6F425E1C9DB9/MicrosoftPracticesProjectLinkerFeb2009.msi
This Microsoft page describes mult-targeting in excruciating detail.