Thanks  a bunch for tracking this one down.  Since I think it is a fairly
uncommon usage, I think we can live with the performance hit until we can
find a better solution or the API gets fixed.

cheers,
  craig

On Mon, Jan 12, 2009 at 5:03 AM, 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to