Fixed on the trunk. Thanks, Krzystof, for investigating the problem. I fixed it by making AddFieldToCacheMethodTokenAndStatementsToInitialize perform the check for generic methods.
Fabian On Mon, Jan 12, 2009 at 12:54 PM, Fabian Schmied <[email protected]> wrote: > This is definitely a bug in ImplementBlankInterface, which for some > reason doesn't use the "CacheMethodTokens" method. The current > workaround for generic methods in "CacheMethodTokens" is to not cache > them (your solution number 2), so ImplementBlankInterface shouldn't > cache them either. > > I'll fix this. > > Fabian > > PS: Yes, it's inefficient, and maybe we should talk about fixing this, > but I'll make it consistent first, we can optimize later. > > On Mon, Jan 12, 2009 at 12:03 PM, Krzysztof Kozmic <[email protected]> wrote: >> >> Craig, >> >> The problem is in .cctor, when trying to get MethodInfo of the generic >> method with ldtoken. >> Unfortunately the API for open generic methods seems to be broken, and >> I couldn't find a clean way of getting Methodinfo for such a method. >> There are two solutions for that. >> >> 1. Try to cache the method in some other way, than by ldtoken >> The best I came up with so far is this: >> MemberInfo[] methods = type.GetMember( "MethodName", >> MemberTypes.Method, >> BindingFlags.Instance >> | >> BindingFlags.Public >> | >> >> BindingFlags.NonPublic ); >> //and now filter out the method we need, and assign it to >> the cache field >> >> We get the MethodInfos for not only the generic method, but for all >> methods with the same name, and we need to filter it out. >> >> 2. Alternatively, easler thing to do, is to not cache the generic >> method. >> >> This requires changing ImplementBlankInterface method of >> BaseProxyGenerator, so that in foreach loop when current method is open >> generic method >> it won't get cached. >> >> I don't have access to the repository to create the patch, but it's >> straightforward. >> With that little change your test, as well as all other pass. >> >> This however means worse performance. Probably someone should create a >> solution that does a lot operations with these generic methods, and >> profile it to see how well it behaves. >> If the performance hit is significant, we might try the 1st approach >> and see if it improves things. >> >> Krzysztof >> >> >>>>> [email protected] 2009-01-10 19:04:18 >>> >> Krzysztof, Fabian >> >> It looks like the problem is when creating interfaces proxies while >> specifying additional interfaces that include generic methods. I >> created a >> unit test to demonstrate the problem. It is checked in on DP2 trunk >> with >> the Ignore attribute. >> >> http://svn.castleproject.org:8080/svn/castle/trunk/Tools/Castle.DynamicProxy2/Castle.DynamicProxy.Tests/GenericMethodsProxyTestCase.cs >> >> >> I am currently trying to resolve this defect in the WCF integration >> facility >> http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-80 >> >> >> Thanks for your help, >> Craig >> >> I also have defects when creating class proxies that call self generic >> methods. This is happening when using MS MVC Controllers that have >> generic >> methods, but that is something totally different and I'll create more >> broken >> tests for that too. >> >> >> On Sat, Jan 10, 2009 at 2:33 AM, Fabian Schmied >> <[email protected]>wrote: >> >>> >>> > Does anyone have any idea the extent of change to DP2 to support >> proxying >>> > generic methods? Got a few defects from that. >>> >>> This is actually implemented. There are, however, a few bugs in the >>> .NET 2.0 CLR (before SP2, at least), which make this really hard to >>> get right. There are a few workarounds in there (eg. tokens of >> generic >>> methods aren't cached, there is this ominous >>> IInvocation.GetConcreteMethod API, etx), but in principle, it should >>> work. >>> >>> What exactly are the defects you have? >>> >>> Fabian >>> >>> > >>> >> >> >> >> CONFIDENTIALITY NOTICE >> This message is intended exclusively for the individual or entity to which >> it is addressed. This communication may contain information that is >> proprietary, privileged, confidential or otherwise legally exempt from >> disclosure. If you are not the named addressee, you are not authorized to >> read, print, retain, copy or disseminate this message or any part of it. If >> you have received this message in error, please delete all copies of this >> message and notify the sender immediately by return mail or fax ATSI >> S.A.(+4812) 285 36 04. >> Any email attachment may contain software viruses which could damage your >> own computer system. Whilst reasonable precaution has been taken to minimise >> this risk, we cannot accept liability for any damage which you sustain as a >> result of software viruses. You should therefore carry out your own virus >> checks before opening any attachments. >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
