Teilen über

CREATE ASSEMBLY (Transact-SQL)

  • Artikel

Gilt für: SQL Server Azure SQL Managed Instance

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.

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 und ein gültiger Bezeichner sein.

AUTHORIZATION owner_name

Gibt den Namen eines Benutzers oder einer Rolle als Besitzer der Assembly an. owner_name muss entweder der Name einer Rolle sein, deren Mitglied der aktuelle Benutzer ist, oder der aktuelle Benutzer muss über die Berechtigung für owner_name verfügenIMPERSONATE. Wird kein Wert angegeben, wird der aktuelle Benutzer zum Besitzer.

<client_assembly_specifier>

Gibt den lokalen Pfad oder den Netzwerkspeicherort an, unter dem die Assembly gespeichert ist, die hochgeladen 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. CREATE ASSEMBLY unterstützt das Laden von Multimodule-Assemblys nicht. SQL Server sucht auch nach abhängigen Assemblys dieser Assembly an demselben Speicherort und lädt sie mit demselben Besitzer wie die Assembly auf Stammebene hoch. Wenn diese abhängigen Assemblys nicht gefunden werden und sie nicht bereits in der aktuellen Datenbank geladen wurden, CREATE ASSEMBLY schlägt ein Fehler fehl. 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.

Wichtig

Azure SQL-Datenbank und Azure SQL verwaltete Instanz das Erstellen einer Assembly aus einer Datei nicht unterstützen.

<client_assembly_specifier> kann nicht angegeben werden, wenn der angemeldete Benutzer identitätswechselt.

<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. Alle Werte, die nicht Abhängigkeiten der Stammassembly entsprechen, werden ignoriert.

Hinweis

Diese Option ist in einer enthaltenen Datenbank nicht verfügbar.

varbinary_literal

Ein varbinäres Literal.

varbinary_expression

Ein Ausdruck des Typs varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Gibt eine Reihe von Codezugriffsberechtigungen an, die der Assembly gewährt werden, wenn auf SQL Server zugegriffen wird. Wenn nicht angegeben, SAFE wird sie als Standard angewendet.

Die PERMISSION_SET Option ist von der Serverkonfiguration betroffen: clr strict security option. Wenn clr strict security aktiviert ist, werden alle Assemblys als UNSAFE behandelt.

Wir empfehlen die Verwendung der SAFE. SAFE ist der restriktivste Berechtigungssatz. Code, der von einer Assembly mit SAFE Berechtigungen ausgeführt wird, kann nicht auf externe Systemressourcen wie Dateien, Das Netzwerk, Umgebungsvariablen oder die Registrierung zugreifen.

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

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

SAFE ist die empfohlene Berechtigungseinstellung für Assemblys, die Berechnungs- und Datenverwaltungsaufgaben ausführen, ohne auf Ressourcen außerhalb einer Instanz von SQL Server zuzugreifen.

Hinweis

Die EXTERNAL_ACCESS Optionen sind UNSAFE in einer enthaltenen Datenbank nicht verfügbar.

Wir empfehlen die Verwendung EXTERNAL_ACCESS für Assemblys, die auf Ressourcen außerhalb einer Sql Server-Instanz zugreifen. EXTERNAL_ACCESS Assemblys umfassen die Zuverlässigkeits- und Skalierbarkeitsschutz von SAFE Assemblys, sind jedoch aus Sicherheitsgründen ähnlich UNSAFE wie Assemblys. Code in EXTERNAL_ACCESS Assemblys wird standardmäßig unter dem SQL Server-Dienstkonto ausgeführt und greift auf externe Ressourcen unter diesem Konto zu, es sei denn, der Code imitiert den Aufrufer explizit. Daher sollte die Berechtigung zum Erstellen von EXTERNAL_ACCESS Assemblys nur für Anmeldungen gewährt werden, die vertrauenswürdig sind, um Code unter dem SQL Server-Dienstkonto auszuführen. Weitere Informationen finden Sie unter Sicherheit der CLR-Integration.

Durch Angeben UNSAFE kann der Code in der Assembly die vollständige Freiheit zum Ausführen von Vorgängen im SQL Server-Prozessbereich ermöglichen, die möglicherweise die Stabilität von SQL Server beeinträchtigen können. UNSAFE Assemblys können das Sicherheitssystem entweder von SQL Server oder der Common Language Runtime möglicherweise subvertieren. UNSAFE Berechtigungen sollten nur für hochgradig vertrauenswürdige Assemblys erteilt werden. Nur Mitglieder der festen Serverrolle "sysadmin " können Assemblys erstellen und ändern UNSAFE .

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

