Freigeben über

Entwerfen von Assemblys

  • Artikel

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 ASSEMBLYvon 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 ASSEMBLYreferenziert 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