CREATE ASSEMBLY (Transact-SQL)

  • Articolo

Crea un modulo gestito dell'applicazione, contenente metadati di classe e codice gestito come oggetto in un'istanza di SQL Server. Facendo riferimento a questo modulo, è possibile creare funzioni CLR (Common Language Runtime), stored procedure, trigger, funzioni di aggregazione definite dall'utente e tipi definiti dall'utente.

Icona di collegamento a un argomentoConvenzioni della sintassi Transact-SQL

Sintassi

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ ,...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]

<client_assembly_specifier> :: =
        '[\\computer_name\]share_name\[path\]manifest_file_name'
  | '[local_path\]manifest_file_name'

<assembly_bits> :: =
{ varbinary_literal | varbinary_expression }

Argomenti

  • assembly_name
    Nome dell'assembly. Il nome deve essere univoco all'interno del database e un identificatore valido.
  • AUTHORIZATION owner_name
    Specifica il nome di un utente o di un ruolo come proprietario dell'assembly. owner_namedeve essere il nome di un ruolo di cui l'utente corrente è membro, oppure l'utente corrente deve disporre dell'autorizzazione IMPERSONATE per owner_name. Se viene omesso, la proprietà viene assegnata all'utente corrente.

  • <client_assembly_specifier>
    Specifica il percorso locale o di rete dell'assembly che viene caricato e il nome del file di manifesto che corrisponde all'assembly. <client_assembly_specifier> può essere espresso come stringa fissa o espressione che restituisce una stringa fissa, con variabili. CREATE ASSEMBLY non supporta il caricamento di assembly in più moduli. SQL Server cerca anche eventuali assembly dipendenti di questo assembly nello stesso percorso e li carica con lo stesso proprietario come assembly a livello di radice. Se tali assembly dipendenti non vengono trovati e non sono già caricati nel database corrente, CREATE ASSEMBLY ha esito negativo. Se gli assembly dipendenti sono già caricati nel database corrente, il proprietario degli assembly deve corrispondere al proprietario dell'assembly appena creato.

    <client_assembly_specifier> non può essere specificato se l'utente connesso viene rappresentato.

  • <assembly_bits>
    Elenco dei valori binari che costituiscono l'assembly e i relativi assembly dipendenti. Il primo valore dell'elenco viene considerato l'assembly a livello di radice. I valori corrispondenti agli assembly dipendenti possono essere specificati in qualsiasi ordine. I valori non corrispondenti alle dipendenze dell'assembly principale vengono ignorati.
  • varbinary_literal
    Valore letterale di tipo varbinary.
  • varbinary_expression
    Espressione di tipo varbinary.

  • PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }
    Specifica un set di autorizzazioni di accesso per il codice che vengono concesse all'assembly quando vi accede SQL Server. Se è omesso, SAFE viene applicato come valore predefinito.

    È consigliabile utilizzare SAFE. SAFE è il set di autorizzazioni più restrittivo. Il codice eseguito da un assembly con autorizzazioni SAFE non può accedere alle risorse di sistema esterne, ad esempio i file, la rete, le variabili di ambiente o il Registro di sistema.

    EXTERNAL_ACCESS consente agli assembly di accedere a determinate risorse di sistema esterne, ad esempio i file, la rete, le variabili di ambiente e il Registro di sistema.

    UNSAFE consente agli assembly privilegi di accesso senza limitazioni, sia all'interno che all'esterno di un'istanza di SQL Server. Il codice eseguito all'interno di un assembly UNSAFE può chiamare il codice non gestito.

    ms189524.security(it-it,SQL.90).gifNota sulla protezione:
    SAFE è l'impostazione di autorizzazioni consigliata per gli assembly che eseguono attività di calcolo e di gestione di dati senza accedere alle risorse all'esterno di un'istanza di SQL Server. È consigliabile utilizzare EXTERNAL_ACCESS per gli assembly che accedono alle risorse all'esterno di un'istanza di SQL Server. Gli assembly EXTERNAL_ACCESS includono l'affidabilità e la scalabilità degli assembly SAFE, ma dal punto di vista della protezione sono simili agli assembly UNSAFE. Ciò è dovuto al fatto che il codice negli assembly EXTERNAL_ACCESS viene eseguito con l'account del servizio SQL Server per impostazione predefinita e con tale account accede a risorse esterne, a meno che il codice non rappresenti esplicitamente il chiamante. Pertanto, l'autorizzazione per creare gli assembly EXTERNAL_ACCESS deve essere concessa solo agli account di accesso che si ritengono attendibili per l'esecuzione del codice con l'account del servizio SQL Server. Per ulteriori informazioni sulla rappresentazione, vedere CLR Integration Security. Specificando UNSAFE, al codice nell'assembly viene concessa l'assoluta libertà di eseguire operazioni nello spazio di processo di SQL Server che potrebbero compromettere l'affidabilità di SQL Server. Gli assembly UNSAFE possono anche compromettere il sistema di sicurezza di SQL Server o del CLR. Le autorizzazioni UNSAFE devono essere concesso solo agli assembly altamente attendibili. Solo i membri del ruolo predefinito del server sysadmin possono creare e modificare gli assembly UNSAFE.

    Per ulteriori informazioni sui set di autorizzazioni per gli assembly, vedere Progettazione di assembly.

Osservazioni

CREATE ASSEMBLY carica un assembly compilato precedentemente come file con estensione dll da codice gestito da utilizzare all'interno di un'istanza di SQL Server.

SQL Server non consente la registrazione di versioni diverse di un assembly con lo stesso nome, lingua e chiave pubblica.