Codezugriffssicherheit wird nicht mehr unterstützt

CLR verwendet die Codezugriffssicherheit (Code Access Security, CAS) im .NET Framework, die nicht länger als Sicherheitsbegrenzung unterstützt wird. Eine CLR-Assembly, die erstellt wurde, PERMISSION_SET = SAFE kann möglicherweise auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und sysadmin-Berechtigungen erwerben. In SQL Server 2017 (14.x) und höheren Versionen verbessert die sp_configure Option clr strict security die Sicherheit von CLR-Assemblys. clr strict security ist standardmäßig aktiviert und behandelt SAFE- und EXTERNAL_ACCESS-Assemblys so, als wären Sie als UNSAFE gekennzeichnet. Die clr strict security Option kann aus Gründen der Abwärtskompatibilität deaktiviert werden, wird jedoch nicht empfohlen.

Es wird empfohlen, alle Assemblys anhand eines Zertifikats oder asymmetrischen Schlüssels mit einer entsprechenden Anmeldung zu signieren, die in der master Datenbank berechtigungen erteilt UNSAFE ASSEMBLY wurde. SQL Server-Administratoren können auch Assemblys einer Liste von Assemblys hinzufügen, der die Datenbank-Engine vertrauen sollte. Weitere Informationen finden Sie unter sys.sp_add_trusted_assembly.

Hinweise

CREATE ASSEMBLY lädt eine Assembly hoch, die zuvor als .dll Datei aus verwaltetem Code kompiliert wurde, um sie in einer Instanz von SQL Server zu verwenden.

Falls die Option PERMISSION_SET aktiviert ist, wir sie in den Anweisungen CREATE ASSEMBLY und ALTER ASSEMBLY zur Laufzeit ignoriert, jedoch werden die PERMISSION_SET-Optionen in den Metadaten beibehalten. Durch Ignorieren der Option wird das Unterbrechen vorhandener Codeanweisungen minimiert.

SQL Server lässt die Registrierung verschiedener Versionen einer Assembly mit demselben Namen, derselben Kultur und einem öffentlichen Schlüssel nicht zu.

Beim Versuch, auf die in <client_assembly_specifier>der Assembly angegebene Assembly zuzugreifen, stellt SQL Server den Sicherheitskontext der aktuellen Windows-Anmeldung imitiert. Wenn <client_assembly_specifier> ein Netzwerkspeicherort (UNC-Pfad) angegeben wird, wird der Identitätswechsel der aktuellen Anmeldung aufgrund von Delegierungseinschränkungen nicht an den Netzwerkspeicherort weitergeleitet. In diesem Fall erfolgt der Zugriff mithilfe des Sicherheitskontexts des SQL Server-Dienstkontos. Weitere Informationen finden Sie unter Anmeldeinformationen (Datenbank-Engine).

Neben der mit assembly_name angegebenen Stammassembly versucht SQL Server, alle Assemblys hochzuladen, auf die die Stammassembly, die hochgeladen wird, verweist. Wenn eine referenzierte Assembly bereits aufgrund einer früheren CREATE ASSEMBLY Anweisung in die Datenbank hochgeladen wird, wird diese Assembly nicht hochgeladen, ist aber für die Stammassembly verfügbar. Wenn eine abhängige Assembly zuvor nicht hochgeladen wurde, aber SQL Server seine Manifestdatei nicht im Quellverzeichnis finden kann, CREATE ASSEMBLY gibt einen Fehler zurück.

Wenn abhängige Assemblys, auf die von der Stammassembly verwiesen wird, noch nicht in der Datenbank vorhanden sind und implizit zusammen mit der Stammassembly geladen werden, verfügen sie über die gleiche Berechtigung 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 hochgeladen werden.

Assemblyüberprüfung

