CREATE ASSEMBLY (Transact-SQL)

  • Artikel

Erstellt ein verwaltetes Anwendungsmodul, das Klassenmetadaten und verwalteten Code als Objekt in einer Instanz von SQL Server enthält. Durch Verweisen auf dieses Modul können CLR-Funktionen (Common Language Runtime), gespeicherte Prozeduren, Trigger, benutzerdefinierte Aggregate und benutzerdefinierte Typen in der Datenbank erstellt werden.

Themenlink (Symbol)Transact-SQL-Syntaxkonventionen

Syntax

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ ,...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]

<client_assembly_specifier> :: =
        '[\\computer_name\]share_name\[path\]manifest_file_name'
  | '[local_path\]manifest_file_name'

<assembly_bits> :: =
{ varbinary_literal | varbinary_expression }

Argumente

  • assembly_name
    Der Name der Assembly. Dieser Name muss innerhalb der Datenbank eindeutig sein und ein gültiger Bezeichner sein.
  • AUTHORIZATION owner_name
    Gibt den Namen eines Benutzers oder einer Rolle als Besitzer der Assembly an. owner_namemuss ein Name einer Rolle sein, bei der der aktuelle Benutzer Mitglied ist, oder der aktuelle Benutzer benötigt die IMPERSONATE-Berechtigung für owner_name. Wird kein Wert angegeben, wird der aktuelle Benutzer zum Besitzer.

  • <client_assembly_specifier>
    Gibt den lokalen Pfad oder den Netzwerkspeicherort an, in dem die Assembly gespeichert ist, die geuploadet wird. Außerdem wird damit der Manifestdateiname angegeben, der der Assembly entspricht. <client_assembly_specifier> kann als feste Zeichenfolge oder als zu einer festen Zeichenfolge ausgewerteter Ausdruck mit Variablen ausgedrückt werden. Das Laden von Assemblys mit mehreren Modulen wird von CREATE ASSEMBLY nicht unterstützt. SQL Server sucht auch nach abhängigen Assemblys dieser Assembly im selben Speicherort und uploadet sie mit demselben Besitzer wie die Assembly auf Stammebene. Wenn keine abhängigen Assemblys gefunden werden und diese noch nicht in der aktuellen Datenbank geladen sind, wird für CREATE ASSEMBLY ein Fehler gemeldet. Wenn die abhängigen Assemblys bereits in der aktuellen Datenbank geladen sind, muss der Besitzer dieser Assemblys mit dem Besitzer der neu erstellten Assembly identisch sein.

    <client_assembly_specifier> kann nicht angegeben werden, wenn für den angemeldeten Benutzer ein Identitätswechsel ausgeführt wird.

  • <assembly_bits>
    Die Liste der Binärwerte, aus denen die Assembly und die abhängigen Assemblys bestehen. Der erste Wert in der Liste wird als Assembly auf Stammebene betrachtet. Die Werte, die den abhängigen Assemblys entsprechen, können in einer beliebigen Reihenfolge bereitgestellt werden. Werte, die nicht Abhängigkeiten der Stammassembly entsprechen, werden ignoriert.
  • varbinary_literal
    Ein Literal vom Typ varbinary.
  • varbinary_expression
    Ein Ausdruck vom Typ varbinary.

  • PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }
    Gibt Codezugriffsberechtigungen an, die der Assembly erteilt werden, wenn SQL Server darauf zugreift. Wird kein Wert angegeben, wird SAFE als Standardwert verwendet.

    Es wird empfohlen, SAFE zu verwenden. SAFE ist der restriktivste Berechtigungssatz. Code, der von einer Assembly mit SAFE-Berechtigungen ausgeführt wird, hat keinen Zugriff auf externe Systemressourcen wie z. B. Dateien, das Netzwerk, Umgebungsvariablen oder die Registrierung.

    EXTERNAL_ACCESS ermöglicht Assemblys den Zugriff auf bestimmte externe Systemressourcen wie z. B. Dateien, Netzwerke, Umgebungsvariablen und die Registrierung.

    UNSAFE ermöglicht Assemblys den uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb einer Instanz von SQL Server. Code, der innerhalb einer UNSAFE-Assembly ausgeführt wird, kann nicht verwalteten Code aufrufen.

    ms189524.security(de-de,SQL.90).gifSicherheitshinweis:
    SAFE ist die empfohlene Berechtigungseinstellung für Assemblys, die Berechnungs- und Datenverwaltungstasks ausführen, ohne auf Ressourcen außerhalb einer Instanz von SQL Server zuzugreifen. Wir empfehlen die Verwendung von EXTERNAL_ACCESS für Assemblys, die auf Ressourcen außerhalb einer Instanz von SQL Server zugreifen. EXTERNAL_ACCESS-Assemblys beinhalten die Zuverlässigkeit und Skalierbarkeit von SAFE-Assemblys, aber aus Sicht der Sicherheit sind sie mit UNSAFE-Assemblys vergleichbar. Code in EXTERNAL_ACCESS-Assemblys wird nämlich standardmäßig unter dem SQL Server-Dienstkonto ausgeführt, und der Code greift auf externe Ressourcen unter diesem Konto zu, außer der Code nimmt explizit die Identität des Aufrufers an. Deshalb sollte die Berechtigung zum Erstellen von EXTERNAL_ACCESS-Assemblys nur vertrauenswürdigen Anmeldenamen erteilt werden, die Code unter dem SQL Server-Dienstkonto ausführen. Weitere Informationen zum Identitätswechsel finden Sie unter CLR Integration Security. Wenn Sie UNSAFE angeben, kann der Code in der Assembly jegliche Vorgänge im SQL Server-Prozessraum ausführen, die die Zuverlässigkeit von SQL Server gefährden können. UNSAFE-Assemblys können außerdem das Sicherheitssystem von SQL Server oder CLR (Common Language Runtime) untergraben. UNSAFE-Berechtigungen sollten nur sehr vertrauenswürdigen Assemblys erteilt werden. Nur Mitglieder der festen Serverrolle sysadmin können UNSAFE-Assemblys erstellen und ändern.

    Weitere Informationen zu Assemblyberechtigungssätzen finden Sie unter Entwerfen von Assemblys.

