Actually, compiler as a service is supposed to be able to allow this. But, to be fair to Andres, you literally *can't* do this. You would have to re-write the CLR in order to allow this.
On Tue, Sep 21, 2010 at 11:05 PM, Wenig, Stefan <[email protected]>wrote: > 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 > > >
