Lokalisieren von Ressourcen für die Übersicht über Komponentenbibliotheken

Artikel
10/22/2014

Aktualisiert: November 2007

Der Begriff Lokalisierung bezeichnet die Anpassung einer Anwendung an eine bestimmte Kultur und Sprache. Die AJAX-Funktionalität in ASP.NET unterstützt die folgenden Lokalisierungsmodelle für Clientskript:

Das .NET Framework-Ressourcenmodell mit erweiterter Unterstützung für lokalisierte Ressourcen, die den ECMAScript (JavaScript)-Komponenten zugeordnet sind. In diesem Modell betten Sie Skriptdateien und lokalisierte Skriptressourcen in eine sternenförmige Anordnung von Assemblys ein (Sie verwenden also Satellitenassemblys). Sie können diese eingebetteten Clientskripts und die Ressourcen für bestimmte Sprachen und Regionen dann selektiv verwenden. Bei diesem Modell kann eine einzelne CodeBase mehrere Kulturen unterstützen.
Statische (eigenständige) JavaScript-Dateien auf Datenträger. Bei diesem Modell sind lokalisierte Dateien als JS-Dateien in einem einzelnen Verzeichnis gruppiert und nicht in eine Assembly eingebettet.
Aktualisierung von Skripts und Skriptressourcen, die mithilfe von statischen JavaScript-Dateien in eine Assembly eingebettet werden. Bei diesem Modell können Sie für eingebettete Skripte und Ressourcen zusätzliche Lokalisierungsunterstützung bereitstellen, ohne dass Änderungen der Originalassembly erforderlich sind.

Dieses Thema enthält folgende Informationen:

Szenarien
Background
Lokalisieren von Clientskripts und Skriptressourcen in Assemblys
Lokalisieren von statischen Skriptdateien und den dazugehörigen Ressourcen
Verwenden von ScriptManager zum Verwalten von Skripts an einem zentralen Speicherort
Codebeispiele
Klassenreferenz

Szenarien

AJAX-Features in ASP.NET unterstützen sowohl Seitenentwickler als auch Komponentenentwickler bei der Clientlokalisierung. Seitenentwickler lokalisieren normalerweise Folgendes:

Ausnahmemeldungen, die von ASP.NET-AJAX oder Komponentenbibliotheken basierend auf der Spracheinstellung des Browsers erzeugt werden.
Benutzeroberflächenelemente für Steuerelemente, z. B. Zeichenfolgen für die Text-Eigenschaft eines Button-Steuerelements.
Werte für öffentliche Eigenschaften von ASP.NET-AJAX-Serversteuerelementen.
Werte für Eigenschaften von Clientskriptobjekten und Komponenten, z. B. nicht-visuelle Komponenten, Verhalten und Steuerelemente.

Komponentenentwickler verwenden in der Regel die folgenden Lokalisierungsfeatures:

Lokalisieren von Ressourcen, auf die im Code von JavaScript-Bibliotheken (JS-Dateien) verwiesen wird. Die lokalisierten Ressourcen können in verschiedenen Installationen eingesetzt werden, ohne dass die Hauptassembly oder die Skriptbibliothek neu erstellt werden muss.
Offenlegen der lokalisierbaren Eigenschaften von Serversteuerelementen, die Eigenschaften von Clientobjekten zugeordnet sind.

Background

Die AJAX-Funktionalität in ASP.NET basiert auf dem ASP.NET 2.0-Lokalisierungsmodell. Sie bietet zusätzliche Unterstützung für lokalisierte Skriptdateien, die in einer Assembly eingebettet sind oder bei denen es sich um statische JS-Dateien auf einem Datenträger handelt.

Wenn Sie mit dem ASP.NET-Lokalisierungsmodell nicht vertraut sind, können Sie die folgenden Themen lesen, um entsprechende Informationen zu erhalten:

Lokalisieren von Clientskriptdateien und Skriptressourcen in Assemblys

