CSLA 3.0 issue (braking change?)

stefan posted on Tuesday, April 17, 2007

Hi,

I just downloaded the csla 3.0 TEST version, because I want to take advantage of a few enhancements
regarding validation (-> PropertyFriendlyName). I deleted all things from the csla project that related
to .NET 3.0, prior to building csla, as I am not switching yet.
Then I updated all references to csla.dll in my project. The project still built successfully.

The (runtime) issue:
I have a property returning an enum type, joined to a validation rule from the common set:
StringMaxLength, which worked properly with csla 2.1.3 (well, at least I got no exception ;-) ).
This doesn't work anymore. Rock states this in his remarks coming with StringMaxLength:

    /// <remarks>
    /// This implementation uses late binding, and will only work
    /// against string property values.
    /// </remarks>

The code inside StringMaxLength causing the exception is:

      string value = (string)Utilities.CallByName(
        target, e.PropertyName, CallType.Get);

Prior to this, I used the vb Version of clsa 2.1.3.
The equivalent line of code there reads:

      Dim value As String = _
        CStr(CallByName(target, e.PropertyName, CallType.Get))

I wonder why I got no exceptions in the past?
Any enlightenment?

Stefan

JoeFallon1 replied on Tuesday, April 17, 2007

I have not looked at the Utilities.CallByName method - but it looks like it is something Rocky wrote rather than the one in the .Net framework.

Try changing to to old style and see if it works for you.

I re-wrote the common rules in my own Module so that I could do these kinds of things without re-compililng the CSLA.dll. Plus I added my own new rules, etc.

Joe

 

RockfordLhotka replied on Tuesday, April 17, 2007

You may have stumbled across a slight difference between VB and C#.

In VB I use the built-in CallByName functionality provided by Microsoft - no sense writing my own.

In C# I had to write my own, but I only wrote a small subset. The VB runtime does a lot of really cool stuff, and I don't have the time or inclination to replicate all of it to C#

My guess is that the VB CallByName method does some pretty cool type coercion, and that's great. But my C# code just uses straight reflection and obviously doesn't handle that case.

Consider the extra VB functionality a bonus - but an unintended one - the idea is only to support string type properties.