I have gotten a lot of questions from Silverlight users wanting to know if VistaDB will be able to load in Silverlight 4. This would be a great thing if you could actually have a client side database in a Silverlight app. I still am not 100% convinced this is a good idea in most circumstances, but for offline Silverlight apps this would definitely make sense. It would allow you to store data locally in isolated storage on the users machine, and then send it to the server when they next are online. The typical airplane offline app scenario.
Nope – Not really using .Net
The short answer – NO. Silverlight 4 can load “some” assemblies, but nothing built for .Net 4 or .Net 4 Client Profile.
I built a .Net assembly as a .Net 4 client profile, and then wanted to load it in a Silverlight app. This is the dialog you will see when you attempt it.

Hmm, can’t I just target Silverlight within my current Visual Studio solution? No. You have to build a new Silverlight assembly. I tried this and was surprised to see the namespaces loaded in a Silverlight control assembly by default.
You can’t load any desktop assemblies into the Silverlight assembly, you have to work with the Silverlight subset of the framework. You can’t do things like ADO.NET, you can’t even implement the interfaces because they don’t exist. Why not let them exist, but not allow them to load due to platform restrictions?
Custom built Silverlight assembly you can load from your .Net app?
Take a look at the using statements at the top of a Silverlight control library. Hmm, notice anything strange? Maybe that everything is in the System.Windows namespace?
Why aren’t these API’s called Microsoft.Silverlight.xxx? Or even System.Silverlight.xxx? Most of these have nothing to do with Windows (the Operating System or User Interfaces). I know many of them come from the WPF included in .Net 3, but they don’t use the same runtime anyway.
According to this blog post about assembly import in Silverlight 4, there are only 5 dlls you can include within your assembly. Note that none of this implement things like ADO.NET or even most of what an API would need to work with local data. I personally do not consider object serialization to be a viable data store, not even close.
For SL 4 and .NET 4, we have made the following assemblies portable:
- Mscorlib
- System
- System.Core
- System.ComponentModel.Composition
- Microsoft.VisualBasic
Hmm, looks like a very small subset of .Net indeed. Nothing like the “run .Net 4 assemblies” I was expecting after reading the posts previous to this one about assembly loading.
More...