Stellen Sie sich vor, Sie arbeiten an einem .Net 4.0-Projekt, das aus Hunderten von Assemblys besteht, von denen jede ihre eigene Ressourcendatei (.resx) für die Lokalisierung hat. Auf die lokalisierten Zeichenfolgen wird von C # über Klassen zugegriffen, die automatisch mit ResXFileCodeGenerator generiert wurden (wodurch eine Datei "ResourceFile.Designer.cs" erstellt wird): string test = ResourceFile.TestString;
Jede Assembly hat lokalisierte Strings, die für sie spezifisch sind, aber es gibt Strings, die allen Assemblys gemeinsam sind. Sie sagen sich, dass es schön wäre, diese "gemeinsamen Zeichenfolgen" in einer "übergeordneten" Ressourcendatei zu haben, auf die der Code zurückfallen würde, wenn der Ressourcenschlüssel in der "lokalen" Ressourcendatei nicht verfügbar wäre. Dann sagst du "Hey! Vererbung könnte hier funktionieren." Und tatsächlich funktioniert Folgendes in der automatisch generierten Designer-Datei:
%Code%
Das heißt, Zeichenfolgen, die nicht in internal class ResourceFile : ParentResourceFile definiert sind, aber in ResourceFile definiert sind, können weiterhin mit ParentResourceFile aufgerufen werden.
Aber etwas in der Header-Datei der Designer-Datei stört Sie: " Änderungen an dieser Datei können zu falschem Verhalten führen, und geht verloren, wenn der Code neu generiert wird. " Außerdem wissen Sie Das Abspielen in den automatisch generierten Designer-Dateien ist verpönt. Also kommst du her und fragst:
Und Sie sagen "Danke".
Nachdem ich das Problem eine Zeit lang untersucht habe, habe ich mich für eine Problemumgehung entschieden: Machen Sie Vererbung nicht für die Ressourcendateien selbst, sondern für die Klassen, die auf die "übergeordneten" Ressourcen zugreifen müssen.
Sie benötigen nur eine Basisklasse, deren Projekt eine "Master" -Ressourcendatei enthält, und legen Sie die CustomTool-Eigenschaft der Ressourcendatei auf PublicResXFileCodeGenerator fest (der "öffentliche" Teil ist wichtig, da er ein erstellt public class, im Gegensatz zu internal one). Eine Einschränkung ist, dass PublicResXFileCodeGenerator nur verfügbar ist, beginnend mit VS2008 (dieser CodeProject Artikel könnte sonst hilfreich sein).
Erben Sie dann in Klassen, die auf die "Master" -Ressourcen zugreifen müssen, einfach von der Basisklasse und greifen Sie auf die Ressourcen wie folgt zu:
%Vor%Ein Nachteil dieser Lösung besteht darin, dass Sie explizit auf BaseResourceFile verweisen müssen, um auf dort definierte Ressourcen zugreifen zu können. Es gibt kein Fallback für die Elternklasse, wie dies bei einer direkten Vererbung zwischen den Ressourcenklassen der Fall wäre.
Und für die Nachwelt beantworte ich meine eigenen Fragen:
Wann generiert ResXFileCodeGenerator den Designer? Klasse?
Immer wenn eine Ressource hinzugefügt / entfernt / geändert wird.
Gibt es eine Möglichkeit, diese automatische Generierung zu deaktivieren?
Nein. Und überhaupt wäre ein "Code Generator" -Tool ohne Auto-Generation ziemlich nutzlos, oder?
Müssen wir auf die Vorteile von ResXFileCodeGenerator verzichten und unsere implementieren? eigene Handhabung von ResourceManager?
Nein, siehe obige Antwort.
Wir haben auch überlegt, eine Lösung mit "verknüpften" Dateien zu implementieren (aus dem "Add existing item" -Dialog mit der "Add as link" -Option), wo eine übergeordnete Ressourcendatei mit all unseren Assemblys verbunden wäre, aber seit unseren Assemblies bereits von einer Basisklasse erben, schien es viel besser, den Vererbungsweg zu gehen.
Ich fühle mich nicht wohl dabei, meine eigene Antwort zu akzeptieren. Wenn jemand eine bessere Lösung oder Verbesserungen für meine Lösung vorschlägt, würde ich das gerne akzeptieren. Das heißt, wenn sich jemand überhaupt interessiert.
Tags und Links c# inheritance resx resource-files