Die ASP.NET-AJAX-Funktionalität nutzt für die Lokalisierung das .NET Framework-Ressourcenmodell. Dieses Modell verwendet eine sternenförmige Anordnung, um lokalisierte Ressourcen zu verpacken und bereitzustellen, die inkrementell aktualisiert werden können. Im Mittelpunkt der sternenförmigen Anordnung steht die Hauptassembly, die den nicht lokalisierten ausführbaren Code enthält. Sie enthält sowohl den .NET Framework-Servercode als auch den jeweiligen JavaScript-Code in JS-Dateien, die als Ressourcen in die Assembly eingebettet sind.

Die Hauptassembly kann außerdem die Ressourcen für einen einzelnen Kulturraum enthalten. Dieser wird als neutraler bzw. standardmäßiger Kulturraum bezeichnet. Diese neutrale Kultur stellt die Fallbackkultur der Anwendung dar. Sie wird verwendet, wenn keine Kultur angegeben wird oder wenn für die angegebene Kultur keine Ressourcen verfügbar sind.

Lokalisierte Ressourcen für eine Kultur werden normalerweise als Name/Wert-Paare in RESX-Dateien erstellt. (Diese RESX-Dateien können in RESOURCES-Dateien kompiliert werden.) Der Name ermöglicht den Zugriff auf die Informationen im Code, und der Wert ist ein lokalisierter (übersetzter) Begriff, ein Bild oder ein anderes Element dieses Namens. Beim Erstellen einer Assembly wird für die RESX-Datei ein Typ generiert, in dem die Namen als Felder offengelegt werden, die den programmgesteuerten Zugriff auf die Werte ermöglichen. (Sie geben den Namen dieses generierten Typs als Teil der Assemblyeigenschaften an. Dies ist weiter unten beschrieben.)

Im sternenförmigen Modell ist jeder Strahl mit einer Satellitenassembly verknüpft, die die Ressourcen für eine einzelne Kultur enthält. Die Satellitenassembly enthält keinen Code, der vom Server ausgeführt wird. Sie enthält nur den generierten Typ, der den programmgesteuerten Zugriff auf die Ressourcenwerte für diese Kultur bereitstellt.

Dieses Modell bietet folgende Features:

Sie können Ressourcen für neue Kulturen hinzufügen, indem Sie neue Satellitenassemblys bereitstellen, nachdem Sie bereits eine Anwendung bereitgestellt haben. Das Entwickeln von kulturspezifischen Ressourcen kann zusätzlichen Zeitaufwand erfordern. Bei diesem Modell haben Sie daher die Möglichkeit, zuerst die Hauptanwendung freizugeben und zusätzliche kulturspezifische Ressourcen später bereitzustellen.
Sie können die Satellitenassemblys einer Anwendung aktualisieren, ohne die Hauptassembly neu kompilieren zu müssen.
Eine Anwendung muss nur die Satellitenassembly für eine bestimmte Kultur laden, anstatt die Hauptassembly entladen und neu laden zu müssen. Damit verringern sich die benötigten Systemressourcen erheblich.

Weitere Informationen dazu, wie Sie Ressourcendateien für ASP.NET erstellen, finden Sie unter Gewusst wie: Erstellen von Ressourcendateien für ASP.NET-Websites (Visual Studio) und Lokalisieren von ASP.NET-Webseiten mithilfe von Ressourcen.

Weitere Informationen zur Verwendung des Resource File Generator-Tools (Resgen.exe) von .NET Framework finden Sie unter Resource File Generator (Resgen.exe). Dieses Tool konvertiert RESX- oder TXT-Dateien in binäre RESOURCES-Dateien, die mit Assemblys verknüpft werden können.

Organisieren von lokalisierten Haupt- und Satellitenassemblys

Sie können das sternenförmige Modell verwenden, wenn Sie eine Anwendung lokalisieren möchten, die JavaScript-Dateien (JS) enthält. Normalerweise organisieren Sie die Assembly so, wie Sie dies auch mit beliebigen lokalisierten ASP.NET-Anwendungen tun würden.

