Possible breaking change in 3.8.1 for Silverlight - MethodAccessException for AddObjectAuthorizationRules

Jaans posted on Saturday, November 21, 2009

Disclaimer: I'm still trying to piece it all together, so I could be wrong on this.

I possibly found an issue which did not exist / happen with 3.7.x, but as soon as I moved to 3.8.0/3.8.1, the runtime issue (described below) started to happen.

I'm getting a "System.MethodAccessException" for my Silverlight (Client-side) business objects, specifically on the :
"private static void AddObjectAuthorizationRules()" method during deserialisation triggered upon the fetch completed.

This only happens once and initially (probably because the method is static). It's not about the code inside that method, since I also get the sam issue with an empty method.

If I change the method access to be public, the problem goes away - but that is highly undersireable and not encapsulated.

Unless I'm wrong, this method is supposed to be private for object authorization rules.

The issue also doesn't happen if there isn't such a method present.

What's changed regarding this? It seems like a change in the serialization code.

Here is the stack trace:
StackTrace:
at System.Reflection.MethodBase.PerformSecurityCheck(Object obj, RuntimeMethodHandle method, IntPtr parent, UInt32 invocationFlags)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at Csla.Security.ObjectAuthorizationRules.GetRoles(Type objectType)
at Csla.Security.AuthorizationRules.GetAllowEditRoles(Type objectType)
at Csla.Security.AuthorizationRules.CanEditObject(Type objectType)
at Csla.Silverlight.CslaDataProvider.RefreshCanOperationsValues()
at Csla.Silverlight.CslaDataProvider.set_IsBusy(Boolean value)
at Csla.Silverlight.CslaDataProvider.SetError(Exception value)
at Csla.Silverlight.CslaDataProvider.RaiseDataChangedEvents()
at Csla.Silverlight.CslaDataProvider.b__0(DependencyObject o, DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.RaisePropertyChangeNotifications(DependencyProperty dp, Object newValue, Object oldValue)
at System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value, Boolean allowReadOnlySet, Boolean isSetByStyle, Boolean isSetByBuiltInStyle, PropertyInvalidationReason reason)
at System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value)
at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value)
at Csla.Silverlight.CslaDataProvider.set_ObjectInstance(Object value)
at Pragma.OnKey.Express.Silverlight.UI.WorkOrder.Feedback.<>c__DisplayClass4.b__1(Object workOrderSender, DataPortalResult`1 workOrderFetchCallback)
at Csla.DataPortal`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortal`1.proxy_FetchCompleted(Object sender, DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.proxy_FetchCompleted(Object sender, FetchCompletedEventArgs e)

sergeyb replied on Sunday, November 22, 2009

I am pretty certain this existed in 3.7 as well. This is not a bug though. The reason for this behavior is that reflection in Silverlight is limited to public method calls, so in Silverlight you have to make this method public.

Sergey Barskiy
Principal Consultant
office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation


-----Original Message-----
From: Jaans [mailto:cslanet@lhotka.net]
Sent: Sunday, November 22, 2009 12:47 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Possible breaking change in 3.8.1 for Silverlight - MethodAccessException for AddObjectAuthorizationRules

Disclaimer: I'm still trying to piece it all together, so I could be wrong on this.

I possibly found an issue which did not exist / happen with 3.7.x, but as soon as I moved to 3.8.0/3.8.1, the runtime issue (described below) started to happen.

I'm getting a "System.MethodAccessException" for my Silverlight (Client-side) business objects, specifically on the :
"private static void AddObjectAuthorizationRules()" method during deserialisation triggered upon the fetch completed.

This only happens once and initially (probably because the method is static). It's not about the code inside that method, since I also get the sam issue with an empty method.

If I change the method access to be public, the problem goes away - but that is highly undersireable and not encapsulated.

Unless I'm wrong, this method is supposed to be private for object authorization rules.

The issue also doesn't happen if there isn't such a method present.

What's changed regarding this? It seems like a change in the serialization code.

Here is the stack trace:
StackTrace:
at System.Reflection.MethodBase.PerformSecurityCheck(Object obj, RuntimeMethodHandle method, IntPtr parent, UInt32 invocationFlags)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at Csla.Security.ObjectAuthorizationRules.GetRoles(Type objectType)
at Csla.Security.AuthorizationRules.GetAllowEditRoles(Type objectType)
at Csla.Security.AuthorizationRules.CanEditObject(Type objectType)
at Csla.Silverlight.CslaDataProvider.RefreshCanOperationsValues()
at Csla.Silverlight.CslaDataProvider.set_IsBusy(Boolean value)
at Csla.Silverlight.CslaDataProvider.SetError(Exception value)
at Csla.Silverlight.CslaDataProvider.RaiseDataChangedEvents()
at Csla.Silverlight.CslaDataProvider.b__0(DependencyObject o, DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.RaisePropertyChangeNotifications(DependencyProperty dp, Object newValue, Object oldValue)
at System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value, Boolean allowReadOnlySet, Boolean isSetByStyle, Boolean isSetByBuiltInStyle, PropertyInvalidationReason reason)
at System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value)
at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value)
at Csla.Silverlight.CslaDataProvider.set_ObjectInstance(Object value)
at Pragma.OnKey.Express.Silverlight.UI.WorkOrder.Feedback.<>c__DisplayClass4.b__1(Object workOrderSender, DataPortalResult`1 workOrderFetchCallback)
at Csla.DataPortal`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortal`1.proxy_FetchCompleted(Object sender, DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.proxy_FetchCompleted(Object sender, FetchCompletedEventArgs e)

Jaans replied on Sunday, November 22, 2009

Thanks Sergey

I forgot that reflection of private members isn't allowed in Silverlight - so the exception makes sense and seems legitimate.

What is strange is that I have had the exact same code running on CSLA 3.7.2 and 3.8.0 Alpha and Alpha 2 which didn't give me the exception.

I guess it could be that it's been there since before and that the exception didn't get thrown or didn't bubble to the client as it does now.

Perhaps the exception was masked somewhere and recent changes to the serialization code fixed it??

Or perhaps the previous code didn't actually call the AddObjectAuthorizationRules() method on the Silverlight client, never causing the exception to begin with.

Anyway... the bottom line is that CSLA 3.8.1 looks to be working as should and that's the important bit.