I think it would work if the assembly was not marked as "security transparent", but I didn't try it.
On Wed, Nov 28, 2012 at 12:23 PM, Stephen Bohlen <[email protected]> wrote: > Other than in partial-trust scenarios --? > > -Steve B. > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > > On Wed, Nov 28, 2012 at 2:14 PM, Patrick Earl <[email protected]> wrote: > >> Looks like it causes security errors. :( >> >> >> On Tue, Nov 27, 2012 at 6:28 PM, Alexander I. Zaytsev >> <[email protected]>wrote: >> >>> Hi all >>> >>> It may be a very big breaking change! >>> >>> Best Regards, Alex >>> >>> >>> 2012/11/28 Patrick Earl <[email protected]> >>> >>>> This sounds like a better alternative to me... what think others? >>>> >>>> >>>> On Tue, Nov 27, 2012 at 7:16 AM, Fabian Schmied < >>>> [email protected]> wrote: >>>> >>>>> Just a comment: you could use >>>>> System.Runtime.Serialization.FormatterServices.GetUninitializedObject >>>>> to create an instantiate a type (verifiably) without calling its >>>>> constructor. >>>>> >>>>> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >>>>> >>>>>> Hi Patrick, >>>>>> >>>>>> I made the change to make the generated assemblies pass PeVerify: >>>>>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>>>>> >>>>>> >>>>>> I’d agree with the argument that the (default) constructor that NH >>>>>> uses shouldn’t be doing anything unusual, but obviously we can’t enforce >>>>>> that. >>>>>> >>>>>> If there is now a situation that we can get a stack overflow using >>>>>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>>>>> I’m not so sure about casting the object directly to an IProxy and >>>>>> relying >>>>>> on the underlying implementation of Interceptors though – it’s not clear >>>>>> to >>>>>> me how someone would decide what is acceptable/reasonable external >>>>>> behaviour for that. In addition, I think the original Castle proxy would >>>>>> have behaved like this too? >>>>>> >>>>>> Also, if you mark the default constructor as private, then the proxy >>>>>> has no choice but to bypass it (and behave the way it did prior to that >>>>>> fix). Does that help? >>>>>> >>>>>> Cheers, >>>>>> Richard >>>>>> >>>>>> >>>>>> *From:* Patrick Earl >>>>>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>>>>> *To:* nhibernate-development >>>>>> *Subject:* [nhibernate-development] Calling base constructor in >>>>>> proxies >>>>>> >>>>>> I noticed (due to a stack overflow) that proxies now call their base >>>>>> constructor. That behaviour is a little scary to me since proxies are >>>>>> not >>>>>> real objects and the real objects might have interaction with the world >>>>>> that isn't supposed to happen with proxy objects. I suppose the argument >>>>>> could be made that the constructor should not be doing anything remotely >>>>>> interesting, but on the other hand, constructors should produce objects >>>>>> that don't need additional initialization. >>>>>> >>>>>> The stack overflow itself was from an interesting combination of >>>>>> changes in the latest NH. First, it calls the base constructor. Second, >>>>>> the dynamic proxy was changed to call "base.Method()" if the interceptor >>>>>> was not set. Since there is no "base.Method()" I assume that it ends up >>>>>> calling the same method again, resulting in the mysterious stack >>>>>> overflow. >>>>>> >>>>>> Basically my code was doing something like >>>>>> NHibernateUtil.IsInitialized(**a) and when it went to get the >>>>>> HibernateLazyInitializer property it overflowed the stack. I ended up >>>>>> fixing this by changing my condition as follows: >>>>>> >>>>>> a is IProxy && (a as IProxy).Interceptor != null && >>>>>> NHibernateUtil.IsInitialized(**a) >>>>>> >>>>>> Perhaps the code to check for uninitialized proxies inside of >>>>>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>>>>> disable calling the base constructor when not needed for a medium trust >>>>>> environment. Thoughts on this interesting situation? Has anyone else >>>>>> run >>>>>> into problems related to calling the base constructor? >>>>>> >>>>>> Patrick Earl >>>>>> >>>>> >>>>> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >>>>>> >>>>>> Hi Patrick, >>>>>> >>>>>> I made the change to make the generated assemblies pass PeVerify: >>>>>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>>>>> >>>>>> I’d agree with the argument that the (default) constructor that NH >>>>>> uses shouldn’t be doing anything unusual, but obviously we can’t enforce >>>>>> that. >>>>>> >>>>>> If there is now a situation that we can get a stack overflow using >>>>>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>>>>> I’m not so sure about casting the object directly to an IProxy and >>>>>> relying >>>>>> on the underlying implementation of Interceptors though – it’s not clear >>>>>> to >>>>>> me how someone would decide what is acceptable/reasonable external >>>>>> behaviour for that. In addition, I think the original Castle proxy would >>>>>> have behaved like this too? >>>>>> >>>>>> Also, if you mark the default constructor as private, then the proxy >>>>>> has no choice but to bypass it (and behave the way it did prior to that >>>>>> fix). Does that help? >>>>>> >>>>>> Cheers, >>>>>> Richard >>>>>> >>>>>> >>>>>> *From:* Patrick Earl >>>>>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>>>>> *To:* nhibernate-development >>>>>> *Subject:* [nhibernate-development] Calling base constructor in >>>>>> proxies >>>>>> >>>>>> I noticed (due to a stack overflow) that proxies now call their base >>>>>> constructor. That behaviour is a little scary to me since proxies are >>>>>> not >>>>>> real objects and the real objects might have interaction with the world >>>>>> that isn't supposed to happen with proxy objects. I suppose the argument >>>>>> could be made that the constructor should not be doing anything remotely >>>>>> interesting, but on the other hand, constructors should produce objects >>>>>> that don't need additional initialization. >>>>>> >>>>>> The stack overflow itself was from an interesting combination of >>>>>> changes in the latest NH. First, it calls the base constructor. Second, >>>>>> the dynamic proxy was changed to call "base.Method()" if the interceptor >>>>>> was not set. Since there is no "base.Method()" I assume that it ends up >>>>>> calling the same method again, resulting in the mysterious stack >>>>>> overflow. >>>>>> >>>>>> Basically my code was doing something like >>>>>> NHibernateUtil.IsInitialized(**a) and when it went to get the >>>>>> HibernateLazyInitializer property it overflowed the stack. I ended up >>>>>> fixing this by changing my condition as follows: >>>>>> >>>>>> a is IProxy && (a as IProxy).Interceptor != null && >>>>>> NHibernateUtil.IsInitialized(**a) >>>>>> >>>>>> Perhaps the code to check for uninitialized proxies inside of >>>>>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>>>>> disable calling the base constructor when not needed for a medium trust >>>>>> environment. Thoughts on this interesting situation? Has anyone else >>>>>> run >>>>>> into problems related to calling the base constructor? >>>>>> >>>>>> Patrick Earl >>>>>> >>>>> >>>> >>> >> >
