L'esecuzione di CLR di SQL Server ha esito negativo con TypeInitializationException

Questo articolo consente di risolvere il problema in cui l'esecuzione di oggetti CLR di SQL Server ha esito negativo e restituisce un'eccezione System.TypeInitializationException .

Si applica a: SQL Server
Numero KB originale: 4576575

Sintomi

Importante

Questo articolo contiene informazioni che illustrano come ridurre le impostazioni di sicurezza o come disattivare le funzionalità di sicurezza in un computer. È possibile apportare queste modifiche per risolvere un problema specifico. Prima di apportare queste modifiche, è consigliabile valutare i rischi associati all'implementazione di questa soluzione alternativa nell'ambiente specifico. Se si implementa questa soluzione alternativa, eseguire eventuali passaggi aggiuntivi appropriati per proteggere il computer.

Dopo aver installato un aggiornamento di .NET Framework applicabile per correggere una vulnerabilità descritta in CVE-2020-1147, l'esecuzione di oggetti di database di compilazione con l'integrazione CLR (Common Language Runtime) che legge XML in oggetti di guida per la sicurezza di DataSet e DataTable ha esito negativo. Ciò si verifica a causa di un'eccezione System.TypeInitializationException con un'eccezione FileNotFoundException nidificata. Questo problema indica che non è stato possibile caricare l'assembly System.Drawing .

Per riferimento, vedere l'esempio seguente:

Messaggio 6522, livello 16, stato 1, routine [oggetto CLR], riga 0 [riga di avvio batch 0] Si è verificato un errore .NET Framework durante l'esecuzione di routine definita dall'utente o di aggregazione "l'oggetto CLR":
System.TypeInitializationException: l'inizializzatore di tipo per 'Scope' ha generato un'eccezione. >--- System.IO.FileNotFoundException: impossibile caricare il file o l'assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=<Token>' o una delle relative dipendenze. Non è possibile trovare il file specificato.
System.TypeInitializationException:
in System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type type)
in System.Data.TypeLimiter.Scope.IsAllowedType(Type)
in System.Data.TypeLimiter.EnsureTypeIsAllowed(Type, TypeLimiter capturedLimiter) all'indirizzo System.Data.DataColumn.UpdateColumnType(Type, StorageType typeCode)
in System.Data.DataColumn.. ctor(String columnName, Type dataType, String expr, MappingType type)
in System.Data.XSDSchema.HandleElementColumn(XmlSchemaElement elem, Tabella DataTable, Boolean isBase)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren, Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList tableChildren, Boolean isNillable)
in System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode, Boolean isRef)
in System.Data.XSDSchema.HandleTable(Nodo XmlSchemaElement)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren, Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList tableChildren, Boolean isNillable)
in System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode, Boolean isRef)
in System.Data.XSDSchema.HandleTable(Nodo XmlSchemaElement)
in System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
in System.Data.DataSet.InferSchema(XmlDocument xdoc, String[] excludedNamespaces, XmlReadMode mode)
in System.Data.Data...

Risoluzione

Questo problema è stato risolto nel 13 ottobre 2020 per la ripubblicazione degli aggiornamenti di sola sicurezza di .NET Framework di luglio 2020.

Per altre informazioni, tra cui come ottenere la patch, vedere Ripubblicazione di .NET Framework degli aggiornamenti solo sicurezza di luglio 2020.

Soluzione alternativa

Avviso

Questa soluzione alternativa potrebbe rendere il computer o la rete più vulnerabile ad attacchi di utenti malintenzionati o programmi software dannosi, ad esempio i virus. Questa soluzione alternativa non è consigliata, ma fornisce queste informazioni in modo che sia possibile implementare questa soluzione alternativa a propria discrezione. L'utilizzo di questa soluzione avviene pertanto a rischio esclusivo dell'utente.

Per le applicazioni che deserializzano dati XML non attendibili in un'istanza di DataSet o DataTable oggetti, è consigliabile usare un metodo alternativo per accedere ai dati. Per le applicazioni che leggono solo dati XML attendibili, è possibile provare una delle soluzioni alternative seguenti.

Note

Le soluzioni alternative 1 e 2 sono preferibili perché le modifiche vengono apportate localmente. La soluzione alternativa 3 è a livello di sistema.

Avviso

Queste soluzioni alternative consentono di rimuovere le restrizioni dei tipi per deserializzare XML in istanze di DataSet oggetti e DataTable . Questo potrebbe aprire un foro di sicurezza se l'applicazione legge l'input non attendibile.

Soluzione alternativa 1: Chiamare AppContext.SetSwitch

Modificare l'inizio del codice oggetto CLR SQL per impostare l'opzione Switch.System.Data.AllowArbitraryDataSetTypeInstantiation su true. È necessario eseguire questa operazione per ogni oggetto CLR SQL applicabile. Vedi l'esempio seguente.

Per altre informazioni, vedere Linee guida per la sicurezza di DataSet e DataTable.

Soluzione alternativa 2: Creare o modificare il file Sqlservr.exe.config per ogni istanza applicabile

Questa soluzione alternativa si applica solo all'istanza stessa.

Importante

Non è possibile garantire che questa modifica non venga sovrascritta dagli aggiornamenti di SQL Server o dalle istanze. È consigliabile determinare se la modifica persiste dopo un aggiornamento o un aggiornamento dell'istanza.

1. Individuare il file Sqlservr.exe.config nei percorsi dei file per le istanze predefinite e denominate di SQL Server:

   %ProgramFiles%\Microsoft SQL Server\<Instance_ID>.<Instance Name>\MSSQL\Binn\

2. All'interno del <runtime> nodo, ma all'esterno di tutti i nodi annidati, aggiungere la riga seguente:

   <AppContextSwitchOverrides value="Switch.System.Data. AllowArbitraryDataSetTypeInstantiation=true"/>
   

3. Salvare il file e riavviare l'istanza.

   Vedere l'esempio seguente di un'istanza di SQL Server 2016.

   

Soluzione alternativa 3: Creare l'assembly System.Drawing

Creare manualmente l'assembly System.Drawing in SQL Server dal file DLL nella Global Assembly Cache (GAC) e quindi ricreare gli assembly che usano DataSet.ReadXML o DataTable.ReadXML. Ad esempio:

 CREATE ASSEMBLY [Drawing] FROM 'C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll' WITH PERMISSION_SET = UNSAFE GO

Soluzione alternativa 4: Creare una sottochiave del Registro di sistema

Importante

Seguire attentamente la procedura descritta in questa soluzione alternativa. Se le modifiche al Registro di sistema vengono apportate in modo non corretto, possono verificarsi problemi gravi. Prima di apportare le modifiche, eseguire il backup del Registro di sistema per il ripristino nel caso si verifichino dei problemi.

Questa soluzione alternativa influirà su tutte le applicazioni .NET nel server. Pertanto, è consigliabile usare questo metodo solo come ultima risorsa se non è possibile usare le altre soluzioni alternative.

1. Aprire l'editor delRegistro di sistema.

2. Individuare la seguente sottochiave:

   KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

3. Creare un REG_SZ valore, come indicato di seguito.

   Nome	Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
   Valore	true

4. Riavviare tutte le istanze di SQL Server.

   Vedi l'esempio seguente.

   

Ulteriori informazioni

Questo problema è causato dall'azione di un recente aggiornamento della sicurezza di .NET Framework per correggere la convalida del markup del contenuto XML di .NET Framework. Gli oggetti CLR di SQL Server che non leggono XML in istanze di DataSet o DataTable oggetti non saranno interessati.