Erstellen von Satellitenassemblys
Aktualisiert: November 2007
Das unter Verpacken und Bereitstellen von Ressourcen beschriebene strahlenförmige Modell stellt die empfohlene Designimplementierung zur Entwicklung von Anwendungen mit Ressourcen dar.
Bei diesem strahlenförmigen Modell müssen Ressourcen in bestimmten Speicherorten gespeichert werden, sodass sie leicht abgerufen und verwendet werden können. Werden Ressourcen nicht wie vorgesehen kompiliert oder benannt, oder nicht am richtigen Speicherort gespeichert, können sie von Common Language Runtime nicht gefunden werden. Common Language Runtime verwendet dann den Standardressourcensatz. Weitere Informationen zu Ressourcennamen finden Sie unter CultureInfo-Klasse oder unter Verpacken und Bereitstellen von Ressourcen.
Kompilieren von Satellitenassemblys
Verwenden Sie das Assembly Linker-Tool (Al.exe), um RESOURCES-Dateien in Satellitenassemblys zu kompilieren. Al.exe erstellt aus den von Ihnen angegebenen RESOURCES-Dateien eine Assembly. Satellitenassemblys können grundsätzlich nur Ressourcen enthalten. Sie können keinen ausführbaren Code enthalten.
Mit dem folgenden Al.exe-Befehl wird aus der Datei strings.de.resources eine Satellitenassembly für die Anwendung MyApp erstellt.
al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
Mit dem folgenden Al.exe-Befehl wird aus der Datei strings.de.resources ebenfalls eine Satellitenassembly für die Anwendung MyApp erstellt. Die /template-Option bewirkt, dass die Satellitenassembly die Assemblymetadaten von der übergeordneten Assemly MyApp.dll erbt.
al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
/template:MyApp.dll
Folgende Tabelle beschreibt die in diesen Beispielen verwenden Al.exe-Optionen genauer.
Option |
Beschreibung |
---|---|
/t:lib |
Die /t-Option gibt an, dass die Satellitenassembly in eine Bibliotheksdatei (.dll) konvertiert wird. Eine Satellitenassembly kann nicht ausgeführt werden, da sie keinen Code enthält und ist nicht die Hauptassembly einer Anwendung. Daher müssen Satellitenassemblys als DLL-Dateien gespeichert werden. |
/embed:strings.de.resources |
Die /embed-Option gibt den Namen der beim Kompilieren einer Assembly mit Al.exe zu verwendenden Quelldatei an. Beachten Sie, dass mehrere RESOURCES-Dateien in eine Satellitenassembly einbetten werden können. Wenn Sie jedoch das strahlenförmige Modell verwenden, müssen Sie eine Satellitenassembly für jede Kultur kompilieren. Sie können jedoch separate RESOURCES-Dateien für Zeichenfolgen und Objekte erstellen. |
/culture:de |
Die /culture-Option gibt die zu kompilierende Kultur der Ressource an. Die Laufzeit verwendet diese Informationen zum Suchen nach Ressourcen für eine bestimmte Kultur. Wenn Sie diese Option weglassen, wird die Ressource dennoch von Al.exe kompiliert, die Laufzeit kann sie jedoch nicht mehr finden, wenn ein Benutzer sie anfordert. |
/out:MyApp.resources.dll |
Die /out-Option gibt den Namen der Ausgabedatei an. Der Name muss dem Namensstandard baseName.resources.extension entsprechen, wobei baseName für den Namen der Hauptassembly und extension für eine geeignete Erweiterung steht (z. B: .dll). Beachten Sie, dass Common Language Runtime die Kultur einer Satellitenassembly nicht anhand ihres Ausgabedateinamens erkennen kann. Daher ist es wichtig, die Kultur mit der oben beschriebenen /culture-Option anzugeben. |
/template:filename |
Die /template-Option gibt eine Assembly an, von der alle Assemblymetadaten bis auf das Kulturfeld geerbt werden. Die Assembly, von der die Satellitenassembly erbt, muss einen starken Namen haben. |
Eine vollständige Liste der für Al.exe verfügbaren Optionen finden Sie unter Assembly Linker-Tool (Al.exe).
Kompilieren von Satellitenassemblys mit starkem Namen
Assemblys, die im globalen Assemblycache installiert werden sollen, müssen einen starken Namen haben. Assemblys mit starkem Namen werden mit einem gültigen öffentlichen/privaten Schlüsselpaar signiert. Weitere Informationen zu starken Namen finden Sie unter Assemblys mit starkem Namen.
Bei der Entwicklung einer Anwendung ist es unwahrscheinlich, dass Sie auf das endgültige öffentliche/private Schlüsselpaar zugreifen können. Um eine Satellitenassembly im globalen Assemblycache zu installieren und sicherzustellen, dass sie erwartungsgemäß funktioniert, können Sie die so genannte verzögerte Signierung anwenden. Wenn Sie eine Assembly verzögert signieren, reservieren Sie zur Erstellungszeit Speicherplatz in der Datei für die Signatur mit starkem Namen. Die eigentliche Signierung wird auf einen späteren Zeitpunkt verschoben, zu dem das endgültige öffentliche/private Schlüsselpaar verfügbar ist.
Abrufen des öffentlichen Schlüssels
Um eine Assembly verzögert zu signieren, müssen Sie auf den öffentlichen Schlüssel zugreifen können. Sie können entweder den echten öffentlichen Schlüssel über die zuständige Organisation Ihres Unternehmens ermitteln oder einen öffentlichen Schlüssel mit dem Strong Name-Tool (Sn.exe) erstellen.
Durch den folgenden Sn.exe-Befehl wird ein aus einem privaten und einem öffentlichen Schlüssel bestehendes Testschlüsselpaar erstellt und in der Datei TestKeyPair.snk gespeichert. Die –k-Option weist Sn.exe an, ein neues Schlüsselpaar zu erstellen und in der angegebenen Datei zu speichern.
sn –k TestKeyPair.snk
Sie können den öffentlichen Schlüssel aus der Datei mit dem Testschlüsselpaar extrahieren. Der folgende Befehl extrahiert den öffentlichen Schlüssel aus TestKeyPair.snk und speichert ihn in PublicKey.snk.
sn –p TestKeyPair.snk PublicKey.snk
Verzögertes Signieren einer Assembly
Nachdem Sie den öffentlichen Schlüssel ermittelt bzw. erstellt haben, können Sie mithilfe des Assembly Linker-Tools (Al.exe) die Assembly kompilieren und verzögerte Signierung festlegen.
Mit folgendem Al.exe-Befehl wird aus der Ressourcendatei strings.ja.resources eine Satellitenassembly mit starkem Namen für die Anwendung MyApp erstellt.
al /t:lib /embed:strings.ja.resources /culture:ja /out:MyApp.resources.dll /delay+ /keyfile:PublicKey.snk
Die /delay+-Option legt fest, die Assembly verzögert zu signieren. Die /keyfile:-Option gibt den Namen der Schlüsseldatei an, die den öffentlichen Schlüssel zum verzögerten Signieren der Assembly enthält.
Weitere Informationen zum verzögerten Signieren finden Sie unter Verzögertes Signieren einer Assembly.
Hinweis: Assemblys mit starkem Namen verfügen über Versionsinformationen, mit deren Hilfe Common Language Runtime feststellen kann, welche Assembly mit einer angeforderten Bindung übereinstimmt. Weitere Informationen dazu finden Sie unter Assemblyversionen.
Erneutes Signieren einer Assembly
Eine verzögert signierte Satellitenassembly muss zu einem späteren Zeitpunkt mit einem echten Schlüsselpaar erneut signiert werden. Dies kann mit Sn.exe erfolgen.
Durch folgenden Sn.exe-Befehl wird MyApp.resources.dll mit dem in der Datei RealKeyPair.snk gespeicherten echten Schlüsselpaar signiert Die –R-Option weist Sn.exe an, eine zu einem früheren Zeitpunkt (verzögert) signierte Assembly erneut zu signieren.
sn –R MyApp.resources.dll RealKeyPair.snk
Installieren einer Satellitenassembly im globalen Assemblycache
Während des Ressourcenfallback-Prozesses ist der globale Assemblycache der erste Ort, den die Common Language Runtime nach Ressourcen durchsucht. Weitere Informationen finden Sie im untergeordneten Thema "Ressourcenfallback-Prozess" des Themas Verpacken und Bereitstellen von Ressourcen. Daher ist es wichtig zu wissen, wie Ressourcen im globalen Assemblycache installiert werden. Eine kompilierte Assembly mit starkem Namen kann im globalen Assemblycache installiert werden. Sie können eine solche Assembly mit dem Global Assembly Cache-Tool (Gacutil.exe) im Cache installieren.
Mit dem folgenden Gacutil.exe-Befehl wird die Assembly MyApp.resources.dll im globalen Assemblycache installiert.
gacutil /i:MyApp.resources.dll
Die /i-Option weist Gacutil.exe an, die angegebene Assembly im globalen Assemblycache zu installieren. Mit diesem Befehl wird ein Eintrag im Cache vorgenommen, durch den auf die Einträge in dieser RESOURCES-Datei zugegriffen werden kann. Nach der Installation im Cache ist die angegebene Ressource für alle Anwendungen verfügbar, die für deren Verwendung geeignet sind.
Verzeichnispfade für Satellitenassemblys, die nicht im globalen Assemblycache installiert sind
Nachdem Sie die Satellitenassemblys kompiliert haben, besitzen alle den gleichen Namen. Die Laufzeit unterscheidet die gleichnamigen Assemblys anhand der beim Kompilieren mit der /culture-Option angegebenen Kultur und anhand des Verzeichnispfades jeder Assembly. Sie müssen die Satellitenassemblys in den entsprechenden Verzeichnissen speichern.
Die folgende Abbildung zeigt eine Beispielverzeichnisstruktur und Anforderungen an den Speicherort für Anwendungen, die nicht im globalen Assemblycache installiert werden. Elemente mit den Dateierweiterungen .txt und .resources werden nicht mit der endgültigen Anwendung ausgeliefert. Dabei handelt es sich um temporäre Ressourcendateien, die zum Erstellen der endgültigen Satellitenressourcenassemblys dienen. In diesem Beispiel können RESX-Dateien durch TXT-Dateien ersetzt werden. Die RESX-Dateien sind die einzigen temporären Ressourcendateien, die Objekte enthalten können.
Satellitenassemblyverzeichnis
Hinweis: |
---|
Wenn die Anwendung Ressourcen für Teilkulturen enthält, speichern Sie jede Teilkultur in einem eigenen Verzeichnis. Speichern Sie keine Teilkultur in Unterverzeichnissen des Hauptkulturverzeichnisses. |
Siehe auch
Konzepte
Verpacken und Bereitstellen von Ressourcen
Verzögertes Signieren einer Assembly