Allgemeine Ressourcenkonzepte

Die meisten Aspekte der Programmierung mit .NET Framework sind für alle kompatiblen Sprachen identisch, weil alle unterstützten Sprachcompiler selbstbeschreibenden, verwalteten Microsoft Intermediate Language (MSIL)-Code erzeugen. Der verwaltete MSIL-Code wird gegen die Common Language Runtime ausgeführt, die eine sprachübergreifende Integration, automatische Speicherverwaltung, sprachübergreifende Ausnahmebehandlung, einen hohen Sicherheitsgrad und ein vereinfachtes Modell für Komponenteninteraktionen bereitstellt. Zusätzlich zur Runtime bietet .NET Framework die .NET Framework-Klassenbibliothek, auf die auch alle Sprachen zugreifen können, die mit .NET kompatibel sind. Einige Aspekte dieses allgemeinen Entwicklungsprozesses sind besonders wichtig bei der Entwicklung von Anwendungen, die Ressourcen verwenden.

Buildblöcke

Die von Ihnen und anderen Benutzern erstellten .NET Framework-Klassenbibliotheken werden auch in hierarchischen Namespaces organisiert und in übertragbaren ausführbaren Dateien (PE-Dateien), d. h. DLL- und EXE-Dateien, gespeichert. Sie können mehrere Namespaces, einschließlich verschachtelter Namespaces, in einer PE-Datei speichern und einen Namespace auf mehrere PE-Dateien aufteilen. Eine oder mehrere PE-Dateien (und möglicherweise andere Arten von Dateien, wie Ressourcen) werden kombiniert und bilden eine Assembly. Diese Assembly stellt eine physische Einheit dar, die weitergegeben werden kann, der eine Version zugewiesen werden kann und die wiederverwendbar ist. Die Runtime verwendet Assemblies, um Verweistypen zu suchen und eine Bindung an die Verweistypen durchzuführen. Ressourcen können auch in Assemblies zusammengefasst oder separat in verschiedene Formate verpackt werden. Sie können der Einfachheit halber aber auch als einzelne Dateien, wie JPEG-Bilder, verwendet werden. Informationen darüber, was eine Assembly ist, einschließlich der Klassen und Ressourcen, finden Sie im Assemblymanifest.

Kultureinstellungen

In .NET Framework bezeichnet Kultur die Sprache des Benutzers, die optional mit dem Standort des Benutzers verbunden ist. Durch die Kultureinstellungen werden eine Reihe von bestimmten Datenprofilen verfügbar, z. B. Zeichenfolgen-, Datums- und Zahlenformate, die den kulturspezifischen Konventionen (Sprache und Standort) eines Benutzers entsprechen.

Bei einem Standort kann es sich um ein Land oder eine Region handeln; letztere ist möglicherweise der geopolitisch korrekte Begriff bei einem Standort in einem Land, das nicht offiziell anerkannt ist. Sprache und Standort können mit den Codes angegebenen werden, die im Internet RFC 1766, "Tags for the Identification of Languages", definiert wurden. Die tatsächlichen Codes selbst sind in zwei ISO-Normen definiert: ISO 639, "Code for the representation of names of languages", und ISO 3166, "Codes for the representation of names of countries". Weitere Referenzinformationen über diese Normen finden Sie unter "Sprach- und Landes-/Regionstags" in Anhang A: Weitere Ressourceninformationen.

Der Zugriff auf die genauen Profile einer Kultur erfolgt mit Instanzen der CultureInfo-Klasse, auf die wiederum mit Kulturtags zugegriffen werden kann. Kulturtags verwenden das Format primär[-sekundär], wobei das primäre Tag die Sprache und das optionale sekundäre Tag den Länder-/Regionscode angibt. Entsprechend einer Konvention besteht das Sprachtag aus zwei Kleinbuchstaben und der Länder-/Regionstag aus zwei Großbuchstaben. Die folgende Tabelle zeigt Beispiele für Kulturtags.

