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 -~----------~----~----~----~------~----~------~--~---
