Is it me or is there a serious problem with Unity.Interception?

Jun 22, 2009 at 12:12 PM

I'm hoping someone can set me straight here but I think there is a serious problem in the Unity interception extension.

In order to build the interception pipeline this extension creates a dictionary of methods that have been tagged with an ICallHandler.

This dictionary is keyed on MetaDataToken of the method which is only unique within the assembly in question.

This means that your ICallHandlers can be firing off all over the place as a result of calls to methods in other assemblies which have the same MetaDataToken.

*Surely* I am missing something here aren't I?

Oct 21, 2009 at 11:04 PM

You are absolutely right!!

I just discovered this after an entire day of pulling my hair out - for some odd reason my Policy Injection block was firing interception on System.GetType for no apparent reason - and oddly, if I removed two methods from the matching rule, it stopped! It turns out that those methods just happen to have the same MetadataToken's as System.Object.GetType()!

How do we go about getting this fixed? I really don't want to work on my own custom compiled version of EAB.

Andrew

Oct 21, 2009 at 11:40 PM

We have confirmed this as a bug, and the fix will be in our next source code drop.

 

Oct 21, 2009 at 11:41 PM

When will that next source code drop be?

And – do you know of any way to:

a) Get .NET to generate a different token

b) Change an existing metadatatoken?

c) Any other workaround?

Thanks,

andrew

From: ctavares [mailto:notifications@codeplex.com]
Sent: Wednesday, October 21, 2009 7:41 PM
To: Andrew Ryan
Subject: Re: Is it me or is there a serious problem with Unity.Interception? [unity:60260]

From: ctavares

We have confirmed this as a bug, and the fix will be in our next source code drop.

Read the full discussion online.

To add a post to this discussion, reply to this email (unity@discussions.codeplex.com)

To start a new discussion for this project, email unity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Oct 28, 2009 at 6:49 PM

Should have a new drop next Monday (11/2). The recent p&p summit conference kind of screwed up our progress last iteration.

Oct 29, 2009 at 9:08 AM

It will be great to get a fix for this. Are you allowed to say how you have fixed this Chris?

Oct 29, 2009 at 6:03 PM

It's not something that can be easily explained in a forum post, but I'll try.

The whole reason we used the metadata token was that it was a simple integer that didn't change, and therefore was easily accessed from our codegen stuff. Using MethodInfo, for example, would have required us to generated calls to the reflection API, which was more complex than we really wanted to get. However, it turned out not to work well as everyone has figured out.

So instead, when we reflect over the target class to build the proxy, instead we maintain a simple integer counter, one per method being intercepted. Then we can simply use that as our index. It's a little more complex than that in the implementation, but that's the basic jist. See the source for more details.

 

Oct 29, 2009 at 6:27 PM

It’s my understanding that the metadata token is unique within a given module – why not just key it off the assembly/module full name plus the metadata token?

From: ctavares [mailto:notifications@codeplex.com]
Sent: Thursday, October 29, 2009 2:03 PM
To: Andrew Ryan
Subject: Re: Is it me or is there a serious problem with Unity.Interception? [unity:60260]

From: ctavares

It's not something that can be easily explained in a forum post, but I'll try.

The whole reason we used the metadata token was that it was a simple integer that didn't change, and therefore was easily accessed from our codegen stuff. Using MethodInfo, for example, would have required us to generated calls to the reflection API, which was more complex than we really wanted to get. However, it turned out not to work well as everyone has figured out.

So instead, when we reflect over the target class to build the proxy, instead we maintain a simple integer counter, one per method being intercepted. Then we can simply use that as our index. It's a little more complex than that in the implementation, but that's the basic jist. See the source for more details.

Read the full discussion online.

To add a post to this discussion, reply to this email (unity@discussions.codeplex.com)

To start a new discussion for this project, email unity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Oct 29, 2009 at 9:31 PM

We're dealing with IL generated at runtime here - having simple integers where possible makes this code generation a lot easier. Also, using a simple integer means that lookups (for things like call handlers) become simple array accesses, which are much faster than hash table lookups. We already get complaints about the interception overhead, so we don't want to make it even worse.

Oct 29, 2009 at 11:37 PM
Gotcha

Sent from my iPhone

On Oct 29, 2009, at 5:32 PM, "ctavares" <notifications@codeplex.com> wrote:

From: ctavares

We're dealing with IL generated at runtime here - having simple integers where possible makes this code generation a lot easier. Also, using a simple integer means that lookups (for things like call handlers) become simple array accesses, which are much faster than hash table lookups. We already get complaints about the interception overhead, so we don't want to make it even worse.