Durante il tentativo di accedere all'assembly specificato in <client_assembly_specifier>, SQL Server rappresenta il contesto di protezione dell'account di accesso di Windows corrente. Se <client_assembly_specifier> specifica un percorso di rete (percorso UNC), la rappresentazione dell'account di accesso corrente non viene trasferita al percorso di rete a causa dei limiti di delega. In questo caso, l'accesso viene effettuato tramite il contesto di protezione dell'account del servizio SQL Server. Per ulteriori informazioni, vedere Credenziali.

Oltre all'assembly principale specificato da assembly_name, SQL Server tenta di caricare tutti gli assembly a cui fa riferimento l'assembly radice che viene caricato. Se un assembly con riferimenti è già caricato nel database a causa di un'istruzione CREATE ASSEMBLY precedente, questo assembly non viene caricato ma è disponibile per l'assembly principale. Se un assembly dipendente non è stato caricato precedentemente, ma SQL Server non è in grado di individuare il relativo file di manifesto nella directory di origine, CREATE ASSEMBLY restituisce un errore.

Se un assembly dipendente a cui viene fatto riferimento dall'assembly principale non è già nel database e viene caricato implicitamente con l'assembly principale, avrà lo stesso set di autorizzazioni dell'assembly a livello di radice. Se gli assembly dipendenti devono essere creati tramite un set di autorizzazioni diverso rispetto all'assembly a livello di radice, essi devono essere caricati esplicitamente prima dell'assembly a livello di radice con il set di autorizzazioni appropriato.

Convalida di assembly

SQL Server esegue controlli sui file binari degli assembly caricati tramite l'istruzione CREATE ASSEMBLY per garantire quanto segue:

  • Il file binario di assembly è ben formato con metadati e segmenti di codice validi e i segmenti di codice contengono istruzioni MSIL (Microsoft Intermediate Language) valide.
  • Il set di assembly di sistema cui fa riferimento è uno degli assembly supportati seguenti in SQL Server: Microsoft.Visualbasic.dll, Mscorlib.dll, System.Data.dll, System.dll, System.Xml.dll, Microsoft.Visualc.dll, Custommarshallers.dll, System.Security.dll, System.Web.Services.dll e System.Data.SqlXml.dll. Può far riferimento anche ad altri assembly di sistema, ma è necessario che siano registrati nel database in modo esplicito.
  • Per gli assembly creati tramite i set di autorizzazioni SAFE o EXTERNAL ACCESS:
    • Il codice di assembly deve essere indipendente dai tipi. L'indipendenza dai tipi viene stabilita eseguendo CLR Verifier sull'assembly.
    • L'assembly non deve contenere membri di dati statici all'interno delle relative classi a meno che non siano contrassegnati come di sola lettura.
    • Le classi nell'assembly non possono contenere metodi del finalizzatore.
    • Le classi o i metodi dell'assembly devono essere annotati solo con gli attributi del codice consentiti. Per ulteriori informazioni, vedere Custom Attributes for CLR Routines.

Oltre ai controlli precedenti eseguiti durante l'esecuzione di CREATE ASSEMBLY, vengono eseguiti controlli aggiuntivi in fase di esecuzione del codice dell'assembly:

  • La chiamata di alcune API Microsoft .NET Framework che richiedono un'autorizzazione di accesso per il codice specifica può non riuscire se il set di autorizzazioni dell'assembly non include tale autorizzazione.
  • Per gli assembly SAFE e EXTERNAL_ACCESS, ogni tentativo di chiamare API .NET Framework annotate con determinati attributi HostProtectionAttributes non riuscirà.

Per ulteriori informazioni, vedere Progettazione di assembly.

Autorizzazioni

È richiesta l'autorizzazione CREATE ASSEMBLY.

Se si specifica PERMISSION_SET = EXTERNAL_ACCESS, l'account di accesso di SQL Server deve disporre dell'autorizzazione EXTERNAL ACCESS ASSEMBLY nel server. Se si specifica PERMISSION_SET = UNSAFE, è richiesta l'appartenenza al ruolo predefinito del server sysadmin.

L'utente deve essere il proprietario degli assembly cui viene fatto riferimento dall'assembly che sta per essere caricato se gli assembly esistono già nel database. Per caricare un assembly utilizzando un percorso di file, l'utente corrente deve disporre di un account di accesso autenticato di Windows o essere un membro del ruolo predefinito del server sysadmin. L'account di accesso di Windows dell'utente che esegue CREATE ASSEMBLY deve disporre dell'autorizzazione di lettura per la cartella condivisa e per i file che vengono caricati nell'istruzione.

Per ulteriori informazioni sui set di autorizzazioni per gli assembly, vedere Progettazione di assembly.

Esempi

Nell'esempio seguente viene presupposto che le applicazioni di esempio di Motore di database di SQL Server siano installate nel percorso predefinito del computer locale e che l'applicazione di esempio HelloWorld.csproj sia compilata. Per ulteriori informazioni, vedere Esempio Hello World.

DECLARE @SamplesPath nvarchar(1024)
SELECT @SamplesPath = REPLACE(physical_name, 
    'Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf', 
    'Microsoft SQL Server\90\Samples\Engine\Programmability\CLR\') 
FROM master.sys.database_files 
WHERE name = 'master';
CREATE ASSEMBLY HelloWorld 
FROM @SamplesPath + 'HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Vedere anche

Riferimento

ALTER ASSEMBLY (Transact-SQL)
DROP ASSEMBLY (Transact-SQL)
CREATE FUNCTION (Transact-SQL)
CREATE PROCEDURE (Transact-SQL)
CREATE TRIGGER (Transact-SQL)
CREATE TYPE (Transact-SQL)
CREATE AGGREGATE (Transact-SQL)
EVENTDATA (Transact-SQL)

Altre risorse

Esempi di programmabilità CLR

Guida in linea e informazioni

Assistenza su SQL Server 2005