Thanks Krzystof and Fabian On Mon, Jan 12, 2009 at 6:28 AM, Fabian Schmied <[email protected]>wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
