comment 2248 posted by justinc on 2010-03-03 2:19 AM, 2823 days ago
Fields are now accessed by lambda expressions. However this was a little tricky to implement because MethodCaller does not expose any mechanism for calling fields. The DataMapper does but it's pretty limited. You should consider consolidating the property/field factories into a single method. The two could be built as if they were the same.
comment 2192 posted by justinc on 2010-02-18 5:51 PM, 2836 days ago
Actually looking at this, there is still some ILGeneration code for field accessing (which never happens in SL) but it would be nice to unify this before closing completely.
comment 2190 posted by justinc on 2010-02-18 5:36 PM, 2836 days ago
I believe this one is done now, with your last two changes.
comment 2188 posted by rocky on 2010-02-18 5:20 PM, 2836 days ago
Added type name rewriting to MethodCaller.GetType() for Silverlight, so it has the functionality from SL3.
comment 2187 posted by rocky on 2010-02-18 5:19 PM, 2836 days ago
Removed the #if blocks in MethodCaller so SL now uses nonpublic members when necessary.
comment 2145 posted by justinc on 2010-02-05 11:12 AM, 2849 days ago
THis is mostly done but there is one issue remaining where BindingFlags.NonPublic was not added for Silverlight. This seemed like a good idea but actually it's possible in some cases for silvelright to invoke non public members via reflection (e.g. the member is declared in the same type it's invoked from.
comment 2054 posted by justinc on 2010-01-21 8:35 PM, 2864 days ago
Actually it looks like the DynamicMethodHandlerFactory in the .net version is pretty well segmented already. I should probably just use replace the body of that with linq expressions to build the delegates. This will make it easier to maintain and will allow Silverlight to use the same code.
comment 2052 posted by justinc on 2010-01-21 5:28 PM, 2864 days ago
It should be possible in both in .net4 using linq expressions to generate delegates.
The general strategy will be to use the current method to find the method to invoke then to build lambda expression that sort of looks like one of the two following forms:
// this is a call to a method with a return type of void.
comment 2049 posted by rocky on 2010-01-20 5:50 PM, 2865 days ago
merged bug 684 into this bug: MethodCaller is able to invoke invalid method overloads
comment 2047 posted by rocky on 2010-01-20 5:49 PM, 2865 days ago
Justin, maybe this can be resolved by changing MethodCaller to use expression trees instead of dynamic method invocation?
Solution needs to work on .NET and SL (ideally MethodCaller.cs would be a linked file :) )
comment 2010 posted by rocky on 2010-01-14 10:59 AM, 2871 days ago