de	Deutsch
de-AT	Deutsch – Österreich
de-CH	Deutsch – Schweiz
en	Englisch
en-US	Englisch – USA
en-AU	Englisch – Australien
en-CA	Englisch - Kanada
fr	Französisch
sp	Spanisch

In .NET Framework bedeuten aus zwei Buchstaben bestehende Tags neutrale Sprachkulturen, wie de für Deutsch. Aus vier Buchstaben bestehende Tags geben bestimmte Kulturen an, wie fr-CA für kanadisches Französisch. In den meisten Fällen wird die Benutzeroberfläche als spezifische Kultur angegeben. Allerdings gibt es in einigen Fällen, wie ja-JP für in Japan gesprochenes Japanisch, nur eine bestimmte Kultur für eine bestimmte neutrale Kultur; in einem solchen Fall sind die beiden Tags oftmals austauschbar. Wenn eine Anwendung in der Lage sein muss, eine Kultur auf eine bestimmte Kultur festzulegen, z. B. auf Grund einer Einstellung für einen Internetbrowser, muss die Anwendung alle neutralen Kulturen mit Hilfe der CreateSpecificCulture-Methode den entsprechenden spezifischen Kulturen zuweisen.

In .NET Framework nimmt die Kultureinstellung den Platz des auf Sprachunterstützung beruhenden Gebietsschemas ein, das mit einem System von LCID-Codes (Gebietsschema-ID) arbeitete. Die LCID-Eigenschaft der CultureInfo-Klasse schafft Interoperabilität und erleichtert die Integration in NLS-basierte Software.

.NET-Ressourcenklassen

Die .NET Framework-Klassenbibliothek bietet mehrere Klassen, die Entwickler bei der Verwendung von Ressourcen in Anwendungen und Tools unterstützen.

ResourceManager-Klasse

Die ResourceManager-Klasse (im System.Resources-Namespace) bietet zur Laufzeit komfortablen Zugriff auf Ressourcen für die entsprechende Kultur. Diese Klasse stellt eine Ressourcenfallback – im Allgemeinen die neutrale Kultur – bereit, wenn keine lokalisierte Ressource vorhanden ist, unterstützt eine Ressourcenserialisierung und stellt die CreateFileBasedResourceManager-Methode für den Zugriff auf Ressourcen zur Verfügung, die nicht in der Assembly enthalten sind. Beim Erstellen von benutzerdefinierten Ressourcenlösungen können Klassen natürlich auch von ResourceManager abgeleitet werden.

ResourceWriter-Klasse

Die ResourceWriter-Klasse im System.Resources-Namespace schreibt Ressourcen im Standardformat des Systems in eine Ausgabedatei oder einen Stream. Ressourcen werden unter Verwendung der AddResource-Methode als Name-Wert-Paare angegeben. Bei Ressourcennamen wird zwischen Groß- und Kleinschreibung unterschieden, wenn sie für Suchvorgänge verwendet werden; ResourceWriter schreibt jedoch keinen Ressourcennamen in eine RESOURCES-Datei, wenn sich der Name nur durch die Groß-/Kleinschreibung unterscheidet. Die ResourceWriter-Klasse stellt eine Standardimplementierung der IResourceWriter-Schnittstelle bereit, die vom Programmierer überschrieben werden kann.

**Hinweis   **Ressourcen werden nicht unbedingt in der Reihenfolge geschrieben, in der sie programmgesteuert hinzugefügt wurden.

ResourceReader-Klasse

Die ResourceReader-Klasse im System.Resources-Namespace listet RESOURCES-Dateien und Streams auf und liest die sequenziellen Paare von Ressourcennamen und -werten. Diese Klasse stellt eine Standardimplementierung der IResourceReader-Schnittstelle zur Verfügung, die, wie die ResourceWriter-Klasse, vom Entwickler überschrieben werden kann.

ResourceSet-Klasse

