Can not register Custom Culture on Azure Web App

[felixcollins]

Hi, We are trying to use custom cultures to allow client by client overrides of a few resources in an ASP web app. The idea was to set the thread ui culture on the incoming request to the client's custom culture. This all works rather well.

The fly in the ointment with this scheme is that on Azure web apps (where we wish to deploy) one can not register a new custom culture with the system (because the system is shared and getting admin privileges is prevented). This means that we can not set the request thread culture to our custom culture (it is not registered) and can not retrieve the custom resources. It does not seem to be possible to create a CultureInfo object for an unregistered custom culture (without resorting to reflection to set private members). I appreciate that this issue is a problem with Microsoft's design of the resource system and not WestWind.Globalization.

Looking in the code, the final step in the process of retrieving the resource is to use the culture name to look up the correct resource. I'm wondering if it would be possible to pass the culture name as a string down the chain rather than using the CultureInfo object (obviously we'd also need to implement fall-back). This would mean it would be possible to retrieve resources using "private" or unregistered custom cultures. I've started looking at the code but it is a bit of a birds nest of classes (Microsoft's design, not yours) and it is unclear to me how it would be best attacked. Any advice on how to implement this would be appreciated.

I can either fork your code and submit a pull request with appropriate overrides implemented or we can maintain our fork for in house use. Would you accept a pull request with this new feature? Thanks Felix.

[intranel]

Here is our solution... open to suggestions to modify it. Especially if that means it will be integrated... https://github.com/RickStrahl/Westwind.Globalization/pull/72

[RickStrahl]

Hi Felix, thanks for the PR...

The code changes look fine, but I have reservations about adding it.

My concern about this is that it's likely not a universal solution. For example, it'd be difficult to use this if you fall back to RESX resources and strongly typed resources. There would be no way to access that custom locale in that case as those resources as well as all the native ASP.NET support infrastructure relies on current UI culture to determine what resources get loaded.

In essence, if we go down this path we're forcing use of this library in some way either via DbRes.T() or via strongly typed resources generated from this tool. You wouldn't be able to use raw RESX resources or even use it with say WebForms and implicit resource binding.

I have to look at the code a little closer. If this can be added without breaking any existing code (and I think it doesn't) then it might be Ok to add, but I'm just wary of sending people down this path that forces them into this particular solution that isn't portable.

Thoughts?

[intranel]

Hi Rick, I changed to the company github account... but it is still Felix here.

Ah... yes the strongly typed helper class. Hmmm.... I guess I'm going to have to modify your GeneratedResourceHelper too. I'll add a thread static string property to GeneratedResourceSettings for "PreferredCulture". If it is not set it will fall back to the default (CurrentUICulture).

I think my code should still work for people who want to use it with registered cultures. But yes you are correct, if you pass an unregistered culture (by string id) it would only work for the DB provider. I'm not sure if it is possible to get it to work for all use cases. Anywhere that the code falls back to the default MS implementation it will likely not work because MS code passes a CultureInfo around which we can not get hold of (for unregistered cultures).

I briefly looked into the CultureInfo source code to see if it would be possible to subclass it. It is not sealed but the thing is a huge beast so implementing a fully functional subclass could be difficult. I haven't tried it, but what do you think about the idea of subclassing CultureInfo to allow construction with an unregistered culture? I could then add an overload to DbRes.T (and the other JS and Strongly typed helpers) to take a CultureInfo instead of a language string. I would not try setting it to the Thread CurrentUICulture, just feed it to the resources system directly.

Oh, and if you have any other ideas about working around the Azure web apps limitation that does not involve fiddling with the resource system, let me know!

Thanks for your response. Felix

[kniganapolke]

Felix, what kind of solution have you finally ended up with?

[felixcollins]

We are moving to a custom solution.

[alecellis1985]

Anyone made this work in azure?

[RickStrahl]

I'm going to close this as I think there's not really a viable solution for this through this library and this is more of an issue with Azure/Host servers that don't support adding custom cultures.