XmlHelper.CultureNameForXmlValueConversion This parameter just set the name and only for the default culture settings.

If users customize their regional settings, by replacing decimal separator and group separator.It doesn't work.

It looks like LLBLGEN not supporting the multi-language server-client architecture(WCF)... Do you have a plan about that case?

Regards...

Which LLBLGen Pro runtime library version are you using?

Isn't this the same issue as in the following thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11949

LLBLGEN Pro 2.5 Final June 2nd, 2008 and it's libraries....

Sorry not same. We are already used this setting option. But this is not quite enough.

We are sending client current culture to WCF and setting *Thread.CurrentCulture, every thing ok, until we come to LLBLGEN.

CultureNameForXmlValueConversion this option only set the culture name and LLBLGEN get's it's default calendar and number formatting, etc... options.

User should be customized his/her regional settings: For example: Default English decimal point "." and group separator "," if user change this decimal point "," group separator "." without changing his/her language.

We need to set full culture info of serialize/deserialize process. Some thing like that XmlHelper.Culture = *clientCulture;

Regards...

It's working now; But we are not sure exactly how.

Is LLBLGEN refresh culture settings when XmlHelper.CultureNameForXmlValueConversion change ?

public class CustomInspector : IClientMessageInspector, IDispatchMessageInspector {

        // Multi-Language Support;
        private const string CultureKey = "culture";

        #region IDispatchMessageInspector Members

        public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) {
            int headerIndex = request.Headers.FindHeader(CultureKey, string.Empty);
            if (headerIndex != -1) {
                Thread.CurrentThread.CurrentCulture.ClearCachedData();
                Thread.CurrentThread.CurrentCulture = request.Headers.GetHeader<CultureInfo>(headerIndex);
                XmlHelper.CultureNameForXmlValueConversion = Thread.CurrentThread.CurrentCulture.Name;
            }
            return null;
        }

        public void BeforeSendReply(ref Message reply, object correlationState) { }

        #endregion



        #region IClientMessageInspector Members

        public void AfterReceiveReply(ref Message reply, object correlationState) { }

        public object BeforeSendRequest(ref Message request, IClientChannel channel) {
            //XmlHelper.CultureNameForXmlValueConversion = Thread.CurrentThread.CurrentCulture.Name; // Moved client startup
            request.Headers.Add(MessageHeader.CreateHeader(CultureKey, string.Empty, Thread.CurrentThread.CurrentCulture));
            return null;
        }

        #endregion

    }

Sorry I am wrong. It doesn't work !!!

If Client customize his/her regional settings, solution is not working.

Please review this message. It is really important for us...

Yours respectfully...

Do you mean that you have different clients that need to send different cultures to a server, and get the XML serialized in a different culture per client ?

Are they using the XML for anything other than client server communication - if not, is it not acceptable to use a single common culture on both sides - regardless of what the client's actual culture settings are...?

Matt

Yes i mean we have different clients with their own regional settings (customized or not).

Unfortunately not acceptable...

We cant force our customers to use our specified type of regional settings. They are not using the XML anything other than communication...

If you are going to offer some kind a solution after this word. You are really welcome

Note : We are using TypedList's on grids for search or listing purpose they are quite okay. We think this is okay because TypedList's inherited from DataTable and not serialized by LLBLGEN method...

Regards...

But if you set the culture in the config file on both sides of the client-server boundary the client does not need to worry about it - it will be serialized using the culture you set, and the deserialized using the same culture on the other side...

Matt

Can you explain this solution ?

You mean, for example:

configure Server on app.config <add key="cultureNameForXmlValueConversion" value="en-US" /> and client with same config <add key="cultureNameForXmlValueConversion" value="en-US" />

If client regional settings is different than "en-US" with some customization; Is this still okay ?

If it is, i am very glad to hear that

Regards...

That's my understanding - I'll get someone to check for you.

Matt

I will be grateful for your assistance...

Yours Respectfully...

Sorry it doesn't work...

When client customize his/her regional setting for example replacing decimal point with group separator: tr-TR defaults is decimal separator "," decimal group separator "." tr-TR customized decimal separator "." decimal group separator ","

When client change regional settings by using its defaults there is no problem. Problem occurs when client customize his/her regional settings...

So, we have to set LLBLGEN full serialization deserialization CultureInfo per thread...

We think this specialty not considered yet...

This specialty very important for us and a lot of your customers who develops International solutions...

This is very critic situation for our project, please help us...

Regards...

You have to use the same culture on the serialization side and the deserialization side. This is important for the following reason: say I use dutch on the server and en-US on the client. Dutch has as decimal delimiter a '.' and for thousands a ',' and en-US has the opposite: ',' for decimal delimiter and '.' for thousands.

When I serialize the xml on the server in Dutch, a value 12456.1234 (en-US format) will become 12.345,1234 in XML. On the client, it is then DEserialized using en-US, and it likely will cause problems because the deserialization process uses '.' and ',' opposite of the server and will think hte value is 12.345 (en-US format), while the real value is much higher.

The culture set in CultureNameForXmlValueConversion is only for the XML data. So it's not affecting any other operation in the system and it doesn't look at the local windows regional settings. So if you need turkish regional settings, you should set CultureNameForXmlValueConversion on both client and server to the same value. If you use different values, it will go wrong for the reason I explained above.

If the client customizes the regional settings, there's not much we can do, as the culture is simply obtained through .NET. So it should work with en-US on both sides, regardless if the client has set local culture to tr-TR and changed that. If you're unsure, leave it to "" which uses the invariant culture which can't be changed.

From MSDN:

Remember that custom cultures override default values. Therefore, you cannot consider culture data to be stable. Country names, date formats, spellings, etc., will probably change in the future. If your application needs to serialize using this data, as for the DateTime formatting and parsing functions, it should use the invariant culture or a specific format.

It's ok to use "", because it's only used to serialize/deserialize the XML, not for anything else.

We are very grateful to you.

We try many things so hard on this situation than we miss invariant use...

public class CustomInspector : IClientMessageInspector, IDispatchMessageInspector {

        private const string CultureKey = "culture";

        #region IDispatchMessageInspector Members

        public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) {
            int headerIndex = request.Headers.FindHeader(CultureKey, string.Empty);
            if (headerIndex != -1) {
                if (Thread.CurrentThread.CurrentCulture != request.Headers.GetHeader<CultureInfo>(headerIndex)) {
                    Thread.CurrentThread.CurrentCulture.ClearCachedData();
                    Thread.CurrentThread.CurrentCulture = request.Headers.GetHeader<CultureInfo>(headerIndex);
                }
            }
            return null;
        }

        public void BeforeSendReply(ref Message reply, object correlationState) { }

        #endregion



        #region IClientMessageInspector Members

        public void AfterReceiveReply(ref Message reply, object correlationState) { }

        public object BeforeSendRequest(ref Message request, IClientChannel channel) {
            request.Headers.Add(MessageHeader.CreateHeader(CultureKey, string.Empty, Thread.CurrentThread.CurrentCulture));
            return null;
        }

        #endregion

    }

This code is working on .net serialized/deserialized types. This code cannot be able to change LLBLGEN serialization/deserialization culture info, we think because; Our DataAccessAdapter definetion on a Singoltan and sealed class...

With this code, when we use variant configuration with CultureNameForXmlValueConversion, it just doesn't work...

When we set CultureNameForXmlValueConversion to "" invariant for both sides, its perfectly working now...

Thank you so much for your assistance... Regards...