Um die JavaScript-Dateien für eine AJAX-fähige ASP.NET-Webanwendung zu verwalten, schreiben Sie JavaScript-Code, damit keine Zeichenfolgen oder anderen Elemente hartcodiert werden, die lokalisiert werden sollen. Stattdessen erhalten Sie an den Stellen, an denen der JavaScript-Code lokalisierte Werte verwenden muss, ein Feld des Typs, der aus der Ressourcendatei generiert wurde.

Die Hauptassembly enthält normalerweise die folgenden Elemente:

Die JavaScript-Dateien, die die Anwendungsaufgaben ausführen und die so geschrieben sind, dass sie anstelle von hartcodierten Werten die lokalisierten Ressourcen verwenden. Die Assembly kann bei Bedarf Debugversionen dieser JavaScript-Dateien enthalten.
Bei Bedarf können Sie die Ressourcen (RESX- oder RESOURCES-Datei) für eine einzelne neutrale Kultur verwenden, die als Fallbackkultur für die Anwendung dient.
Beliebige Debugversionen von Ressourcen der neutralen Kultur (optional). Die Debugversion einer Ressourcendatei enthält die zusätzlichen Name/Wert-Paare, die für die Debugversionen der JavaScript-Dateien erforderlich sind.

Eine Satellitenassembly enthält normalerweise die lokalisierten Ressourcen einer einzelnen Kultur für die ASP.NET-Anwendung. (Für die Fallbackkultur ist keine Satellitenassembly erforderlich.) Die Ressourcen für eine einzelne Kultur werden in einer separaten Ressourcendatei (RESX- oder RESOURCES-Datei) erstellt und dann in eine einzelne Satellitenassembly kompiliert.

Hinweis:
ASP.NET ermöglicht es Ihnen, eine benutzerdefinierte Benutzeroberflächenkultur und einen benutzerdefinierten Kulturnamen zu erstellen. Normalerweise basieren Kulturnamen jedoch auf einem ISO-Sprachcode aus zwei Buchstaben für die Sprache und zwei Großbuchstaben für das Land bzw. die Region. Beispiele: es-MX (Spanisch – Mexiko), es-CO (Spanisch – Kolumbien) und fr-CA (Französisch – Kanada). Eine vollständige Liste der Kulturnamen finden Sie in der Übersicht der System.Globalization.CultureInfo-Klasse.

ASP.NET ermöglicht es Ihnen, eine benutzerdefinierte Benutzeroberflächenkultur und einen benutzerdefinierten Kulturnamen zu erstellen. Normalerweise basieren Kulturnamen jedoch auf einem ISO-Sprachcode aus zwei Buchstaben für die Sprache und zwei Großbuchstaben für das Land bzw. die Region. Beispiele: es-MX (Spanisch – Mexiko), es-CO (Spanisch – Kolumbien) und fr-CA (Französisch – Kanada). Eine vollständige Liste der Kulturnamen finden Sie in der Übersicht der System.Globalization.CultureInfo-Klasse.

Namen für lokalisierte eingebettete Skriptdateien

Die folgende Namenskonvention wird für lokalisierte Skriptdateien empfohlen, die als Ressourcen eingebettet sind:

scriptname_noextension.[debug].[UI culture identifier].[resources|resx]

Die Debugversion eines Dateinamens enthält den Zusatz ".debug". Bei der Releaseversion ist dies nicht der Fall.

Die folgende Tabelle enthält einige Beispiele für diese Namenskonvention. Die Beispiele zeigen eine Releaseversion und eine Debugversion einer eingebetteten Skriptdatei. Sie zeigen auch die zugeordneten Release- und Debugversionen der Ressourcen für die Skriptdateien.

