Generic interception/dynamic proxying library should not depend on Unity

Jan 19, 2010 at 7:01 PM

I'm planning to use the generic interception mechanism, but none of the Unity container stuff.

Looks like because of the way dependencies are laid out currently, the situation is mostly the same as with Castle, where DynamicProxy has a (seemingly unnecessary) dependency on Castle Core. This makes a lot of people nervous when your company has already made a choice of DI container. Why do you need to bring in another one??

It would be VERY good if it was decoupled in Unity, to avoid having the same problem.

Jan 19, 2010 at 7:05 PM



 I agree with kzu, there should be no need to have a dependency "up" to the container.

  Lars Wilhelmsen - Connected Systems MVP

Jan 19, 2010 at 11:38 PM

I vote for that as well.


Jan 20, 2010 at 5:20 AM

Well, it's not as bad as all that. The only piece that's coupled to the container is the Policy Injection stuff. You can use the rest of interception without deploying the Unity DLL at all.

The issue is that we needed a container in order to resolve the matching rules and call handlers; those have to be created for each method that matches. We discussed using IServiceLocator instead, but then you need to deploy another DLL to use PolicyInjection, which seemed like a worse tradeoff.

What parts of the injection stuff did you want to use? Will this be sufficient for your needs?



Jan 20, 2010 at 1:52 PM

I don't think this is the case, Chris.

To do the following:


return Intercept.ThroughProxy(
new InterfaceInterceptor(),
new[] { new PropertyContainerBehavior() },
new[] { typeof(TInterface) })
as TInterface;

return Intercept.ThroughProxy(


new InterfaceInterceptor(),

new[] { new PropertyContainerBehavior() },

new[] { typeof(TInterface) })

as TInterface;

Unity.dll is required, and I'm guessing the *Configuration* stuff for both unity and interception too. So it's 4 dlls for just dynamic proxy behavior.



Jan 21, 2010 at 6:39 AM

Really? I'll have to check it out. It wasn't our intention to be coupled here, let me see what's going on. May just be a bug.

If I was able to limit the need for Unity to just policy injection, would that answer your concerns? PIAB really needs a container of some sort, and I'd hate to introduce yet another abstraction just for it.


Jan 21, 2010 at 5:50 PM

Still don't understand why PIAB needs to exist inside the interception/dynamic proxy stuff. 

Can't it just be another assembly that bridges Unity/PIAB and Interception?

Castle seems to have liked the refactoring idea towards a similar structure:


Would love to see the same for Unity interception :)

Jan 21, 2010 at 11:20 PM

It could be, but:

1) The pieces of PIAB that are in that assembly are the implementation of an Interception behavior - it's just a use of the mechanisms delivered by the interception stuff, not the call handlers themselves,

2) most of the users of Unity interception will be using PIAB,

3) We're making a conscious effort to reduce the total number of assemblies in Entlib 5.0/Unity 2.0 to simplify deployment.

Having them in the same assembly doesn't cost much, and helps the majority of our users by saving them an extra assembly to deploy and an extra assembly load. As long as the dependencies are structured appropriately, I'd like to keep them together for the above reasons.


Jan 21, 2010 at 11:35 PM

By the way, I found the source of the dependency - it's the Guard class used to check for things like null arguments. We can easily replicate it and remove the dependency.