Condividi tramite

Azure Data Lake Analytics sta eseguendo l'aggiornamento a .NET Framework v4.7.2

  • Articolo

Importante

Azure Data Lake Analytics è stato ritirato il 29 febbraio 2024. Per altre informazioni, vedere questo annuncio.

Per l'analisi dei dati, l'organizzazione può usare Azure Synapse Analytics o Microsoft Fabric.

Il runtime predefinito di Azure Data Lake Analytics esegue l'aggiornamento da .NET Framework v4.5.2 a .NET Framework v4.7.2. Questa modifica introduce un piccolo rischio di interruzioni se il codice U-SQL utilizza assembly personalizzati e tali assembly utilizzano librerie .NET.

Questo aggiornamento da .NET Framework 4.5.2 alla versione 4.7.2 significa che .NET Framework distribuito in un runtime U-SQL (runtime predefinito) sarà sempre 4.7.2. Non è disponibile un'opzione side-by-side per le versioni di .NET Framework.

Al termine dell'aggiornamento a .NET Framework 4.7.2, il codice gestito del sistema verrà eseguito come versione 4.7.2, le librerie fornite dall'utente, ad esempio gli assembly personalizzati U-SQL, verranno eseguite nella modalità compatibile con le versioni precedenti appropriata per la versione per cui è stato generato l'assembly.

  • Se le DLL degli assembly vengono generate per la versione 4.5.2, il framework distribuito li considererà come librerie 4.5.2, fornendo (con alcune eccezioni) semantica 4.5.2.
  • È ora possibile usare assembly personalizzati U-SQL che usano le funzionalità della versione 4.7.2, se si usa .NET Framework 4.7.2.

A causa di questo aggiornamento a .NET Framework 4.7.2, è possibile introdurre modifiche di rilievo ai processi U-SQL che usano assembly personalizzati .NET. È consigliabile verificare la presenza di problemi di compatibilità con le versioni precedenti usando la procedura seguente.

Come verificare la presenza di problemi di compatibilità con le versioni precedenti

Verificare la presenza di potenziali problemi di compatibilità con le versioni precedenti eseguendo i controlli di compatibilità .NET nel codice .NET negli assembly personalizzati U-SQL.

Nota

Lo strumento non rileva modifiche di rilievo effettive. identifica solo le API .NET che possono (per determinati input) causare problemi. Se ricevi una notifica di un problema, il tuo codice potrebbe comunque essere corretto; tuttavia, dovresti controllare ulteriormente nei dettagli.

  1. Esegui il controllo della compatibilità con le versioni precedenti sulle DLL .NET tramite
    1. Uso dell'estensione di Visual Studio del .NET Portability Analyzer
    2. Scaricamento e utilizzo dello strumento indipendente da GitHub dotnetapiport. Le istruzioni per l'esecuzione di uno strumento autonomo sono disponibili su GitHub dotnetapiport alla sezione modifiche di rilievo
    3. Per la versione 4.7.2. compatibilità, read isRetargeting == True identifica i possibili problemi.
  2. Se lo strumento indica se il codice potrebbe essere interessato da una delle possibili incompatibilità con le versioni precedenti (alcuni esempi comuni di incompatibilità sono elencati di seguito), è possibile controllare ulteriormente
    1. Analisi del codice e identificazione del passaggio di valori alle API interessate
    2. Eseguire un controllo di runtime. La distribuzione del runtime non viene eseguita in parallelo in ADLA. È possibile eseguire un controllo di runtime prima dell'aggiornamento usando l'esecuzione locale di VisualStudio con .NET Framework 4.7.2 locale rispetto a un set di dati rappresentativo.
  3. Se in effetti si è interessati da un'incompatibilità con le versioni precedenti, eseguire i passaggi necessari per correggerli, ad esempio la correzione dei dati o della logica del codice.

Nella maggior parte dei casi, l'incompatibilità con le versioni precedenti non dovrebbe influire su di te.