Sample.js
Eine Releaseversion der Skriptdatei einer neutralen Kultur, die in die Hauptassembly eingebettet ist.
Sample.debug.js
Eine Debugversion der Skriptdatei einer neutralen Kultur, die auch in die Hauptassembly eingebettet ist.
Sample.fr-FR.resources
Eine Releaseversion der Ressourcen, die der Skriptdatei Sample.js zugeordnet und für eine bestimmte Benutzeroberflächenkultur lokalisiert sind. Diese Ressourcen werden zu einem Teil der Satellitenassembly.
Sample.debug.fr-FR.resources
Debugspezifische Ressourcen, die der Skriptdatei Sample.debug.js zugeordnet und für eine bestimmte Benutzeroberflächenkultur lokalisiert sind. Diese Ressourcen werden zu einem Teil der Satellitenassembly, die auch die Datei Sample.fr-FR.resources enthält.

Diese Namenskonvention ist nicht zwingend für Skriptdateien, die in Assemblys eingebettet sind, und nicht für Ressourcendateien erforderlich. Dies liegt daran, dass die Zuordnung zwischen dem für die Ressource erzeugten Typ und dem Ressourcennamen mithilfe eines Assemblyattributs erreicht wird.

Lokalisieren von Debugskriptressourcen

Wenn Sie im Debugmodus arbeiten, kombiniert ASP.NET zur Laufzeit die Releaseversion der Ressourcen für Skriptdateien mit den verfügbaren zusätzlichen Debugressourcen. Anschließend wird die sich ergebende Kombination an den Browser gesendet. Aus diesem Grund müssen Sie beim Erstellen von Ressourcendateien für Debugversionen von Skripts nur die Name/Wert-Paare definieren, die nicht bereits in den Releaseskript-Ressourcendateien enthalten sind. Der Konvention nach verwenden Debugversionen von Skripts und von Skriptressourcen denselben Namen wie ihr Release-Gegenstück, wobei an den Skriptdateinamen lediglich ".debug" angehängt wird.

Angeben von Assemblyattributen für lokalisierte Skripts und lokalisierte Ressourcen, die Skripts zugeordnet sind

Um anzugeben, wie Ressourcendateien beim Erstellen einer Assembly verwaltet werden, fügen Sie Attribute in die AssemblyInfo-Datei ein (AssemblyInfo.vb bzw. AssemblyInfo.cs).

Hinweis:
In Visual Studio befindet sich die Datei AssemblyInfo.vb für Projekte, die in Visual Basic geschrieben sind, im Knoten Eigenes Projekt des Projektmappen-Explorers. Wenn im Knoten Eigenes Projekt keine Dateien angezeigt werden, klicken Sie im Menü Projekt auf Alle Dateien anzeigen. Bei Projekten, die in C# geschrieben sind, befindet sich die Datei AssemblyInfo.cs im Knoten Eigenschaften des Projektmappen-Explorers.

In Visual Studio befindet sich die Datei AssemblyInfo.vb für Projekte, die in Visual Basic geschrieben sind, im Knoten Eigenes Projekt des Projektmappen-Explorers. Wenn im Knoten Eigenes Projekt keine Dateien angezeigt werden, klicken Sie im Menü Projekt auf Alle Dateien anzeigen. Bei Projekten, die in C# geschrieben sind, befindet sich die Datei AssemblyInfo.cs im Knoten Eigenschaften des Projektmappen-Explorers.

In ASP.NET kennzeichnen Sie Ressourcen für die Anwendung mithilfe der WebResourceAttribute-Klasse. Um JavaScript-Dateien in eine Assembly einzubetten, verwenden Sie dieses Attribut zum Angeben der JS-Dateien als Webressource.

Um Ressourcendateien für die eingebetteten JavaScript-Dateien einzubinden, verwenden Sie die ScriptResourceAttribute-Klasse. Dieses Attribut identifiziert textbasierte Ressourcen speziell als Ressourcen für die JavaScript-Dateien.

Hinweis:
Sie können die ScriptResourceAttribute-Klasse verwenden, um nur textbasierte Ressourcen für JavaScript-Dateien zu identifizieren. Um eine lokalisierte (binäre) Bilddatei einer Kultur zuzuordnen, speichern Sie die dazugehörige URL als lokalisierte Ressource, die Skript auflösen und laden kann.

Das folgende Beispiel zeigt, wie Sie Assemblyattribute verwenden, um eingebettete Skripts und die dazugehörigen Skriptressourcen zu identifizieren.

