Select is broken? (.NET 4)

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)

Select is broken

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?


Jb Evain says:

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…

Shawn says:

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:…/…security-and-reflection.aspx