I posted a related question on SO:
http://stackoverflow.com/questions/6114869/why-does-nhibernate-require-protected-internal-visibility-on-auto-properties.
Is there something I am missing?  Why is the "internal" attribute
called for?

Thank you!
-Michael

On May 5, 6:35 am, Fabio Maulo <[email protected]> wrote:
> btw the note about the breaking change is in the releasenotes.txt since the
> beginning. ;)
>
> --
> Fabio Maulo
>
> El 04/05/2011, a las 17:18, Stephen Bohlen <[email protected]> escribió:
>
> You'll have to talk to Anders for that :)
>
> Steve Bohlen
> [email protected]http://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen
>
>
>
> On Wed, May 4, 2011 at 4:16 PM, Fabio Maulo <[email protected]> wrote:
> > well... give me something to override private members on the fly (without
> > use IL rewrite) and I'll remove that restriction ;)
>
> > On Wed, May 4, 2011 at 5:01 PM, Stephen Bohlen <[email protected]> wrote:
>
> >> lol -- there is no doubt in my mind at all that our restrictions are
> >> almost guaranteed to be the least invasive of all of the options, but I'd
> >> *still* like to ensure that we try to measure ourselves by something more
> >> rigorous than "we're not as bad as MS" :D
>
> >> Steve Bohlen
> >> [email protected]
> >>http://blog.unhandled-exceptions.com
> >>http://twitter.com/sbohlen
>
> >> On Wed, May 4, 2011 at 3:56 PM, Diego Mijelshon 
> >> <[email protected]>wrote:
>
> >>> Steve, do you know what the default behavior for EF "code-first" is when
> >>> a many-to-one property is not virtual?
> >>> It loads as null and lazy load doesn't work.
> >>> I'll take NH's fail-early, simple restrictions any time.
>
> >>>     Diego
>
> >>> On Wed, May 4, 2011 at 11:12, Stephen Bohlen <[email protected]> wrote:
>
> >>>> That feels like (yet another) constraint on my object modeling dictated
> >>>> by my persistence choice (tail wags dog).  There are already several of
> >>>> these w/NH adoption; I'd prefer not to introduce yet another one if we 
> >>>> can
> >>>> avoid it.
>
> >>>> Steve Bohlen
> >>>> [email protected]
> >>>>http://blog.unhandled-exceptions.com
> >>>>http://twitter.com/sbohlen
>
> >>>> On Wed, May 4, 2011 at 10:08 AM, Ramon Smits 
> >>>> <[email protected]>wrote:
>
> >>>>> Can't you just convert private to protected?
>
> >>>>> On Wed, May 4, 2011 at 4:05 PM, cremor <[email protected]> wrote:
>
> >>>>>> Oh, lazy properties, right. I didn't think about that because I've
> >>>>>> never used them.
>
> >>>>>> Is there a way to just disable that lazy property check? Because I
> >>>>>> don't want to disable the whole proxy checking for sure.
> >>>>>> If not, would it be possible to change that code so it does the check
> >>>>>> for private accessors only if the property is really mapped as lazy
> >>>>>> property?
>
> >>>>>> On May 4, 3:54 pm, Fabio Maulo <[email protected]> wrote:
> >>>>>> > yes if you don't want use lazy-properties.
> >>>>>> > You can disable the validator but then you have to know what will
> >>>>>> happen if
> >>>>>> > you use lazy-properties.
>
> >>>>>> > On Wed, May 4, 2011 at 10:39 AM, cremor <[email protected]> wrote:
> >>>>>> > > I just tried a build of the current trunk (coming from
> >>>>>> 3.2.0.Alpha2)
> >>>>>> > > and was quite surprised that nothing worked any more because
> >>>>>> > > NHibernate complained about many of my entities not being
> >>>>>> proxyable.
>
> >>>>>> > > Example property:
> >>>>>> > > public virtual SomeEntity SomeEntity { get; private set; }
>
> >>>>>> > > Seems like in r5718 the DynProxyTypeValidator was changed to also
> >>>>>> > > check non-public property accessors (line 57 from
> >>>>>> > > "property.GetAccessors(false)" to "property.GetAccessors(true)").
> >>>>>> I
> >>>>>> > > see that it's needed to check protected/protected internal
> >>>>>> accessors
> >>>>>> > > (so the previous code wasn't checking everything), but shouldn't
> >>>>>> > > private accessors be allowed?
>
> >>>>>> > --
> >>>>>> > Fabio Maulo
>
> >>>>> --
> >>>>> Ramon
>
> > --
> > Fabio Maulo- Hide quoted text -
>
> - Show quoted text -

Reply via email to