Entwerfen von Assemblys

In diesem Thema 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

Packen von Assemblys

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 wahrscheinlicher gegenseitig aufrufen, als die methoden weniger verwandter Aufgaben.

Wenn Sie Code in die Assembly packen, sollten Sie Folgendes berücksichtigen:

• 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 im Allgemeinen besser, Code zu trennen, auf dem gespeicherte Datenabhängigkeiten basieren (z. B. benutzerdefinierte Typen und Indizes mit benutzerdefinierten Funktionen), von Code, der keine solchen dauerhaften Datenabhängigkeiten aufweist. 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, für die keine höhere Berechtigung erforderlich ist.

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.

SICHER

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 als Assemblyberechtigungssatz empfohlen.

EXTERNAL_ACCESS

EXTERNAL_ACCESS ermöglicht Assemblys den Zugriff auf bestimmte externe Systemressourcen wie Dateien, Netzwerke, Webdienste, Umgebungsvariablen und die Registrierung. Nur SQL Server-Anmeldungen mit EXTERNEN ACCESS-Berechtigungen können EXTERNAL_ACCESS Assemblys erstellen.

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.

UNSICHER

UNSAFE bietet Assemblys uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb von SQL Server. Code, der in einer UNSAFE-Assembly ausgeführt wird, kann nicht verwalteten Code aufrufen.

Außerdem ermöglicht das Angeben von UNSAFE den Code in der Assembly zum Ausführen von Vorgängen, 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. UNSICHERe Assemblys können auch das Sicherheitssystem von SQL Server oder der Common Language Runtime unterstellen. UNSAFE-Berechtigungen sollten nur für besonders vertrauenswürdige Assemblys von erfahrenen Entwicklern 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 Stabilität des Servers kompromittieren 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  

Darüber hinaus können SAFE- und EXTERNAL_ACCESS 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 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 von Der benutzerdefinierten Assembly verwiesen wird, muss mithilfe von CREATE ASSEMBLY in SQL Server geladen werden. Die folgenden .NET Framework-Assemblys werden bereits in SQL Server geladen und können daher von benutzerdefinierten Assemblys referenziert werden, ohne CREATE ASSEMBLY verwenden zu müssen.

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

Assemblys (Database Engine)
Sicherheit der CLR-Integration