' Indicates that neutral fallback resources are retrieved from 
' the main assembly named MainAssembly.
<assembly: NeutralResourcesLanguageAttribute("en-US",
  UltimateResourceFallbackLocation.MainAssembly)>

' Defines embedded scripts as Web resources.
<assembly:WebResource("Sample.js", "text/javascript")>
<assembly:WebResource("Sample.debug.js", "text/javascript")>

' Defines the script resources for the scripts and their types.
<assembly:ScriptResource("Sample.js", "Sample.resources", 
  "Sample.Res")>
<assembly:ScriptResource("Sample.debug.js", "Sample.debug.resources", 
  "Sample.Res")>

// Indicates that neutral fallback resources are retrieved from 
// the main assembly named MainAssembly.

[assembly: NeutralResourcesLanguageAttribute("en-US",
  UltimateResourceFallbackLocation.MainAssembly)]

// Defines embedded scripts as Web resources.
[assembly:WebResource("Sample.js", "text/javascript")]
[assembly:WebResource("Sample.debug.js", "text/javascript")]

// Defines the script resources for the scripts and their types.
[assembly:ScriptResource("Sample.js", "Sample.resources", 
  "Sample.Res")]
[assembly:ScriptResource("Sample.debug.js", "Sample.debug.resources", 
  "Sample.Res")]

In diesem Beispiel enthält eine Hauptassembly mit dem Namen MainAssembly eine eingebettete Releaseversion einer Clientskriptdatei, die den Namen Sample.js hat. Die Assembly enthält auch die entsprechende Debugversion mit dem Namen Sample.debug.js. Die JS-Dateien werden vom WebResourceAttribute-Attribut als Ressourcen identifiziert.

Das NeutralResourcesLanguageAttribute-Assemblyattribut wird verwendet, um die Hauptassembly als Fallbackkultur anzugeben. Weitere Informationen finden Sie unter Neutrale Ressourcensprachen für die Lokalisierung sowie in der Übersicht über die System.Resources.NeutralResourcesLanguageAttribute-Klasse.

Die von den Skriptdateien verwendeten Ressourcen werden mithilfe des ScriptResourceAttribute-Attributs definiert. Die Dateien Sample.resources und Sample.debug.resources enthalten jeweils Ressourcenwerte für die Datei Sample.js bzw. Sample.debug.js.

Für die Release- und die Debugversion der Skriptressourcen wird ein Typ mit dem Namen Sample.Res generiert. Dies ist der Typ, den der JavaScript-Code verwendet, um auf lokalisierte Werte zuzugreifen. Für den Release- und den Debugmodus erstellt der Buildprozess nur einen einzelnen Typ. Im Debugmodus werden die Ressourcen für die Releaseversion mit den zusätzlichen Ressourcen für die Debugversion kombiniert.

Weitere Informationen dazu, wie Sie Assemblyinformationsdateien und die Assemblymetadaten erstellen, die für Assemblys mit Versionsangaben erforderlich sind, finden Sie unter Gewusst wie: Erstellen von Assemblys mit Versionsangaben für vorkompilierte Websites.

Lokalisieren von statischen Skriptdateien und den dazugehörigen Ressourcen

Sie können eine Skriptbibliothek als lokalisierte statische Skriptdateien (JS-Dateien) auf Datenträger organisieren, anstatt die Skriptdateien in Assemblys einzubetten. Seitenentwickler können auf die Skriptdateien über die ScriptReferenceCollection-Klasse verweisen.

