Hi,
we are using CSLA v3.8.1.0 to create a WPF application. We are having a problem with the properties of the business objects getting mixed up while traveling through a WCF data portal. This is a result of different regional/culture setting on the server and on the machine that is running the WPF front end. While comparing the soap envelopes received from the dev server and from the local instance of data portal, I have found out that the properties of the business object are in different order. Our business object has the following properties: BusinessUnitName, ChannelName, ExternalID. The server is returning the fields in the specified order, but if the WPF front end is running on a machine with Slovak culture settings, it is expecting the fields to appear in following order: BusinessUnitName, ExternalID, ChannelName. This is because the letter "ch" (from the ChannelName property) comes after letter "h" in Slovak.
I have identified Csla.Core.FieldManager.PropertyInfoManager RegisterProperty method as the place where the list of properties is getting sorted.
Is there a way to make this sorting culture independent or any other possible solution to this problem?
Thank you
You could try this:
public static PropertyInfo<T> RegisterProperty<T>(Type objectType, PropertyInfo<T> info)
{
var list = GetPropertyListCache(objectType);
lock (list)
{
if (list.IsLocked)
throw new InvalidOperationException(string.Format(Resources.PropertyRegisterNotAllowed, info.Name, objectType.Name));
list.Add(info);
list.Sort(new PropertyComparer());
}
return info;
}
public class PropertyComparer : Comparer<IPropertyInfo>
{
public override int Compare(IPropertyInfo x, IPropertyInfo y)
{
return StringComparer.InvariantCultureIgnoreCase.Compare(x.Name, y.Name);
}
}
This would sort the PropertyInfos using InvariantCulture.
Yes,but this would require modification of the PropertyInfoManager class (please correct me if I'm wrong). But the CSLA project is not part of my solution. I'm just referencing the pre-build Csla.dll.
Unfortunately - that is the only solution to your problem.
It is probably a bug in Csla that will require changes in the source code and recompile of Csla.
Would you think that setting the CurrentThread.CurrentCulture to invariant culture would make any difference?
Probably - but that would also have consequences for resources and formatting.
Copyright (c) Marimer LLC