.NET resources hierarchy unrelated to culture

Question

I have some string resources, e.g. a user welcome string. By default it should be "Hello", but for customer X it should be "Greetings".

I'd like to use .NET's resources implementation, and have the strings sit in constants or in files or wherever I like, plus the hierarchy model fits my needs: customer X's resources override the user welcome string.

The only problem - it seems like .NET's resources are geared towards i18n, and they choose from the hierarchy based on the current culture.

For now I'll be keeping flat resources per customer and mapping the hierarchy myself, but is there a better solution?

Answer 1

There really isn't anything stopping you from having multiple ResourceManagers, but as you say it was designed for l18n. Personally I have had lots of trouble with the resx stuff especially when it came to satellite assemblies the GAC and deployment. The other issue I have is the rigidity of this system, if you ever need a new string you need to recompile a dll and muck around with xml, your customers have no flexibility around fixing stuff up, something that does eat in to support time.

The hierarchy based solution the resx stuff has means it will fall back from "en-US" to "en" and finally to invariant, you don't have more fallbacks than that and you can not define two different "en-US" in one resource file for the same string. You could hack this solution to use "en-US" for customer X and "en-AU" for customer Y and then ship as one resource but this is messy as hell.

You could compile a different satellite assembly for each customer and get this to work somehow.

Personally, I much prefer a database backed solution for localization using either sqlite or mssql, and ensuring I perform some caching after initial string lookups.