Im statischen Skriptdateimodell gibt es keine separaten RESX- oder RESOURCES-Dateien, die automatisch als Ressourcen für die JavaScript-Dateien verwaltet werden können. Stattdessen gibt es nur JS-Dateien, und zwar jeweils eine für jede Kombination aus Benutzeroberflächenkultur und Gebietsschema. Dabei stellt jede JS-Datei praktisch eine gebietsschemaspezifische Version des vollständigen JavaScript-Codes dar. Ein typisches Verfahren zum Verwalten von lokalisierten Skriptdateien in diesem Modell besteht darin, in jeder JS-Datei dieselbe JavaScript-Logik zu verwenden. Wie beim Modell mit Assemblyeinbettung auch, ruft der JavaScript-Code einen Typ auf, um lokalisierte Ressourcenwerte abzurufen. Der Unterschied besteht darin, dass Sie den Typ angeben müssen, der die lokalisierten Werte enthält. Der Typ wird nicht automatisch generiert. Die JS-Datei für die einzelnen Gebietsschemas kann z. B. sowohl den Anwendungscode als auch eine Klasse enthalten, die die Felder für die lokalisierten Werte definiert. In jeder JS-Datei enthält diese Klasse dabei Werte in einer anderen Sprache.

Hinweis:
Im statischen Skriptdateimodell kann der JavaScript-Code der Anwendung in den JS-Dateien asynchron zum Code in einer eingebetteten JavaScript-Datei werden. Das liegt daran, dass jede Skriptdatei eine Kopie des Codes enthält. Um Versionssteuerungsprobleme aufgrund von doppelt vorhandenem Code zu vermeiden, können Sie eine einzelne Kopie der JavaScript-Quelldateien verwenden und lokalisierte Ressourcentypen in separaten Dateien erstellen. Sie können dann während des Buildprozesses der Anwendung die endgültigen kombinierten Dateien generieren.

Im statischen Skriptdateimodell kann der JavaScript-Code der Anwendung in den JS-Dateien asynchron zum Code in einer eingebetteten JavaScript-Datei werden. Das liegt daran, dass jede Skriptdatei eine Kopie des Codes enthält. Um Versionssteuerungsprobleme aufgrund von doppelt vorhandenem Code zu vermeiden, können Sie eine einzelne Kopie der JavaScript-Quelldateien verwenden und lokalisierte Ressourcentypen in separaten Dateien erstellen. Sie können dann während des Buildprozesses der Anwendung die endgültigen kombinierten Dateien generieren.

Lokalisierte statische Skriptdateien werden ihrer Benutzeroberflächenkultur zugeordnet, indem Sie den Namen der Benutzeroberflächenkultur in den Dateinamen einbinden, wie dies auch bei eingebetteten Ressourcen in einer Assembly der Fall ist. Eine eingebettete Clientskriptdatei, die kulturell neutrale Daten für Französisch enthält, erhält z. B. den Namen Sample.fr.js, und eine kulturspezifische JavaScript-Ressource für Französisch (Kanada) erhält den Namen Sample.fr-CA.js.

Lokalisierte Debugskripts im statischen Skriptdateimodell

Im statischen Skriptdateimodell werden lokalisierte Ressourcen, auf die ein Skript verweist, normalerweise als Typ in einer einzelnen JS-Datei definiert. Eine Debugversion einer Skriptdatei wird auf dieselbe Weise organisiert, wobei die lokalisierten Releaseressourcen und die zusätzlichen Debugressourcen als Typ in einer einzelnen Datei definiert sind. Die Debugversionen von Skripts verwenden denselben Namen wie die entsprechende Releaseversion, jedoch mit dem Zusatz ".debug".

Verwenden von ScriptManager zum Verwalten von Skripts

Sie können das ScriptManager-Steuerelement zum Verwalten von statischen Skripts verwenden, die sich in einem zentralen Verzeichnis auf einem Datenträger befinden. Legen Sie dazu alle Versionen der Skriptdateien in einem Ordner mit Release- und Debugversionen aller lokalisierten Dateien ab. Das folgende Beispiel zeigt das Layout einer Verzeichnisstruktur für eine statische Skriptdateibibliothek:

SampleNamespace/

1.0.0.0/

Sample.js

Sample.debug.js

Sample.de-DE.js

Sample.debug.de-DE.js

Sample.fr-FR.js

Sample.debug.fr-FR.js

