Teilen über

Ressourcen in .NET-Apps

  • Artikel

Fast jede professionell erstellte App benötigt Ressourcen. Bei einer Ressource handelt es sich um beliebige nicht ausführbare Daten, die logisch mit einer App bereitgestellt werden. Eine Ressource kann in einer App als Fehlermeldung oder als Teil der Benutzeroberfläche angezeigt werden. Ressourcen können verschiedene Formen von Daten enthalten, z. B. Zeichenfolgen, Bilder und beibehaltene Objekte. (Wenn Sie persistente Objekte in eine Ressourcendatei schreiben möchten, so müssen die Objekte serialisierbar sein.) Durch Speichern von Daten in einer Ressourcendatei können Sie die Daten ändern, ohne die gesamte App neu kompilieren zu müssen. Außerdem können Sie dadurch die Daten an einem einzigen Ort speichern und müssen nicht auf hartcodierte Daten zurückgreifen, die an mehreren Orten gespeichert wird.

.NET stellt umfassende Unterstützung zum Erstellen und Lokalisieren von Ressourcen zur Verfügung. Außerdem unterstützt .NET ein einfaches Modell zum Verpacken und Bereitstellen lokalisierter Ressourcen.

Erstellen und Lokalisieren von Ressourcen

In einer nicht lokalisierten App können Sie Ressourcendateien als Repository für App-Daten verwenden. Dies gilt besonders für Zeichenfolgen, die andernfalls an mehreren Stellen im Quellcode hartcodiert wären. Im Allgemeinen werden Ressourcen als Textdateien (.txt) oder XML-Dateien (.resx) erstellt und dann mit Resgen.exe (Resource File Generator) in binäre .resources-Dateien kompiliert. Diese Dateien können dann durch einen Sprachcompiler in die ausführbare Datei der App eingebettet werden. Weitere Informationen zum Erstellen von Ressourcen finden Sie unter Erstellen von Ressourcendateien.

Sie können die Ressourcen der App auch für bestimmte Kulturen lokalisieren. Dadurch können Sie lokalisierte (übersetzte) Versionen der Apps erstellen. Wenn Sie eine App entwickeln, die lokalisierte Ressourcen verwendet, legen Sie eine Kultur als neutrale bzw. Ausweichkultur fest, deren Ressourcen verwendet werden, wenn keine passenden Ressourcen verfügbar sind. In der Regel werden die Ressourcen der neutralen Kultur in der ausführbaren Datei der App gespeichert. Die verbleibenden Ressourcen für einzelne lokalisierte Kulturen werden in eigenständigen Satellitenassemblys gespeichert. Weitere Informationen finden Sie unter Erstellen von Satellitenassemblys.

Verpacken und Bereitstellen von Ressourcen

Lokalisierte App-Ressourcen werden in Satellitenassemblys bereitgestellt. Eine Satellitenassembly enthält die Ressourcen einer einzelnen Kultur. Sie enthält keinen App-Code. Im Satellitenassembly-Bereitstellungsmodell erstellen Sie eine App mit einer Standardassembly (in der Regel die Hauptassembly) und einer Satellitenassembly für jede Kultur, die von der App unterstützt wird. Da die Satellitenassemblys kein Teil der Hauptassembly sind, können Sie die Ressourcen problemlos entsprechend einer bestimmten Kultur ersetzen oder aktualisieren, ohne die Hauptassembly der App ersetzen zu müssen.

Überlegen Sie genau, aus welchen Ressourcen die Standardressourcenassembly der App bestehen soll. Da diese ein Teil der Hauptassembly ist, müssen Sie nach jeder Änderung daran auch die Hauptassembly ersetzen. Wenn Sie keine Standardressource angeben, wird eine Ausnahme ausgelöst, wenn der Ressourcenfallback-Prozess versucht, sie zu finden. In einer gut entworfenen App sollte die Verwendung von Ressourcen nie Ausnahmen auslösen.

Weitere Informationen finden Sie im Artikel Packen und Bereitstellen von Ressourcen.

Abrufen von Ressourcen

Zur Laufzeit werden von einer App die passenden lokalisierten Ressourcen auf Threadbasis entsprechend der Kultur geladen, die von der CultureInfo.CurrentUICulture-Eigenschaft angegeben wird. Dieser Eigenschaftswert wird wie folgt abgeleitet:

  • Durch direktes Zuweisen eines CultureInfo-Objekts, das die lokalisierte Kultur darstellt, zur Thread.CurrentUICulture-Eigenschaft.

  • Wenn keine Kultur explizit zugeordnet wurde, durch Abrufen der Benutzeroberflächenkultur des Standardthreads von der CultureInfo.DefaultThreadCurrentUICulture-Eigenschaft.

  • Wenn keine Benutzeroberflächenkultur des Standardthreads explizit zugeordnet wurde, durch Abrufen der Kultur für den aktuellen Benutzer auf dem lokalen Computer. Dazu rufen unter Windows ausgeführte .NET-Implementierungen die Windows-Funktion GetUserDefaultUILanguage auf.

Weitere Informationen darüber, wie die aktuelle Benutzeroberflächenkultur festgelegt wird, finden Sie auf den Referenzseiten CultureInfo und CultureInfo.CurrentUICulture.

Sie können Ressourcen dann für die aktuelle Benutzeroberflächenkultur oder für eine bestimmte Kultur abrufen, indem Sie die System.Resources.ResourceManager-Klasse verwenden. Die ResourceManager-Klasse wird zwar am häufigsten zum Abrufen von Ressourcen verwendet, der System.Resources-Namespace enthält jedoch weitere Typen, die Sie zum Abrufen von Ressourcen verwenden können. Dazu gehören:

  • Die ResourceReader-Klasse, mit der Sie Ressourcen auflisten können, die in eine Assembly eingebettet oder in einer eigenständigen binären „.resources“-Datei gespeichert sind. Dies ist nützlich, wenn Sie die genauen Namen der Ressourcen nicht kennen, die zur Laufzeit verfügbar sind.

  • Die ResXResourceReader-Klasse, mit der Sie Ressourcen aus einer XML-Datei (.resx) abrufen können.

  • Die ResourceSet-Klasse, mit der Sie Ressourcen einer bestimmten Kultur abrufen können, ohne Fallbackregeln zu beachten. Die Ressourcen können in einer Assembly oder einer eigenständigen binären „.resources“-Datei gespeichert werden. Sie können auch eine IResourceReader-Implementierung entwickeln, die Ihnen ermöglicht, mit der ResourceSet-Klasse Ressourcen aus einer anderen Quelle abzurufen.

  • Die ResXResourceSet-Klasse, mit der Sie alle Elemente in einer XML-Ressourcendatei in den Speicher abrufen können.

Siehe auch