Hinweise

CREATE ASSEMBLY uploadet eine Assembly, die zuvor als DLL-Datei von verwaltetem Code zum Verwenden in einer Instanz von SQL Server kompiliert wurde.

In SQL Server ist es nicht zulässig, verschiedene Versionen einer Assembly mit demselben Namen, öffentlichen Schlüssel oder derselben Kultur zu registrieren.

Beim Versuch, auf die in <client_assembly_specifier> angegebene Assembly zuzugreifen, nimmt SQL Server den Sicherheitskontext des aktuellen Windows-Anmeldenamens an. Falls <client_assembly_specifier> einen Netzwerkspeicherort (UNC-Pfad) angibt, wird der Identitätswechsel des aktuellen Anmeldenamens aufgrund von Delegierungsbeschränkungen nicht auf den neuen Netzwerkspeicherort übertragen. In diesem Fall erfolgt der Zugriff mithilfe des Sicherheitskontextes des SQL Server-Dienstkontos. Weitere Informationen finden Sie unter Anmeldeinformationen.

Neben der mit assembly_name angegebenen Stammassembly versucht SQL Server Assemblys zu uploaden, auf die die Stammassembly, die geuploadet wird, verweist. Falls eine Assembly, auf die verwiesen wird, aufgrund einer früheren CREATE ASSEMBLY-Anweisung bereits in die Datenbank geuploadet wurde, wird diese Assembly nicht geuploadet, ist aber für die Stammassembly verfügbar. Falls eine abhängige Assembly nicht zuvor geuploadet wurde, aber SQL Server die Manifestdatei nicht im Quellverzeichnis findet, gibt CREATE ASSEMBLY einen Fehler zurück.

Wenn abhängige Assemblys, auf die von der Stammassembly verwiesen wird, nicht bereits in der Datenbank vorhanden sind und implizit zusammen mit der Stammassembly geladen werden, haben sie die gleichen Berechtigungen wie die Assembly auf Stammebene. Wenn die abhängigen Assemblys mit einem anderen Berechtigungssatz als die Assembly auf Stammebene erstellt werden müssen, müssen sie vor der Assembly auf Stammebene explizit mit dem entsprechenden Berechtigungssatz geuploadet werden.

Assemblyüberprüfung