Die ResourceSet-Klasse im System.Resources-Namespace speichert alle Ressourcen, die für eine bestimmte Kultur lokalisiert wurden. Alle Ressourcen werden umgehend in den Speicher geladen. Im Gegensatz zur ResourceManager-Klasse gibt es bei der ResourceSet-Klasse keine Rückfallressource. Daher ist die ResourceSet-Klasse in erster Linie beim Erstellen von Tools und Dienstprogrammen nützlich, aber nicht in lokalisierten Anwendungen. Die ResourceSet-Klasse kann auch verwendet werden, um das Zwischenspeichern von Ressourcen zu steuern (um z. B. das Zwischenspeichern von Bildern zu verhindern).

CultureInfo-Klasse

Die CultureInfo-Klasse im System.Globalization-Namespace enthält lediglich eine Reihe von Benutzereinstellungsinformationen, die abhängig von der Sprache, der Teilsprache, dem Land/der Region und den kulturellen Konventionen des Benutzers sind. Diese Klasse wird zum Formatieren von Datumsangaben, Zeitangaben und Zahlen, zum Sortieren von Zeichenfolgen und zum Bestimmen der Textsprache verwendet.

RegionInfo-Klasse

Mit der RegionInfo-Klasse im System.Globalization-Namespace wird die Maßeinheit festgestellt und Regionscodes Regionsnamen zugewiesen.

Assembly.GetManifestResourceStream-Methode

Die Assembly.GetManifestResourceStream-Methode im System.Reflection-Namespace lädt Daten für Manifestressourcen direkt in einen Stream. Dies ist besonders dann nützlich, wenn Ressourcen in benutzerdefinierten Formaten gespeichert werden, die von einer ResourceManager-Klasse nicht verstanden würden.

**Hinweis   **Die Ressourcen müssen sich in einer Assembly befinden, damit die Assembly.GetManifestResourceStream-Methode verwendet werden kann.

Thread.CurrentUICulture-Eigenschaft

Die Thread.CurrentUICulture-Eigenschaft im System.Threading-Namespace ist dann nützlich, wenn die aktuelle Kultur bestimmt oder, wichtiger noch, die Kultur festgelegt werden muss, um die Verwendung einer anderen lokalisierten Windows-Version zu emulieren. Dies ist erforderlich, weil die Systemsteuerung nicht mehrere LCIDs für Benutzeroberflächen in einer Windows 2000-Version anzeigen kann, die keine mehrsprachige Benutzeroberfläche besitzt. Stattdessen kann die Kultur zur Laufzeit programmgesteuert auf Threadbasis festgelegt werden.

Weitergabe

Im einfachsten Fall kann eine eigenständige, ausführbare .NET Framework-Datei lokal auf einem beliebigen Computer ausgeführt werden, auf dem die Common Language Runtime bereits installiert ist. Es ist nichts weiter erforderlich – es werden keine Registrierungseinträge vorgenommen, eine andere Anwendung wird durch nichts unterbrochen oder angehalten, und durch ein einfaches Löschen der Datei (falls sie lokal kopiert wurde) kann die Anwendung so entfernt werden, dass sie keine Spuren auf dem Computer hinterlässt. Anwendungen, die von einem URL aus ausgeführt werden, der eine Website darstellt, verhalten sich etwas anders. In diesem Fall werden Assemblies im Downloadcache installiert, die später automatisch entfernt werden. Alle anderen Anwendungen, einschließlich der Anwendungen von einem URL, der eine Datei darstellt, werden vom Quellcode ausgeführt und auf dem lokalen Computer nicht zwischengespeichert.

Verteilung

Selbstverständlich werden die meisten Clientanwendungen weiterhin in einem allgemeinen Verteilungsformat verpackt (wie z. B. einer CAB- oder MSI-Datei) und viele werden mit Mechanismen zur Anwendungsverteilung installiert, wie Windows 2000 IntelliMirror oder Microsoft Systems Management Server (SMS), die beide die Microsoft Installer-Technologie verwenden. Weitere Informationen zum Microsoft Installer finden Sie im entsprechenden Abschnitt im Win32 SDK.

Siehe auch

Erstellen von Ressourcen | Abrufen von Ressourcen mit Hilfe von Code | Ressourcen – Zusammenfassung | Anhang A: Weitere Ressourceninformationen | Anhang B: Ressourcentools