Entwerfen von Assemblys

Aktualisiert: 05. Dezember 2005

Dieses Thema beschreibt die folgenden Faktoren, die Sie beim Entwerfen von Assemblys berücksichtigen sollten:

• Verpacken von Assemblys
• Verwalten der Assemblysicherheit
• Einschränkungen für Assemblys

Verpacken von Assemblys

Eine Assembly kann Funktionen für mehrere SQL Server-Routinen oder -Typen 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 dauerhafte Daten in der Datenbank befinden, die von der Assembly abhängen. Das Bearbeiten des Codes einer Assembly ist in der Regel komplexer, wenn dauerhafte 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 dauerhafter Daten abhängen (z. B. benutzerdefinierte Typen und Indizes, die benutzerdefinierte Funktionen verwenden), von Code zu trennen, der keine solchen Abhängigkeiten dauerhafter 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, für die kein Zugriff auf Ressourcen außerhalb der lokalen Datenbanken erforderlich ist.

Die meisten Assemblys führen Berechnungs- und Datenverwaltungsaufgaben aus, ohne dass ein Zugriff auf Ressourcen außerhalb von SQL Server erforderlich ist. 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-Anmeldenamen 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. Außerdem können sie keine Vorgänge durchführen, die nachteilige Auswirkungen auf die Robustheit des SQL Server-Prozess besitzen könnten.

UNSAFE

UNSAFE ermöglicht Assemblys den uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb von 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 potenziell auf unkontrollierte Weise auf Speicherpuffer im SQL Server-Prozessraum 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 2005 belegt verwalteten Code in Assemblys mit einigen Einschränkungen, damit sichergestellt wird, dass diese auf zuverlässige und skalierbare Weise 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

Microsoft .NET Framework-APIs, die mit einem der unzulässigen HostProtectionAttributes-Attribute mit Anmerkungen versehen sind, können 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 durch die benutzerdefinierte Assembly verwiesen wird, muss mithilfe von CREATE ASSEMBLY in SQL Server 2005 geladen werden. Die folgenden .NET Framework-Assemblys wurden bereits in SQL Server geladen; daher kann durch benutzerdefinierte Assemblys auf sie verwiesen werden, ohne dass CREATE ASSEMBLY verwendet werden muss.

custommarshallers.dll
Microsoft.visualbasic.dll
Microsoft.visualc.dll
mscorlib.dll
system.data.dll
System.Data.SqlXml.dll
system.dll
system.security.dll
system.web.services.dll
system.xml.dll
System.Transactions
System.Data.OracleClient
System.Configuration

Siehe auch

Andere Ressourcen

Assemblys (Database Engine)
CLR Integration Security

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf