Tuesday, 17 March 2009

Compact Framework Woes, revisted

A cautionary tale for CF development...

Previously, I mentioned a compact framework permissions gotcha that was hurting protobuf-net. Other than making thinks public, I never got much further, but at least I can understand the issue.

Well, now I have hit another issue (in the wild); for a complex model, the VM is throwing a MissingMethodException - but simply when invoking a regular generic method - no reflection etc:

    prop = CreateProperty<T>(type, ref format);

This surfaces in a test case where we add lots of different (but very similar) types to the model - eventually it simply gives up, and can't resolve the generic method (even though it worked fine for the identical property on the last "n" similar types). One can only assume that it has hit an internal limitation of the CF runtime.

The good news is that the regular framework doesn't exhibit this; the bad news is that this doesn't help me... to support complex models I expect I will have to take out some of the generics, and use a bit more casting / boxing. Which probably won't kill me.

In truth, I've probably out-clevered myself through over-use of generics - and in some ways, it has stopped me using a decorator quite as cleanly as I'd like. Lesson learnt...


Igor said...

Hi, first of all, thanks for the good, easy, power library. I try use it in my projects.

Now i communicate .NET 3.0 Win32 Application, .NET 3.5 CF Win Mobile, Win CE 6.0 Apps and Android 2.0 Mobile Application. ProtoBuf .NET very help me.
But, one problem with CF 3.5 applications.

Exception non supported -
System.Reflection.RuntimeMethodInfo.GetParameters(), when used
ProtoBuf.Serializer.NonGeneric.Deserialize/Serialize - methods.

ProtoBuf.Serializer.Serialise - work succesful.

Does ProtoBuf.Serializer.NonGeneric. work in CF 3.5?

Marc Gravell said...

@Igor sounds like a bug ; you might want to log that (with an example) on the project site

Vlad said...

Hi Mark,
First of all I'd like to express the deep respect for all the useful info you provided to people.

We've hit the same wall and I hate to do the refactoring and combine different classes into one.

Is there any good news about the problem raised by Igor?

Thank you in advance,

Marc Gravell said...

@Vlad hi, I believe this should work in v2 - simply, in v2 the call path is inverted, so generic calls non-generic, which works much better on CF.