I have a CSLA 4.1 Silverlight application and noticed that CSLA doesn't seem to be flowing the client's CurrentCulture to the server's current thread.
I made a few changes to the Silverlight SimpleApp to test this out. In App.xaml.cs, I added the following to Application_Startup:
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-GB");
In CustomEdit.DataPortal_Insert, I put a breakpoint near the beginning. After choosing to save a new item, the CurrentCulture is "en-US", which is the setting on the server. I expected it to be "en-GB".
Am I missing something, or is CSLA behaving correctly? My understanding is that CSLA is supposed to establish the client's CurrentCulture and CurrentUICulture on the server automatically.
In looking at the code, I notice that Csla.Server.Hosts.Silverlight.WcfPortal.Update uses an UpdateRequest object, which has properties for CurrentCulture and CurrentUICulture. From debugging, the server does seem to be getting the anticipated values for these properties (e.g. en-GB), but nothing in WcfPortal appears to reference these properties. So, WcfPortal calls SilverlightRequestProcessor.Update, which calls Csla.DataPortal.Update, which instantiates a DataPortalContext that references CurrentCulture on the executing thread, but that is en-US.
This seem like a bug. Will look into this for Csla 4.5.
Ah, I noticed this but thought the issue was probably due to something I had done. I took a quick fix and set the culture in the web.config as work around, then proceeded to forget about it.
It's good to know it's a general issue and not just me!
Fixed for CSLA 4.5
Copyright (c) Marimer LLC