DO4 and Silverlight: will it be easy to make them friends?

Today I've been analyzing this. Briefly, yes - it won't be too complex. Hopefully, 2-3 man-months. Now the details:

1) Dependencies on assemblies which aren't compatible with Silverlight
- Obviously we'll get rid of all the providers except memory provider (in future - file system provider as well).
- It's easy to get rid of Parallel FX as well - actually we don't use it intensively for now.
- The only left one is log4net. Again, quite easy: we use our own logging abstraction layer I'm promising to describe for very long time. In our case logging is fully replaceable.

Btw, there is PostSharp as well, but its 1.5 and upcoming 2.0 versions are ready for Silverlight. So we must migrate to one of them. Most likely, we'll wait for 2.0.

2) Overwhelming Reflection & Reflection.Emit limitations in Silverlight
As it looks like, it won't be too complex. Silverlight limits the reflection only to members your code can access directly, so no any privates or internals. We have lots of internal classes we're reflecting by AssociateProvider (it provides comparers, hashers, size calculators, arithmetics and so on), but actually we've made them internal just because they aren't must be necessarily public. They implement the interfaces AssociateProvider looks for, that's it.

So in majority of cases it will be enough to open such types for public access - they're anyway frequently "hidden" into Internals namespaces.

We also emit lots of code - e.g. whole Tuples infrastructure is build on Reflection.Emit. But AFAIK we never used such things as accessing internal or private members of types we don't emit. Must be checked, of course, but at the first glance it seems relatively easy to fix.

I remember just one place: we make PostSharp to build protected constructors for Entity & Structure ancestors - they look like this one. They're used on materialization. But we can make PostSharp to emit some public static member invoking them as well (specially for Silverlight).

3) Absence of serialization in Silverlight
This is the most complex part. On the other hand, we anyway need fast binaty serialization and currently looking for good approaches there. DO4 already uses serialization few several places, including deserialization of aspects and Metadata.Extension instance storing simplified version of current Storage model (I wrote we use it to make schema upgrade layer to be aware of type-level structure, instead of just table-level structure) and Storage itself (Entities already support serialization by IFormatter). Furthermore, upcoming sync and file system provider also require it.

Our final set of decisions related to serialization is described in this issue. Having it implemented, we'll get fully portable serialization layer.

It seems that's all. If you know any other pitfalls, please notify us. If you're interested in getting Silverlight support, please vote for it in upcoming survey.