Assemblys: Entwurf
Gilt für:
SQL Server
In diesem Thema werden die folgenden Faktoren beschrieben, die Sie beim Entwerfen von Assemblys berücksichtigen sollten:
Packen von Assemblys
Verwalten der Assemblysicherheit
Einschränkungen für Assemblys
Verpacken von Assemblys
Eine Assembly kann Funktionen für mehrere SQL Server Routine- oder Typs in ihren Klassen und Methoden enthalten. In den meisten Fällen ist es sinnvoll, die Funktionen von Routinen, die verwandte Funktionen ausführen, in der gleichen Assembly zu verpacken, insbesondere, wenn diese Routinen Klassen gemeinsam verwenden, deren Methoden sich gegenseitig aufrufen. Klassen, die Dateneingabe-Verwaltungstasks für CLR-Trigger (Common Language Runtime) und CLR-gespeicherte Prozeduren ausführen, können z. B. in der gleichen Assembly verpackt werden. Dies hängt damit zusammen, dass sich die Methoden für diese Klassen mit größerer Wahrscheinlichkeit gegenseitig aufrufen als die Methoden anderer, weniger verwandter Tasks.
Sie sollten Folgendes beachten, wenn Sie Code in einer Assembly verpacken:
CLR-benutzerdefinierte Typen und Indizes, die von CLR-benutzerdefinierten Funktionen abhängen, können bewirken, dass sich persistente Daten in der Datenbank befinden, die von der Assembly abhängen. Das Bearbeiten des Codes einer Assembly ist in der Regel komplexer, wenn persistente Daten vorhanden sind, die von der Assembly in der Datenbank abhängen. Auf diesem Grund ist es im Allgemeinen besser, Code, von dem die Abhängigkeiten persistenter Daten abhängen (z. B. benutzerdefinierte Typen und Indizes, die benutzerdefinierte Funktionen verwenden), von Code zu trennen, der keine solchen Abhängigkeiten persistenter Daten aufweist. Weitere Informationen finden Sie unter Implementieren von Assemblys und ALTER ASSEMBLY (Transact-SQL).
Wenn verwalteter Code höhere Berechtigungen verlangt, ist es besser, diesen Code in einer anderen Assembly als den Code zu speichern, für den die höheren Berechtigungen nicht erforderlich sind.
Verwalten der Assemblysicherheit
Sie können steuern, im welchem Umfang eine Assembly auf Ressourcen zugreifen kann, die durch .NET Code Access Security geschützt ist, wenn diese verwalteten Code ausführt. Sie geben zu diesem Zweck einen von drei Berechtigungssätzen an, wenn Sie eine Assembly erstellen oder ändern: SAFE, EXTERNAL_ACCESS oder UNSAFE.
SAFE
SAFE ist der Standardberechtigungssatz und die restriktivste Einstellung. Code, der von einer Assembly mit SAFE-Berechtigungen ausgeführt wird, kann nicht auf externe Systemressourcen wie z. B. Dateien, das Netzwerk, Umgebungsvariablen oder die Registrierung zugreifen. SAFE-Code kann auf Daten aus den lokalen SQL Server Datenbanken zugreifen oder Berechnungen und Geschäftslogik ausführen, die nicht den Zugriff auf Ressourcen außerhalb der lokalen Datenbanken beinhalten.
Die meisten Assemblys führen Berechnungs- und Datenverwaltungsaufgaben aus, ohne auf Ressourcen außerhalb SQL Server zugreifen zu müssen. Aus diesem Grund wird empfohlen, SAFE als Berechtigungssatz für die Assembly zu verwenden.
EXTERNAL_ACCESS
EXTERNAL_ACCESS ermöglicht Assemblys den Zugriff auf bestimmte externe Systemressourcen wie z. B. Dateien, Netzwerke, Webdienste, Umgebungsvariablen und die Registrierung. Nur SQL Server Anmeldungen mit EXTERNAL ACCESS-Berechtigungen können EXTERNAL_ACCESS Assemblys erstellen.
SAFE- und EXTERNAL_ACCESS-Assemblys können nur Code enthalten, der überprüfbar typsicher ist. Dies bedeutet, dass diese Assemblys auf Klassen nur über definierte Einstiegspunkte zugreifen können, die für die Typdefinition gültig sind. Daher können sie nicht beliebig auf Speicherpuffer zugreifen, die sich nicht im Besitz des Codes befinden. Darüber hinaus können keine Vorgänge ausgeführt werden, die sich negativ auf die Robustheit des SQL Server-Prozesses auswirken können.
UNSAFE
UNSAFE bietet Assemblys uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb SQL Server. Code, der aus einer UNSAFE-Assembly ausgeführt wird, kann nicht verwalteten Code aufrufen.
Wenn Sie UNSAFE angeben, kann der Code in der Assembly außerdem Vorgänge ausführen, die von der CLR-Überprüfung als typunsicher betrachtet werden. Diese Vorgänge können möglicherweise unkontrolliert auf Speicherpuffer im SQL Server Prozessbereich zugreifen. UNSAFE-Assemblys können außerdem potenziell das Sicherheitssystem von SQL Server oder der CLR unterlaufen. UNSAFE-Berechtigungen sollten nur hochgradig vertrauenswürdigen Assemblys durch erfahrene Entwickler oder Administratoren erteilt werden. Nur Mitglieder der festen Serverrolle sysadmin können UNSAFE-Assemblys erstellen.
Einschränkungen für Assemblys
SQL Server legt bestimmte Einschränkungen für verwalteten Code in Assemblys fest, um sicherzustellen, dass sie zuverlässig und skalierbar ausgeführt werden können. Dies bedeutet, dass bestimmte Vorgänge, die die Robustheit des Servers beeinträchtigen könnten, in SAFE- und EXTERNAL_ACCESS-Assemblys nicht zulässig sind.
Unzulässige benutzerdefinierte Attribute
Assemblys dürfen nicht mit den folgenden benutzerdefinierten Attributen mit Anmerkungen versehen werden:
System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute
Außerdem dürfen SAFE- und EXTERNAL_ACCESS-Assemblys nicht mit den folgenden benutzerdefinierten Attributen mit Anmerkungen versehen werden:
System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
Unzulässige .NET Framework-APIs
Jede Microsoft .NET Framework-API, die mit einem der nicht zulässigen HostProtectionAttributes versehen ist, kann nicht aus SAFE- und EXTERNAL_ACCESS Assemblys aufgerufen werden.
eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI
Unterstützte .NET Framework-Assemblys
Jede Assembly, auf die ihre benutzerdefinierte Assembly verweist, muss mithilfe von CREATE ASSEMBLY in SQL Server geladen werden. Die folgenden .NET Framework Assemblys sind bereits in SQL Server geladen und können daher von benutzerdefinierten Assemblys referenziert werden, ohne CREATE ASSEMBLY verwenden zu müssen.
CustomMarshalers.dll
Microsoft.VisualBasic.dll
Microsoft.VisualC.dll
mscorlib.dll
System.dll
System.Configuration.dll
System.Core.dll
System.Data.dll
System.Data.OracleClient.dll
System.Data.SqlXml.dll
System.Deployment.dll
System.Security.dll
System.Transactions.dll
System.Web.Services.dll
system.Xml.dll
System.Xml.Linq.dll
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für