Sequenza temporale

È possibile verificare l'implementazione del nuovo runtime qui, Risoluzione dei problemi di runtime, e anche esaminando qualsiasi processo precedentemente completato con successo.

Cosa accade se non è possibile esaminare il codice in tempo

È possibile inviare il lavoro alla versione precedente del runtime (che è stata compilata per la versione 4.5.2 del framework), tuttavia, a causa della mancanza di capacità di esecuzione parallela di .NET Framework, verrà comunque eseguito solo in modalità di compatibilità con la versione 4.5.2. È comunque possibile che si verifichino alcuni dei problemi di compatibilità con le versioni precedenti a causa di questo comportamento.

Quali sono i problemi di compatibilità con le versioni precedenti più comuni che possono verificarsi

Le incompatibilità con le versioni precedenti più comuni che è probabile che il correttore identifichi sono (questo elenco è stato generato eseguendo il controllo sui processi ADLA interni), quali librerie sono interessate (si noti che è possibile chiamare le librerie solo indirettamente, quindi è importante eseguire l'azione n. 1 per verificare se i processi sono interessati) e le possibili azioni da risolvere. Nota: in quasi tutti i casi per i nostri lavori, gli avvisi si sono rivelati falsi positivi a causa della natura ristretta della maggior parte delle modifiche incompatibili.

  • La proprietà IAsyncResult.CompletedSynchronously deve essere corretta per il completamento dell'attività risultante

    • Quando si chiama TaskFactory.FromAsync, l'implementazione della proprietà IAsyncResult.CompletedSynchronously deve essere corretta per il completamento dell'attività risultante. Ovvero, la proprietà deve restituire true se e solo se l'implementazione è stata completata in modo sincrono. In precedenza, la proprietà non era verificata.
    • Librerie interessate: mscorlib, System.Threading.Tasks
    • Azione suggerita: verificare che TaskFactory.FromAsync restituisca true correttamente

  • DataObject.GetData ora recupera i dati come UTF-8

    • Per le app destinate a .NET Framework 4 o eseguite in .NET Framework 4.5.1 o versioni precedenti, DataObject.GetData recupera i dati in formato HTML come stringa ASCII. Di conseguenza, i caratteri non ASCII (caratteri i cui codici ASCII sono maggiori di 0x7F) sono rappresentati da due caratteri casuali.#N##N#For app destinate a .NET Framework 4.5 o versione successiva ed eseguite in .NET Framework 4.5.2, DataObject.GetData recupera i dati in formato HTML come UTF-8, che rappresenta caratteri maggiori di 0x7F correttamente.
    • Librerie interessate: Glo
    • Azione suggerita: verificare che i dati recuperati siano il formato desiderato

  • XmlWriter genera un'eccezione in caso di coppie di surrogati non valide

    • Per le app destinate al .NET Framework 4.5.2 o versioni precedenti, la scrittura di una coppia di surrogati non valida tramite la gestione del fallback delle eccezioni non sempre genera un'eccezione. Per le app destinate a .NET Framework 4.6, il tentativo di scrivere una coppia di surrogati non valida genera un ArgumentException.
    • Librerie interessate: System.Xml, System.Xml.ReaderWriter
    • Azione suggerita: assicurarsi di non scrivere una coppia di surrogati non valida che provocherà un'eccezione di argomento.

  • HtmlTextWriter non esegue correttamente il rendering dell'elemento <br/>

    • A partire da .NET Framework 4.6, la chiamata a HtmlTextWriter.RenderBeginTag() e HtmlTextWriter.RenderEndTag() con un elemento <BR /> inserirà correttamente una sola <BR /> (anziché due)
    • Librerie interessate: System.Web
    • Azione suggerita: assicurati che tu stia inserendo la quantità di <BR /> che ti aspetti di vedere affinché non si manifesti alcun comportamento casuale nel processo di produzione.

  • La chiamata a CreateDefaultAuthorizationContext con un argomento Null è stata modificata

    • L'implementazione di AuthorizationContext restituita da una chiamata al CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) con un argomento authorizationPolicies null ha modificato l'implementazione in .NET Framework 4.6.
    • Librerie interessate: System.IdentityModel
    • Azione suggerita: assicurati di gestire il nuovo comportamento previsto quando è presente una policy di autorizzazione null.

  • RSACng carica ora correttamente le chiavi RSA di dimensioni chiave non standard

    • Nelle versioni di .NET Framework precedenti alla 4.6.2, i clienti con dimensioni di chiave non standard per i certificati RSA non sono in grado di accedere a tali chiavi tramite i metodi di estensione GetRSAPublicKey() e GetRSAPrivateKey(). Viene generata una CryptographicException con il messaggio "La dimensione della chiave richiesta non è supportata". Con .NET Framework 4.6.2 questo problema è stato risolto. Analogamente, RSA.ImportParameters() e RSACng.ImportParameters() ora funzionano con dimensioni di chiave non standard senza lanciare CryptographicException's.
    • Librerie interessate: mscorlib, System.Core
    • Azione suggerita: assicurarsi che le chiavi RSA funzionino come previsto

  • I controlli dei due punti di percorso sono più rigorosi

    • In .NET Framework 4.6.2 sono state apportate molte modifiche per supportare i percorsi non supportati in precedenza (sia in lunghezza che in formato). I controlli della sintassi corretta del separatore di unità (due punti) sono stati resi più corretti, con l'effetto collaterale del blocco di alcuni percorsi URI in alcune API path selezionate in cui venivano tollerati.
    • Librerie interessate: mscorlib, System.Runtime.Extensions
    • Azione suggerita:

  • Chiamate ai costruttori ClaimsIdentity

    • A partire da .NET Framework 4.6.2, è stata apportata una modifica al modo in cui i costruttori di T:System.Security.Claims.ClaimsIdentity con un parametro T:System.Security.Principal.IIdentity impostano la proprietà P:System.Security.Claims.ClaimsIdentify.Actor. Se l'argomento T:System.Security.Principal.IIdentity è un oggetto T:System.Security.Claims.ClaimsIdentity e la proprietà P:System.Security.Claims.ClaimsIdentify.Actor di tale oggetto T:System.Security.Claims.ClaimsIdentity non è null, la proprietà P:System.Security.Claims.ClaimsIdentify.Actor viene associata utilizzando il metodo M:System.Security.Claims.ClaimsIdentity.Clone. In Framework 4.6.1 e versioni precedenti la proprietà P:System.Security.Claims.ClaimsIdentify.Actor è associata come riferimento esistente. A causa di questa modifica, a partire da .NET Framework 4.6.2, la proprietà P:System.Security.Claims.ClaimsIdentify.Actor del nuovo oggetto T:System.Security.Claims.ClaimsIdentity non è uguale alla proprietà P:System.Security.Claims.ClaimsIdentify.Actor dell'argomento T:System.Security.Principal.IIdentity del costruttore. In .NET Framework 4.6.1 e versioni precedenti è uguale.
    • Librerie interessate: mscorlib
    • Azione suggerita: verificare che ClaimsIdentity funzioni come previsto nel nuovo runtime

  • La serializzazione dei caratteri di controllo con DataContractJsonSerializer è ora compatibile con ECMAScript V6 e V8

    • In .NET Framework 4.6.2 e versioni precedenti, DataContractJsonSerializer non serializza alcuni caratteri di controllo speciali, ad esempio \b, \f e \t, in modo compatibile con gli standard ECMAScript V6 e V8. A partire da .NET Framework 4.7, la serializzazione di questi caratteri di controllo è compatibile con ECMAScript V6 e V8.
    • Librerie interessate: System.Runtime.Serialization.Json
    • Azione suggerita: assicurarsi lo stesso comportamento con DataContractJsonSerializer