CREATE ASSEMBLY (Transact-SQL)
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.dll
CustomMarshallers.dll
System.Xml.dll
System.dll
System.Security.dll
System.Web.Services.dll
Microsoft.VisualC.dll
System.Data.SqlXml.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 created by using
SAFE
orEXTERNAL 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
undEXTERNAL_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 aufON
festgelegt, und der Besitzer der Datenbank ist ein Anmeldename, der überUNSAFE ASSEMBLY
-Berechtigungen auf dem Server verfügt. Von der Verwendung dieser Option wird abgeraten.
- Die Assembly ist mit einem Zertifikat oder asymmetrischen Schlüssel signiert, der über einen entsprechenden Anmeldenamen mit der
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
- 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