Thank you for your contribution.
I'm not sure if the implementation is what we want. @rockfordlhotka shoud make a decision here.
My "problem" is: With the new implemention you can't set a string property to null because the CSLA default is string.Empty.
This is a breaking change in current behavior and I don't know how many people rely on that.
I'm personally okay with this change.

@StefanOssendorf I've got the same conversion from null to String.Empty when trying to write null value directly to a string property because of

@StefanOssendorf I've got the same conversion from null to String.Empty when trying to write null value directly to a string property because of

csla/Source/Csla/Core/BusinessBase.cs

Lines 2451 to 2452 in a60f4da

	if (typeof(P) == typeof(string) && newValue == null)
	newValue = Utilities.CoerceValue<P>(typeof(string), null, string.Empty);

That may be the case. But currently a rule can set a string to null with an out value. I just tested that with 8.1.0.

The reason that, in general, CSLA tries to ensure that a string property is empty instead of null, is that (iirc) Windows Forms data binding can't handle null in some cases.

If someone is using Windows Forms and they created a rule that set a string to null, that would probably cause data binding to fail in their app. I don't think anyone else would notice, because I don't think any other UI frameworks have this limitation.

All that said, this is a breaking change - but one that has no real meaning, since CSLA string properties generally convert null into empty already.

Someday maybe we'll change everything to support null string property values, but that day is not today.

I think this change is fine.

@StefanOssendorf Can we merge then?

Alrighty. LGTM then :-)

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.