It is possible to add proxy capabilities to an already generated and not empty object using Castle Dynamic Proxy?
I've tried this:
Dog _myDog=new Dog();
_myDog.Name="Fuffy";
var _proxyDog = generator.CreateClassProxyWithTarget<Dog>(_myDog, ProxyGenerationOptions.Default, new DogInterceptor());
_proxyDog results as a new object.
Now this is only an example, in real world application my object has 30+ properties and I want to know if I can avoid to copy those props one by one!
Yes it is. The only problem: ProxyGenerator needs to instantiate an object of that type anyway. This code is actually working correctly in my project:
public static class MongoExtensions
{
static readonly ProxyGenerator pg = new ProxyGenerator();
public static MongoCollection GetRetryCollection(this MongoDatabase db, string collectionName, int retryCount = 5, int pauseBetweenRetries = 2000)
{
var coll = db.GetCollection(collectionName);
return (MongoCollection)pg.CreateClassProxyWithTarget(typeof(MongoCollection), coll, new object[] { db, collectionName, coll.Settings }, new RetryingInterceptor { RetryCount = retryCount, PauseBetweenCalls = pauseBetweenRetries });
}
}
Paramerts of CreateClassProxyWithTarget are:
I can't really explain, why it need constructor parameters for the object, but this code work correctly for me.
I had the same issue so using vlad's suggestion this worked for me:
var _proxyDog = generator.CreateClassProxyWithTarget(_myDog.GetType(), _myDog, new DogInterceptor());
From what I can see a new wrapper (proxy) is created that simulates the real class and the wrapped class (target) is my original object.
additional: nope i checked again and the 'target type' is correct but the proxy isn't reflecting the values set in it. i'd consider this a bug; and a big one.
from the first image you can see the original class with all the imports satisfied.
image here... sadly i can't post the images for you to look at as it appears i need a reputation of '10'; apparently. how silly is that? sorry.
as you can see the properties on the proxy are both null and incomplete but the original class under '_target' is still intact. probing the proxies properties results in aberrant behaviour and you shouldn't need to inspect the target as you would be obviating the purpose of the decorator.
another image here...
i would expect either all the properties to be there mimicking in full the underlying class; or none of them and the mapping to be dynamic. as it stands it isn't working for me either, as the one property i actually want to gain access to is being exposed with an incorrect value.
Colin.
The approach in the original question is fine. However, you need to ensure that all of the properties in the class being wrapped are marked as virtual.
