Entwerfen von Assemblys
Gilt für: SQL Server
In diesem Artikel werden die folgenden Faktoren beschrieben, die Sie beim Entwerfen von Assemblys berücksichtigen sollten:
- Verpacken von Assemblys
- Verwalten der Assemblysicherheit
- Einschränkungen für Assemblys
Paketassemblys
Eine Assembly kann Funktionen für mehrere SQL Server-Routinen oder -Typen in den 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 liegt daran, dass sich die Methoden für diese Klassen eher gegenseitig aufrufen als Methoden weniger verwandter Aufgaben.
Berücksichtigen Sie beim Packen von Code in der Assembly Folgendes:
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 Ändern des Codes einer Assembly ist häufig komplexer, wenn gespeicherte Daten vorhanden sind, die von der Assembly in der Datenbank abhängen. Daher ist es besser, Code zu trennen, auf dem beibehaltene Datenabhängigkeiten (z. B. benutzerdefinierte Typen und Indizes mit benutzerdefinierten Funktionen) von Code getrennt werden, der nicht über diese dauerhaften Datenabhängigkeiten verfügt. Weitere Informationen finden Sie unter Implementieren von Assemblys und ALTER ASSEMBLY (Transact-SQL).
Wenn ein Teil von verwaltetem Code eine höhere Berechtigung erfordert, ist es besser, diesen Code in eine separate Assembly vom Code zu trennen, der keine höhere Berechtigung erfordert.
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. Dazu geben Sie einen von drei Berechtigungssätzen an, wenn Sie eine Assembly erstellen oder ändern: SAFE
, EXTERNAL_ACCESS
, oder UNSAFE
.
SAFE-Berechtigung
SAFE
ist der Standardberechtigungssatz und ist der restriktivste. 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. SAFE
Code kann auf Daten aus den lokalen SQL Server-Datenbanken zugreifen oder Berechnungen und Geschäftslogik ausführen, die keinen Zugriff auf Ressourcen außerhalb der lokalen Datenbanken erfordern.
Die meisten Assemblys führen Berechnungs- und Datenverwaltungsaufgaben durch, ohne auf Ressourcen außerhalb von SQL Server zugreifen zu müssen. Daher wird SAFE
empfohlen, als Assemblyberechtigungssatz festzulegen.
EXTERNAL_ACCESS-Berechtigung
EXTERNAL_ACCESS
ermöglicht Assemblys den Zugriff auf bestimmte externe Systemressourcen wie Dateien, Netzwerke, Webdienste, Umgebungsvariablen und die Registrierung. Nur SQL Server-Anmeldungen mit EXTERNAL ACCESS
Berechtigungen können Assemblys erstellen EXTERNAL_ACCESS
.
SAFE und EXTERNAL_ACCESS
Assemblys können nur Code enthalten, der nachweislich 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 willkürlich auf Speicherpuffer zugreifen, die nicht im Besitz des Codes sind. Darüber hinaus können sie keine Vorgänge ausführen, die sich negativ auf die Stabilität des SQL Server-Prozesses auswirken können.
UNSAFE-Berechtigung
UNSAFE
bietet Assemblys uneingeschränkten Zugriff auf Ressourcen, sowohl innerhalb als auch außerhalb von SQL Server. Code, der in einer UNSAFE
Assembly ausgeführt wird, kann nicht verwalteten Code aufrufen.
Außerdem ermöglicht die Angabe UNSAFE
, dass der Code in der Assembly Vorgänge ausführt, die vom CLR-Prüfer als typunsicher eingestuft werden. Diese Vorgänge können potenziell auf Speicherpuffer im SQL Server-Prozessbereich auf unkontrollierte Weise zugreifen. UNSAFE
Assemblys können das Sicherheitssystem entweder von SQL Server oder der Common Language Runtime möglicherweise subvertieren. UNSAFE-Berechtigungen sollten nur hochgradig vertrauenswürdigen Assemblys durch erfahrene Entwickler oder Administratoren erteilt werden. Nur Mitglieder der festen Serverrolle "sysadmin " können Assemblys erstellen UNSAFE
.
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 Stabilität des Servers gefährden können, in SAFE und EXTERNAL_ACCESS
Assemblys nicht zulässig sind.
Nicht zulässige benutzerdefinierte Attribute
Assemblys können nicht mit den folgenden benutzerdefinierten Attributen kommentiert 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
SAFE
EXTERNAL_ACCESS
Darüber hinaus können Assemblys nicht mit den folgenden benutzerdefinierten Attributen kommentiert werden:
System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
Unzulässige .NET Framework-APIs
Jede Microsoft .NET Framework-API, die mit einer der unzulässigen HostProtectionAttributes
Anmerkungen versehen ist, kann nicht von SAFE
assemblys EXTERNAL_ACCESS
aufgerufen werden.
eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI
Unterstützte .NET Framework-Assemblys
Jede Assembly, auf die von der benutzerdefinierten Assembly verwiesen wird, muss mithilfe CREATE ASSEMBLY
von SQL Server in SQL Server geladen werden. Die folgenden .NET Framework-Assemblys werden bereits in SQL Server geladen und können daher von benutzerdefinierten Assemblys ohne Verwendung CREATE ASSEMBLY
referenziert werden.
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
Zugehöriger Inhalt
Feedback
https://aka.ms/ContentUserFeedback.
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 unterFeedback senden und anzeigen für