In diesem Beispiel befinden sich alle Skriptdateien in einem Ordner, der unter Verwendung der Skriptbibliothekversion (1.0.0.0) benannt wird. Dieser versionsspezifische Ordner ist wiederum in einem Ordner enthalten, der nach dem Namespace der Bibliothek benannt ist. Das Organisieren einer Skriptbibliothek innerhalb von Namespace- und Versionsordnern ist ein Beitrag zur Versionssteuerung für Ihre Bibliothek. Außerdem lassen sich dadurch Skriptnamenskonflikte zwischen Bibliotheken vermeiden. Ferner können die Consumer der Bibliothek erkennen, zu welcher Bibliothek und Bibliotheksversion die Dateien gehören.

Grundlegendes zur Rolle des ScriptManager-Steuerelements bei der Lokalisierung

Das ScriptManager-Steuerelement stellt die folgende Funktionalität für die Verwendung lokalisierter Skripts und Skriptressourcen bereit:

Sie können definieren, welche Benutzeroberflächenkulturen unterstützt werden, darunter auch benutzerdefinierte Benutzeroberflächenkulturen.
Interpretiert das kulturspezifische Assemblyattribut und erkennt die Benutzeroberflächenkultur des Browsers automatisch (falls vorhanden). Anschließend werden die lokalisierten Skripts bzw. die Fallbackskripts und die dazugehörigen Ressourcen aus der Assembly ausgelesen. Im Debugmodus wird versucht, eine Skriptressource zu laden, die sowohl den entsprechenden Namen der Benutzeroberflächenkultur als auch die Zeichenfolge ".debug" im Dateinamen enthält, z. B. Sample.debug.fr-FR.resources.
Generiert URLs, die auf die entsprechenden Skripts und ihre lokalisierten Ressourcen zeigen. Um die Sicherheit zu erhöhen, werden URLs verschlüsselt.
Bestimmt, ob ein Skript oder eine Skriptressource komprimiert wird, indem ein Parameter in der generierten URL überprüft wird.
Fügt der Assembly einen Zeitstempel mit eingebetteten Skripts hinzu, damit der Browser die Skripts nicht unendlich lange zwischenspeichert.

Weitere Informationen finden Sie in der Übersicht über die ScriptManager-Klasse.

Das folgende Beispiel zeigt einen Teil einer Webseite, die das ScriptManager-Steuerelement zum Registrieren eines Clientsteuerelements verwendet, das in einer Assembly angeordnet ist. Sie registrieren das eingebettete Script, indem Sie die Assembly-Eigenschaft und die Name-Eigenschaft verwenden.

<%@ Register TagPrefix="Samples" Namespace="DemoControls" 
  Assembly=" SampleAssembly" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head >
  <title>ScriptReference</title>
</head>
<body>
  <form id="form1" >
    <div>
      <asp:ScriptManager ID="ScriptManager1" >
        <Scripts>
          <asp:ScriptReference Assembly="SampleAssembly"
              Name="DemoControls.SampleControl.js" />
        </Scripts>
      </asp:ScriptManager>

      <!-- Additional markup here. -->

    </div>
  </form>
</body>

Codebeispiele

Die folgenden Abschnitte enthalten Codebeispiele, die zeigen, wie Sie mit JavaScript-Dateien und Ressourcen arbeiten.

Gewusst-wie-Themen und Themen mit exemplarischen Vorgehensweisen

Klassenreferenz

In der folgenden Tabelle sind wesentliche Klassen aufgeführt, die zum Lokalisieren von Komponentenbibliotheken verwendet werden.

ScriptManager
Verwaltet AJAX-Komponenten, Teilrendering von Seiten, Clientanforderungen und Serverantworten auf ASP.NET-Serverseiten.
ScriptReference
Stellt APIs zum Registrieren von JavaScript-Dateien zur Verwendung auf einer Webseite bereit. Die Dateien sind dabei entweder in eine Assembly eingebettet oder liegen auf einem Datenträger vor.
ScriptReferenceCollection
Ermöglicht den Zugriff auf ScriptReference-Objekte, die Clientskriptdateien darstellen.

Siehe auch

Share via