Progettazione di assembly

Data aggiornamento: 5 dicembre 2005

In questo argomento vengono illustrati alcuni fattori da prendere in considerazione durante la progettazione degli assembly:

• Assemblaggio di assembly
• Gestione della protezione degli assembly
• Limitazioni relative agli assembly

Assemblaggio di assembly

Le classi e i metodi di un assembly possono contenere funzionalità per più di una routine o un tipo di SQL Server. Nella maggior parte dei casi è opportuno assemblare le funzionalità delle routine che eseguono funzioni correlate all'interno dello stesso assembly, in particolare se le routine condividono classi i cui metodi si chiamano a vicenda. Ad esempio, le classi che eseguono attività di gestione dell'immissione di dati per trigger CLR (Common Language Runtime) e stored procedure CLR possono essere assemblate nello stesso assembly. Il motivo di questa scelta è che è più probabile che i metodi di queste classi si chiamino l'un l'altro rispetto ai metodi di attività meno correlate.

Quando si assembla codice in assembly, è opportuno prendere in considerazione i fattori seguenti:

• I tipi CLR definiti dall'utente e gli indici che dipendono da funzioni CLR definite dall'utente possono provocare la presenza di dati persistenti nel database che dipende dall'assembly. Modificare il codice di un assembly risulta spesso più complesso quando nel database sono presenti dati persistenti che dipendono dall'assembly. È pertanto preferibile separare il codice sul quale si basano le dipendenze dei dati persistenti, ad esempio i tipi definiti dall'utente e gli indici che utilizzano funzioni definite dall'utente, dal codice che non contiene questo tipo di dipendenze. Per ulteriori informazioni, vedere Implementazione di assembly e ALTER ASSEMBLY (Transact-SQL).
• Se una parte di codice gestito richiede un'autorizzazione di livello superiore, è opportuno inserirla in un assembly separato.

Gestione della protezione degli assembly

È possibile controllare l'accesso di un assembly alle risorse protette dalla protezione dall'accesso di codice .NET quando esegue codice gestito. A questo scopo, quando si crea o modifica l'assembly è necessario specificare uno dei tre set di autorizzazioni disponibili: SAFE, EXTERNAL_ACCESS oppure UNSAFE.

SAFE

SAFE è il set di autorizzazioni predefinito ed è il più restrittivo. Il codice eseguito da un assembly con autorizzazioni SAFE non può accedere a risorse di sistema esterne, ad esempio file, la rete, variabili di ambiente o il Registro di sistema. Il codice SAFE può accedere ai dati dei database di SQL Server locali o eseguire calcoli e regole business che non comportino l'accesso a risorse esterne ai database locali.

Nella maggior parte dei casi gli assembly eseguono attività di calcolo e gestione dei dati senza accedere a risorse esterne a SQL Server. È pertanto consigliabile applicare agli assembly il set di autorizzazioni SAFE.

EXTERNAL_ACCESS

EXTERNAL_ACCESS consente agli assembly di accedere a specifiche risorse di sistema esterne, ad esempio file, reti, servizi Web, variabili di ambiente e il Registro di sistema. Solo gli account di accesso di SQL Server con autorizzazioni EXTERNAL ACCESS possono creare assembly EXTERNAL_ACCESS.

Gli assembly SAFE ed EXTERNAL_ACCESS possono contenere solo codice indipendente dai tipi. Ciò significa che questi assembly possono accedere alle classi solo tramite punti di accesso ben definiti, validi per la definizione del tipo. Non possono pertanto accedere arbitrariamente a buffer di memoria non di proprietà del codice. Non possono inoltre eseguire operazioni che possono influire in modo negativo sull'affidabilità del processo di SQL Server.

UNSAFE

Il set di autorizzazioni UNSAFE concede agli assembly libero accesso alle risorse interne ed esterne a SQL Server. Il codice eseguito da un assembly UNSAFE può chiamare codice non gestito.

Specificando UNSAFE si consente inoltre al codice dell'assembly di eseguire operazioni considerate non indipendenti dai tipi da CLR Verifier. Tali operazioni potrebbero accedere ai buffer di memoria nello spazio di processo di SQL Server in modo incontrollato. Gli assembly UNSAFE possono potenzialmente sovvertire il sistema di protezione di SQL Server o di Common Language Runtime. Si consiglia di concedere le autorizzazioni UNSAFE solo ad assembly assolutamente attendibili, creati da sviluppatori o amministratori esperti. Solo i membri del ruolo predefinito del server sysadmin possono creare assembly UNSAFE.

Limitazioni relative agli assembly

In SQL Server 2005 vengono imposte restrizioni sul codice gestito negli assembly per garantirne l'affidabilità e la scalabilità. Alcune operazioni potenzialmente in grado di compromettere l'affidabilità del server non sono consentite negli assembly SAFE ed EXTERNAL_ACCESS.

Attributi personalizzati non consentiti

Non è possibile annotare gli assembly con gli attributi personalizzati seguenti:

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

Non è inoltre possibile annotare gli assembly SAFE ed EXTERNAL_ACCESS con gli attributi personalizzati seguenti:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

API .NET Framework non consentite

Le API Microsoft .NET Framework annotate con uno degli attributi HostProtectionAttributes non consentiti non possono essere chiamate dagli assembly SAFE ed EXTERNAL_ACCESS.

eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState 
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI

Assembly .NET Framework supportati

Gli assembly cui fa riferimento l'assembly personalizzato devono essere caricati in SQL Server 2005 utilizzando CREATE ASSEMBLY. Gli assembly .NET Framework seguenti sono già caricati in SQL Server e, pertanto, possono essere utilizzati come riferimento dagli assembly personalizzati senza richiedere l'utilizzo di CREATE ASSEMBLY.

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

Vedere anche

Altre risorse

Assembly (Motore di database)
CLR Integration Security

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche