CREATE ASSEMBLY (Transact-SQL)
Gilt für:
SQL ServerAzure 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.
Warnung
CLR verwendet die Codezugriffssicherheit (Code Access Security, CAS) im .NET Framework, die nicht länger als Sicherheitsbegrenzung unterstützt wird. Eine CLR-Assembly, die mit PERMISSION_SET = SAFE erstellt wurde, kann womöglich auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und sysadmin-Privilegien erwerben. Ab SQL Server 2017 (14.x) wird eine sp_configure-Option mit der Bezeichnung clr strict security eingeführt, um die Sicherheit von CLR-Assemblys zu erhöhen. clr strict security ist standardmäßig aktiviert und behandelt SAFE- und EXTERNAL_ACCESS-Assemblys so, als wären Sie als UNSAFE gekennzeichnet. Die Option clr strict security kann für die Abwärtskompatibilität deaktiviert werden, es wird jedoch nicht empfohlen. Microsoft empfiehlt, dass alle Assemblys durch ein Zertifikat oder einen asymmetrischen Schlüssel mit einem entsprechenden Anmeldenamen signiert werden, dem UNSAFE ASSEMBLY-Berechtigung für die Masterdatenbank gewährt wurde. Weitere Informationen finden Sie unter CLR Strict Security.
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 der Name einer Rolle sein, deren Mitglied der aktuelle Benutzer 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, 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. Das Laden von Assemblys mit mehreren Modulen wird von CREATE ASSEMBLY nicht unterstützt. 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 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.
Wichtig
Azure SQL-Datenbank & Azure SQL verwaltete Instanz unterstützen das Erstellen einer Assembly aus einer Datei nicht.
<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.
Hinweis
Diese Option ist in einer enthaltenen Datenbank nicht verfügbar.
varbinary_literal
Ist ein varbinary-Literal.
varbinary_expression
Ist ein Ausdruck vom Typ varbinary.
PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }
Wichtig
Die Option PERMISSION_SET wird von der Option clr strict security beeinflusst, was in der Warnung beschrieben wird. Wenn clr strict security aktiviert ist, werden alle Assemblys als UNSAFE behandelt.
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.
Hinweis
Diese Option ist in einer enthaltenen Datenbank nicht verfügbar.
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.
Hinweis
Diese Option ist in einer enthaltenen Datenbank nicht verfügbar.
Wichtig
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 finden Sie unter Sicherheit der CLR-Integration.
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 potenziell das Sicherheitssystem von SQL Server oder der CLR unterlaufen. 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 Assemblyberechtigungen finden Sie unter Entwerfen von Assemblys.
Bemerkungen
CREATE ASSEMBLY lädt eine Assembly hoch, die zuvor als DLL-Datei von verwaltetem Code zum Verwenden in einer Instanz von SQL Server kompiliert wurde.
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. Das Ignorieren dieser Option vermindert die Trennung vorhandener Codeanweisungen.
In SQL Server ist es nicht zulässig, verschiedene Versionen einer Assembly mit demselben Namen, derselben Kultur und demselben öffentlichen Schlüssel 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 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. Falls eine Assembly, auf die verwiesen wird, aufgrund einer früheren CREATE ASSEMBLY-Anweisung bereits in die Datenbank hochgeladen wurde, wird diese Assembly nicht hochgeladen, ist aber für die Stammassembly verfügbar. Falls eine abhängige Assembly nicht zuvor hochgeladen 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 hochgeladen werden.
Assemblyüberprüfung
SQL Server überprüft die Binärdaten der Assemblys, die mithilfe der CREATE ASSEMBLY-Anweisung hochgeladen 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, System.Data.SqlXml.dll, System.Core.dll und System.Xml.Linq.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 Benutzerdefinierte Attribute für CLR-Routinen.
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, wird die EXTERNAL ACCESS ASSEMBLY-Berechtigung auf dem Server benötigt. Falls PERMISSION_SET = UNSAFE angegeben ist, wird UNSAFE ASSEMBLY-Berechtigung auf dem Server benötigt.
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. 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.
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. - Und eine der folgenden Bedingungen muss auch 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 aufONfestgelegt, und der Besitzer der Datenbank ist ein Anmeldename, der überUNSAFE ASSEMBLY-Berechtigungen auf dem Server verfügt. Diese Option wird nicht empfohlen.
- Die Assembly ist mit einem Zertifikat oder asymmetrischen Schlüssel signiert, der über einen entsprechenden Anmeldenamen mit der
Weitere Informationen zu Assemblyberechtigungen finden Sie unter Entwerfen von Assemblys.
Beispiele
Beispiel A: Erstellen einer Assembly aus einer dll
Gilt für: SQL Server 2008 (10.0.x) und höher.
Im folgenden Beispiel wird davon ausgegangen, dass die SQL Server-Datenbank-Engine-Beispiele im Standardspeicherort des lokalen Computers gespeichert sind und dass die Beispielanwendung HelloWorld.csproj kompiliert ist. 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 bietet keine Unterstützung für das Erstellen einer Assembly aus einer Datei.
Beispiel B: Erstellen einer Assembly aus Assemblyteilen
Gilt für: SQL Server 2008 (10.0.x) und höher.
Ersetzen Sie die Beispielteile (die nicht abgeschlossen oder gültig sind) durch Ihre Assemblyteile.
CREATE ASSEMBLY HelloWorld
FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;
Weitere Informationen
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)
Verwendungsszenarien und Beispiele für Common Language Runtime (CLR)-Integration
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für