you can intercept private member access using in-process remoting. it just requires some native code ;-) (at least it worked in .net 1.0, I'd have to find the code in some old VSS(!) repository...)
jokes aside, I once talked to anders hejlsberg at the lang.net symposium. i proposed to make it possible to override non-virtual members (private is not the problem in the CLR, these are orthogonal concepts there) for subclass proxies that are generated at run time. the reasoning being that, like in reflection, you don't introduce a dependency if you discover the target at run time, same thing as in reflection (e.g. serializing all private fields). also, unlike IL weaving or a boo-like C#5, this could be used by existing frameworks like castle. anders' answer was basically "interesting. so you want to be able to change the behaviour of anything?" - and off he was. long story short: unlikely ;-) ________________________________________ From: [email protected] [[email protected]] on behalf of Frans Bouma [[email protected]] Sent: Tuesday, September 21, 2010 18:36 To: [email protected] Subject: RE: [nhibernate-development] Re: Proxy with lazy fields does not implement INHibernateProxy > That is the cost to pay for a very cool feature in .NET (so far). > Before see the ISet, inside the framework, we had to wait the needs of EF4 > (around 9 years). > To have Proxy support inside the .NET perhaps we have to wait others one or > two years. > To have static-proxy directly supported by the compiler (to efficiently > intercept the access to a private field) perhaps in others 4 or 5 years... > if we all don't create enough noise to speed up the change a little bit. I fear that will never happen. What should happen is IL weaving inside the CLR. Unfortunately, powerful forces inside MS either hate AOP like stuff to death or think it can be outsourced to the DLR (is that still alive?) But never is a big word, for what I know the CLR team moves incredibly slow so I wouldn't hold my breath FB > > > On Tue, Sep 21, 2010 at 1:02 PM, Ayende Rahien <[email protected]> wrote: > > > That is pretty much the point. > There isn't an unproxy stage for an entity with lazy fields. > > To give you an example: User.Image is lazy > > var user = session.Load<User>(1); // user is a proxy > NHibernateUtil.Initialize(user); // select id,name from user where id > = 1 > var unproxiedUser = ((INHibernateProxy)user).GetImplementation(); > > unproxiedUser is also proxy, because it need to intercept the > get_Image call > > On Tue, Sep 21, 2010 at 5:43 PM, Allan Ritchie > <[email protected]> wrote: > > > The problem is more widespread then just the LINQ provider. > You can't > unproxy the entity even at later stages outside of the LINQ > provider. > > > On Sep 21, 9:18 am, pvginkel <[email protected]> wrote: > > I would be very surprised if this really would be a bug, > because this > > would make the Linq provider unusable when enabling lazy > properties. > > Feedback is very welcome. > > > > On Sep 21, 2:36 pm, Allan Ritchie <[email protected]> > wrote: > > > > > I filed this as a bug. It was claimed not to be a bug > which is fine, > > > but contrib packages like nhibernate validator seem to > fail against > > > lazy property proxies because of this exact issue. Can > anyone say > > > what the workaround is for this situation? > > > > > On Sep 20, 7:33 am, pvginkel <[email protected]> wrote: > > > > > > I have a Linq query which takes an entity as parameter. > This entity > > > > itself is a proxy loaded with another Linq query and has > lazy > > > > properties. In "ReflectHelper.cs(267): Assembly assembly > = > > > > Assembly.Load(name.Assembly);" I get an > FileNotFoundException because > > > > it tries to load the assembly of the proxy class. It > looks like the > > > > problem is that > NHibernateProxyHelper.GetClassWithoutInitializingProxy > > > > can't determine the type of the entity because the proxy > does not > > > > implement INHibernateProxy, so it returns the type of > the proxy. > > > > > > Is this something I can solve in my configuration, or is > something > > > > else going on here? > > > > > > I am using a nightly build of the NH3 trunk. > > > > > > > -- > Fabio Maulo >
