Update II: I couldn’t wait. I’ve installed the last Mono daily binary tarball and all the unit tests are passing now!. It works perfectly!
Update:The Mono implementation of GetMethodFromHandle for generics is already in the svn, so rather than write a conditional code I’ll wait for the new binary release.
In the previous post about the BindableWrapper I was using DynamicProxy but I’ve realized that it doesn’t work with generics. That is, if the class to which you are creating the proxy has generic methods or properties (public virtual List<T> MyList). Actually, it works on Mono but it doesn’t on .Net, because the GetMethodFromHandle method has a different signature for generics and I didn’t see that until I tested it on .Net. I guess it shouldn’t work in Mono neither but it does.
The BindableWrapper hierarchy classes have been migrated to DynamicProxy2 and they are working fine now on .Net. However on Mono I’m getting a NotImplementedException with DP2 🙂 so I’m wondering if should I use conditional build to have both versions of DynamicProxy in order to have my classes working everywhere.These are the steps I made to migrate:
- Change the reference to Castle.DynamicProxy.dll, for Castle.DynamicProxy2.dll
- Add a reference to Castle.Core.dll
- Add this: using Castle.Core.Interceptor
- As the new parameters to CreateClassProxy, pass in IInterceptor[] and object[] arrays to prevent ambiguity problems
- Change the Intercept method signature in your implementation of IInterceptor:
public override object Intercept(IInvocation invocation, params object[] args) – old
public void Intercept(IInvocation invocation) – new - Change the way to proceed on an interception:
return base.Intercept(invocation, args); – old
invocation.Proceed(); – new - I was also inheriting from StandarInterceptor and now I’m just implementing the IInterceptor
It is straightforward to migrate but I’d advise to get the last daily binary build of the CastleProject in order to user DynamicProxy2. I don’t like very much the release policy of the CastleProject because the last “stable version” was released the last year and the svn contains much more functionality and bugfixes. I rather would release versions more often using minor version numbers (i.e, 0.9.1…), making branches in the svn repository. So in my opinion the head of the svn is not unstable but the right decision if you choose Castle.