SQL Server überprüft die von der CREATE ASSEMBLY Anweisung hochgeladenen Assemblybinärdateien, um die folgenden Prüfungen zu gewährleisten:

  • 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 Gruppe von Systemassemblys, auf die verwiesen wird, ist eine der folgenden unterstützten Assemblys in SQL Server: Microsoft.VisualBasic.dll, , , mscorlib.dll, System.Data.dll, System.Core.dllCustomMarshallers.dllSystem.Xml.dllSystem.dllSystem.Security.dllSystem.Web.Services.dllMicrosoft.VisualC.dllSystem.Data.SqlXml.dllund .System.Xml.Linq.dll Auf andere Systemassemblys kann verwiesen werden, aber sie müssen explizit in der Datenbank registriert sein.

  • Für assemblys created by using SAFE or EXTERNAL ACCESS permission sets:

    • 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 Datenmmber in ihren Klassen enthalten, es sei denn, sie sind als schreibgeschützt gekennzeichnet.

    • Die Klassen in der Assembly können keine Finalizermethoden enthalten.

    • Die Klassen oder Methoden der Assembly sollten nur mit zulässigen Codeattributen versehen werden. Weitere Informationen finden Sie unter CLR-Integration: benutzerdefinierte Attribute für CLR-Routinen.

Neben den vorherigen Prüfungen, die bei CREATE ASSEMBLY der Ausführung ausgeführt werden, gibt es zusätzliche Überprüfungen, die zur Ausführungszeit des Codes in der Assembly ausgeführt werden:

  • Das Aufrufen bestimmter .NET Framework-APIs, die eine bestimmte Codezugriffsberechtigung erfordern, schlägt möglicherweise fehl, wenn der Berechtigungssatz der Assembly diese Berechtigung nicht enthält.

  • Für SAFE und EXTERNAL_ACCESS Assemblys schlägt jeder Versuch, .NET Framework-APIs aufzurufen, die mit bestimmten HostProtectionAttributes versehen sind, fehl.

Weitere Informationen finden Sie unter Entwerfen von Assemblys.

Berechtigungen

Erfordert die CREATE ASSEMBLY-Berechtigung.

Wenn PERMISSION_SET = EXTERNAL_ACCESS angegeben, ist die Berechtigung auf dem Server erforderlich EXTERNAL ACCESS ASSEMBLY . Wenn PERMISSION_SET = UNSAFE angegeben, ist die Berechtigung auf dem Server erforderlich UNSAFE ASSEMBLY .

Der Benutzer muss der Besitzer von Assemblys sein, auf die von der Assembly verwiesen wird, die hochgeladen werden soll, falls die Assemblys bereits in der Datenbank vorhanden sind. Um eine Assembly mithilfe eines Dateipfads hochzuladen, muss der aktuelle Benutzer einen Anmeldenamen mit Windows-Authentifizierung haben oder ein Mitglied der festen Serverrolle sysadmin sein. Die Windows-Anmeldung des ausgeführten CREATE ASSEMBLY Benutzers muss über Leseberechtigungen für die Freigabe und die Dateien verfügen, die in der Anweisung geladen werden.

Berechtigungen mit CLR Strict Security

Die folgenden Berechtigungen werden zum Erstellen einer CLR-Assembly benötigt, wenn CLR strict security aktiviert ist:

  • Der Benutzer muss über die CREATE ASSEMBLY-Berechtigung verfügen.
  • Eine der folgenden Bedingungen muss ebenfalls erfüllt sein:
    • Die Assembly ist mit einem Zertifikat oder asymmetrischen Schlüssel signiert, der über einen entsprechenden Anmeldenamen mit der UNSAFE ASSEMBLY-Berechtigung auf dem Server verfügt. Es wird empfohlen, die Assembly zu signieren.
    • Die TRUSTWORTHY-Eigenschaft der Datenbank ist auf ON festgelegt, und der Besitzer der Datenbank ist ein Anmeldename, der über UNSAFE ASSEMBLY-Berechtigungen auf dem Server verfügt. Von der Verwendung dieser Option wird abgeraten.

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

Beispiele

A. Erstellen einer Assembly aus einer DLL

Im folgenden Beispiel wird davon ausgegangen, dass die SQL Server-Datenbank-Engine Beispiele am Standardspeicherort des lokalen Computers installiert sind und die HelloWorld.csproj Beispielanwendung kompiliert wird. Weitere Informationen finden Sie unter Beispiel „Hello World“.

CREATE ASSEMBLY HelloWorld
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Wichtig

Azure SQL-Datenbank unterstützt das Erstellen einer Assembly aus einer Datei nicht.

B. Erstellen einer Assembly aus Assemblybits

Ersetzen Sie die Beispielbits (die nicht vollständig oder gültig sind) durch Ihre Assemblybits.

CREATE ASSEMBLY HelloWorld
    FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;

Zugehöriger Inhalt