Can managed properties be internal?

Can managed properties be internal?

Old forum URL: forums.lhotka.net/forums/t/5207.aspx


sixeyes posted on Thursday, August 07, 2008

I changed one of the properties in a BusinessBase derived class from "public" to "internal". The class itself is already marked "internal".

With the property marked as "public" ValidationRules.CheckRules() worked, but when the property was marked "internal" ValidationRules.CheckRules() threw an exception.

I traced this problem as far as CallByName (Utilities.cs)

        case CallType.Get:
          {
            PropertyInfo p = target.GetType().GetProperty(methodName);
            return p.GetValue(target, args);
          }

The retrieved value for p is null.

I'm using the released v3.5.1 of CSLA.

Is using "internal" for managed property invalid or is it a bug?

Iain

rsbaker0 replied on Thursday, August 07, 2008

In CSLA 3.0 I used internal property "setters", while the property itself was marked public. This worked fine in CSLA 3.0, so I hope this isn't broken in 3.5.

I made extensive use of "internal" setters. The idea is that we have a multitude of fields that no user should be directly changing, but we want the user to be able to update those same fields if they are performing an authorized transaction.  The transaction BO is in a friend assembly, so it can call the setters, but they appear to be read-only anytime they are bound to the UI.

sixeyes replied on Friday, August 22, 2008

I don't think you'll have a problem. My problem is related to using the new managed fields in v3.5.

If you were to migrate your code to v3.5 you wouldn't be using managed fields so I don't believe you'll be affected.

Iain

ajj3085 replied on Friday, August 22, 2008

I don't have an answer to your question... but I'll throw this out there.

If your class is already internal, it doesn't seem like it matters if a property on the class is public or internal. 

That said, the method getting the PropertyInfo is only searching public properties.  You could change the call to include private / internal ones as well.  I thought at one point Csla was changed to allow internal / private members to be included, but that code looks newer to me.  I could be 100% wrong though.

sixeyes replied on Friday, August 22, 2008

I agree it doesn't matter whether the property is internal / public but I was a bit surprised when my code crashed. It took me a while before I realised that the change from public to internal had caused the problem.

Do you know if it's a requirement for managed properties to be public and not internal?

Iain

rsbaker0 replied on Friday, August 22, 2008

I wonder if it would work to declare CSLA as a "friend" assembly using the InternalsVisibleTo attribute? 

ajj3085 replied on Friday, August 22, 2008

Can't comment there, although checking versions 2.1.4 and 3.0.4 of the Utilities.cs file, that actually hasn't changed at all.  So it doesn't seem like you could ever do this out of the box, but maybe it could be an enhancement.

rsbaker0 replied on Friday, August 22, 2008

ajj3085:
Can't comment there, although checking versions 2.1.4 and 3.0.4 of the Utilities.cs file, that actually hasn't changed at all.  So it doesn't seem like you could ever do this out of the box, but maybe it could be an enhancement.

Yes, but read-only properties are supported, right? It works fine in those versions to have an internal setter while the getter is public (thus making the property appear to be read-only outside of the assembly), although I don't know if this would satisfy the OP's requirements or work with managed properties in CSLA 3.5+.

Interestingly (and fortunately), CSLA 3.0 doesn't seem to care about the read-onlyness in the validation rules. They fire just fine when you call the internal setter... :)

 

Copyright (c) Marimer LLC