The story of Spring.NET solution for copying of custom attributes from the original class to the proxy continues with a new member of a .NET2.0 family - System.Reflection.CustomAttributeData http://msdn2.microsoft.com/en-us/library/system.reflection.customattributedata.aspx
Mark Pollack re-pointed me into this direction a day ago. Truly I tried to execute CustomAttributeData.GetCustomAttributes from the debugger line before trying the Mono.Cecil approach few weeks ago, but it threw exception to me and I happily progressed to Mono.Cecil without caring about it.
Mark is absolutely right though that solution by means of only .NET framework would be the best one.
Lets take another look onto the class and how it can be useful in our case.
Applying the code from the msdn sample to the test class:
Brings the following result:
Test class is not picked up randomly. The fact that test runs proves that issue of CustomAttributeData with WebService attribute http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=161522 really seems to be fixed (though still a mystery, how it has been applied? Would not a guy with a clean .NET 2.0 redistributable face this problem?)
I created a post on msdn forum thread dedicated to this issue http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=542365&SiteID=1. Lets see if there is going to be a response.
UPDATE!: Just after an hour, there is a response and Peter Ritchie says:
"Yes, there was a security update that was released recently that had some various other fixes. If you've downloaded and installed .NET 3.5 Beta 2, or Visual Studio 2008 Beta 2; you've also installed .NET 2.0 Service Pack 1 beta."
This explains why I had an exception 6 weeks ago but not now!
It also means that if your system is running on clean .NET 2.0 install you will still have this exception unless you install .NET 2.0 Service Pack 1 beta (on your production system?!)
Here is the list of all other issues logged for this class on the vs feedback site:
Only issue #2 is still marked as active and I was able to reproduce it. This issue is caused by the fact that System.Enum type returns false for its IsEnum method and IsValueType is false as well :):).
I can see the design where using of the Enum type field for the attribute can be pretty alright. [CommonAttribute(MyEnum.MyTypeId)] where CommonAttribute is located in the common library and developer uses her library enum member.
Wrapping it up for a moment here, enough blah for the CustomAttributeData, hopefully enough material for Mark to review the applicability for Spring.NET 1.1.