Daniel pinged me today that he stumbled upon odd issue while trying to update Moq to use Castle DynamicProxy 2.2. I investigate a bit more and it appears to be one of these this-cannot-be-happening-select-is-broken situations.
When DynamicProxy tries to replicate an attribute on one method, its CustomAttributeData contains contradictory information. It happens only when running on .NET 4 (the method in question does not have the attribute in previous versions of BCL)
That’s the method in question in Reflector:
Here’s simplified code sample that reproduces the issue:
var method = typeof(HtmlInputText).GetMethod("GetDesignModeState", BindingFlags.Instance | BindingFlags.NonPublic);
Debug.Assert(method != null, "method != null");
var attributes = CustomAttributeData.GetCustomAttributes(method);
Debug.Assert(attributes.Count == 1, "attributes.Length == 1");
var attribute = attributes[0];
Debug.Assert(attribute.Constructor.GetParameters().Length == attribute.ConstructorArguments.Count, "This fails");
Now – what am I missing? Is this really bug in BCL v4 or am I doing something wrong here?
Comments
CAS security attributes are not encoded as traditional attributes. My guess is that they re-create the custom attribute based on the data in the security attribute blob, but they’re not passing the security action argument to the constructor. You should file a connect bug about it (gluck with that).
I’m looking into this…
JB is exactly right – this is an artifact of the fact that declarative security attributes have their own metadata table, and aren’t "real" custom attributes at all. Somre more details are here: blogs.msdn.com/…/…security-and-reflection.aspx
-Shawn