What are the differences between LinFu.DynamicProxy and Castle.DynamicProxy?

Dale Ragan picture Dale Ragan · Sep 10, 2009 · Viewed 9.4k times · Source

I am looking at adding logic to a library I am working on that would require the need for a Dynamic Proxy. I would like to get some advice from user's who have used these two library's in a production environment. Does one out perform the other, were there any shortcoming's which made you have to switch to the other, etc. Basically tell me your experiences with the library's. The answers will help me decide which one to use.

-- Edit --


I forgot to mention that the library I am developing will support Mono, therefore any knowledge you can share about the two libraries and their support for Mono would be great also.

Answer

Krzysztof Kozmic picture Krzysztof Kozmic · Sep 10, 2009

I am a committer to Castle, contributing to Dynamic Proxy, so I may be biased, but I generally think Castle's Dynamic proxy is far better solution. I'm talking here about LinFu DynamicProxy v1.0 because that's what I'm familiar with. LinFu.Proxy 2 is based on Mono.Cecil and is rewritten from the scratch.

  • Castle covers wider range of scenarios.
  • Castle has (a lot) larger user base, and is proven in many OSS and commercial applications
  • Castle is actually performing better (link)
  • Castle has cleaner, easier to use API for example invoking target method to Castle DynamicProxy looks like this:

invocation.Proceed();

for LinFu, it looks like this (actual method/property name may vary as I'm writing it from memory)

//invocation.TargetMethod is MethodInfo, so you're using reflection
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters);
  • Castle has an active user group where you can quickly get answers to your questions.

The performance issue, mentioned by the other answer are not DynamicProxy issue, but are result of bug in Microsoft's implementation of BCL (on Mono there is no such issue BTW). This only manifests itself when you have many (over 200+) proxy types in single ModuleScope.

Solution is trivial - don't generate that many proxy types (usually you won't have to) or use many ModuleScopes/ProxyGenerators (for example Rhino.Mocks uses this approach)

Personally I do not develop on Mono, so I don't have firsthand experience, however there are libraries using Castle DP on Mono, and we didn't get any compliaints so i guess it works just fine.

Since my benchmark few months ago, there has been no new release of Castle DP (new version is targeted at the end of the year). LiFu has a 2.0 version, but I'm not sure if it is trunk only, or released. I don't know about Spring or Unity.