We recently hit a bug in our code that was caused by a subtle difference in how DevForce behaves under Silverlight compared to non-Silverlight environments. We found out the hard way that when DevForce raises an 'all properties have changed' event in Silverlight, it does so by using string.Empty in the PropertyChanged event. However, in non-Silverlight null is used instead. This wasn’t that hard of a fix on our end – we likely should have been watching out for either null or string.Empty all along. But it got us worried if there are other subtle differences like this that we should be looking out for.
Are there any other known differences between Silverlight and non-Silverlight like this? Obviously there are some differences such as Silverlight not allowing synchronous queries...but that is well documented. I'm looking for small things like this which might break code that previously worked fine in Silverlight.
Sorry you ran into the PropertyChanged issue. That divergence actually came about due to an old bug in the SL DataForm, but it's never been re-addressed in DevForce because MS documentation does say that both null and the empty string do the same thing. FWIW, DF uses the empty string here in all non-full .NET environments.
We don't have any documentation on these subtle differences. In general, most environment differences result in a different surface area, usually with a reduced API. So as you noted the synchronous methods are only found in the .NET assemblies, while you'll find XAP-related APIs in the SL assemblies. Other "missing" or changed features would be things like file I/O and .config file handling.
In general DF tries to rationalize the APIs and behaviors across environments, although there can be subtle differences or performance impacts in the underlying implementations. For example, WCF, composition (MEF), serialization and reflection are a few areas which we've found don't always work quite the same across environments, although we've tried to mitigate these within DevForce so apps don't see the issues. DF also has shim/dummy implementations for some attributes (mostly for ODATA and data annotations) in non-.NET environments, which could cause issues if you're expecting the real types.
I've scanned for a few differences which might not be obvious: 1) a parameterless constructor is required when cloning in non-.NET, 2) compile-time validation of the use of the ProvideEntityAspect and ProvideComplexAspect attributes is done only in .NET, 3) attempts to do encryption/decryption with the FIPS parameter set will throw a NotSupportedException in non-.NET.
There are differences in design-time support too. In SL weird security and serialization exceptions will be thrown by VS when using the ECS or using design-time data based on a code first model.
I should also note that if you're doing .NET unit testing of your SL code you cannot assume the code will also work in SL. You really need to test in SL too to avoid surprises.
If you have questions about any specific areas of DevForce or run into any unexpected environment differences let us know.