SQL Server überprüft die Binärdaten der Assemblys, die mithilfe der CREATE ASSEMBLY-Anweisung geuploadet wurden, um folgende Bedingungen sicherzustellen:

  • Die Assemblybinärdatei ist wohlgeformt und enthält gültige Metadaten und Codesegmente, und die Codesegmente weisen gültige MSIL-Anweisungen (Microsoft Intermediate Language) auf.
  • Die Systemassemblys, auf die verwiesen wird, entsprechen einer der folgenden unterstützten Assemblys in SQL Server: Microsoft.Visualbasic.dll, Mscorlib.dll, System.Data.dll, System.dll, System.Xml.dll, Microsoft.Visualc.dll, Custommarshallers.dll, System.Security.dll, System.Web.Services.dll und System.Data.SqlXml.dll. Auf andere Systemassemblys kann verwiesen werden, aber sie müssen explizit in der Datenbank registriert sein.
  • Für Assemblys, die mit den SAFE- oder EXTERNAL ACCESS-Berechtigungssätzen erstellt werden:
    • Der Assemblycode sollte typsicher sein. Die Typsicherheit wird durch Ausführen der CLR-Überprüfung (Common Language Runtime) für die Assembly erreicht.
    • Die Assembly sollte keine statischen Datenelemente in den Klassen enthalten, außer sie sind als schreibgeschützt gekennzeichnet.
    • Die Klassen in der Assembly dürfen keine Finalizer-Methoden enthalten.
    • Die Klassen oder Methoden der Assembly sollten nur mit zulässigen Codeattributen versehen werden. Weitere Informationen finden Sie unter Custom Attributes for CLR Routines.

Neben den vorherigen Überprüfungen, die zusammen mit CREATE ASSEMBLY ausgeführt werden, werden zur Ausführungszeit des Codes in der Assembly zusätzliche Überprüfungen vorgenommen:

  • Beim Aufrufen bestimmter Microsoft .NET Framework-APIs, die eine bestimmte Codezugriffsberechtigung erfordern, wird möglicherweise ein Fehler gemeldet, wenn diese Berechtigung im Berechtigungssatz der Assembly nicht enthalten ist.
  • Für SAFE- und EXTERNAL_ACCESS-Assemblys wird für jeden Versuch, .NET Framework-APIs aufzurufen, die mit bestimmten HostProtectionAttributes versehen sind, ein Fehler gemeldet.

Weitere Informationen finden Sie unter Entwerfen von Assemblys.

Berechtigungen

Erfordert die CREATE ASSEMBLY-Berechtigung.

Falls PERMISSION_SET = EXTERNAL_ACCESS angegeben ist, benötigt der SQL Server-Anmeldename die EXTERNAL ACCESS ASSEMBLY-Berechtigung auf dem Server. Falls PERMISSION_SET = UNSAFE angegeben ist, ist die Mitgliedschaft in der festen Serverrolle sysadmin erforderlich.

Der Benutzer muss der Besitzer von Assemblys sein, auf die von der Assembly verwiesen wird, die geuploadet werden soll, falls die Assemblys bereits in der Datenbank vorhanden sind. Um eine Assembly mithilfe eines Dateipfades zu uploaden, muss der aktuelle Benutzer einen Anmeldenamen mit Windows-Authentifizierung haben oder ein Mitglied der festen Serverrolle sysadmin sein. Der Windows-Anmeldename des Benutzers, der CREATE ASSEMBLY ausführt, benötigt die Leseberechtigung für die Freigabe und für die Dateien, die in die Anweisung geladen werden.

Weitere Informationen zu Assemblyberechtigungssätzen finden Sie unter Entwerfen von Assemblys.

Beispiele

Im folgenden Beispiel wird davon ausgegangen, dass die SQL Server-Datenbankmodul-Beispiele im Standardspeicherort des lokalen Computers gespeichert sind und dass die Beispielanwendung HelloWorld.csproj kompiliert ist. Weitere Informationen finden Sie unter Hello World-Beispiel.

DECLARE @SamplesPath nvarchar(1024)
SELECT @SamplesPath = REPLACE(physical_name, 
    'Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf', 
    'Microsoft SQL Server\90\Samples\Engine\Programmability\CLR\') 
FROM master.sys.database_files 
WHERE name = 'master';
CREATE ASSEMBLY HelloWorld 
FROM @SamplesPath + 'HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Siehe auch

Verweis

ALTER ASSEMBLY (Transact-SQL)
DROP ASSEMBLY (Transact-SQL)
CREATE FUNCTION (Transact-SQL)
CREATE PROCEDURE (Transact-SQL)
CREATE TRIGGER (Transact-SQL)
CREATE TYPE (Transact-SQL)
CREATE AGGREGATE (Transact-SQL)
EVENTDATA (Transact-SQL)

Andere Ressourcen

Beispiele für die CLR-Programmierbarkeit

Hilfe und Informationen

Informationsquellen für SQL Server 2005