Imagine you're working on a .Net 4.0 project that is made up of hundreds of assemblies, each having its own resource file (.resx) for localization. The localized strings are accessed from C# through classes auto-generated with ResXFileCodeGenerator (which creates a "ResourceFile.Designer.cs" file): string test = ResourceFile.TestString;
Each assembly has localized strings which are particular to it, but there are strings which are common to all assemblies. You tell yourself that it would be nice to have those "common strings" in a "parent" resource file, on which the code would fall back if the resource key is not available in the "local" resource file. You then say "Hey! inheritance could work here." And indeed, doing something like this in the auto-generated designer file does work:
internal class ResourceFile : ParentResourceFile
That is, strings not defined in ResourceFile
, but defined in ParentResourceFile
, can still be accessed with ResourceFile.StringInParentFile
.
But something in the designer file's header troubles you: "Changes to this file may cause incorrect behavior and will be lost if the code is regenerated." Plus you know playing in the auto-generated designer files is frowned upon. So you come here, and you ask:
- When does ResXFileCodeGenerator generate/regenerate the designer class?
- Is there a way to turn off that auto-generation?
- Will we have to forego the advantages of ResXFileCodeGenerator and implement our own handling of ResourceManager?
And you say "thank you".