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

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 modifiche di rilievo se il codice U-SQL usa assembly personalizzati e tali assembly personalizzati usano 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.

Dopo aver completato l'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 eseguiti nella modalità compatibile con le versioni precedenti appropriate per la versione per cui è stato generato l'assembly.

• Se le DLL dell'assembly vengono generate per la versione 4.5.2, il framework distribuito li considera come librerie 4.5.2, fornendo (con alcune eccezioni) la 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 i problemi di compatibilità con le versioni precedenti

Verificare il potenziale di problemi di interruzione della compatibilità con le versioni precedenti eseguendo i controlli di compatibilità .NET nel codice .NET negli assembly personalizzati U-SQL.

1. Eseguire il controllo di compatibilità con le versioni precedenti nelle DLL .NET in base a
   1. Uso dell'estensione di Visual Studio nell'estensione .NET Portability Analyzer Visual Studio
   2. Download e uso dello strumento autonomo da GitHub dotnetapiport. Le istruzioni per l'esecuzione di uno strumento autonomo sono in GitHub dotnetapiport modifiche di rilievo
   3. Per 4.7.2. compatibilità, read isRetargeting == True identifica i possibili problemi.
2. Se lo strumento indica se il codice potrebbe essere influenzato da una qualsiasi delle possibili incompatibilità con le versioni precedenti (alcuni esempi comuni di incompatibilità sono elencati di seguito), è possibile verificare ulteriormente
   1. Analisi del codice e identificazione se il codice passa i valori alle API interessate
   2. Eseguire un controllo di runtime. La distribuzione del runtime non viene eseguita side-by-side in ADLA. È possibile eseguire un controllo di runtime prima dell'aggiornamento usando l'esecuzione locale di VisualStudio con un set di dati rappresentativo .NET Framework 4.7.2 locale.
3. Se effettivamente si è interessati da un'incompatibilità con le versioni precedenti, seguire i passaggi necessari per correggerlo (ad esempio correggere i dati o la logica del codice).

Nella maggior parte dei casi, non è consigliabile influire sull'incompatibilità con le versioni precedenti.

Sequenza temporale

È possibile verificare la distribuzione del nuovo runtime qui Risoluzione dei problemi relativi al runtime e esaminare qualsiasi processo precedentemente riuscito.

Cosa succede se il codice non è stato esaminato in tempo

È possibile inviare il processo alla versione precedente del runtime (che è stata compilata per la versione 4.5.2), tuttavia, a causa della mancanza di funzionalità side-by-side di .NET Framework, verrà comunque eseguita solo in modalità di compatibilità 4.5.2. È comunque possibile che si verifichino alcuni 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 potrebbero verificarsi

Le incompatibilità con le versioni precedenti più comuni che il checker è probabile identificare sono (è possibile generare questo elenco eseguendo il controllo sui processi ADLA interni), sulle librerie interessate (si noti che è possibile chiamare le librerie solo indirettamente, pertanto è importante eseguire l'azione necessaria #1 per verificare se i processi sono interessati) e le azioni possibili per risolvere. Nota: in quasi tutti i casi per i nostri processi, gli avvisi hanno rivelato di essere falsi positivi a causa delle natura ristrette delle modifiche più importanti.

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

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

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

  • Per le app destinate a .NET Framework 4 o che vengono eseguite in .NET Framework 4.5.1 o versioni precedenti, DataObject.GetData recupera dati in formato HTML sotto forma di 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 versioni successive ed eseguite in .NET Framework 4.5.2, recupera i dati formattati HTML come UTF-8, DataObject.GetData 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 per le coppie di surrogati non valide

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

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

  • A partire da .NET Framework 4.6, la chiamata di HtmlTextWriter.RenderBeginTag() e HtmlTextWriter.RenderEndTag() con un elemento <BR /> inserirà correttamente solo un <BR /> (invece di due)
  • Librerie interessate: System.Web
  • Azione suggerita: assicurarsi di inserire la quantità prevista per visualizzare in modo che non venga visualizzato alcun comportamento casuale nel processo di <BR /> produzione

• Modifica della chiamata di CreateDefaultAuthorizationContext con un argomento Null

  • L'implementazione dell'oggetto AuthorizationContext restituito da una chiamata al metodo CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) con un argomento authorizationPolicies è cambiata in .NET Framework 4.6.
  • Librerie interessate: System.IdentityModel
  • Azione suggerita: assicurarsi di gestire il nuovo comportamento previsto quando sono presenti criteri di autorizzazione Null

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

  • Nelle versioni di .NET Framework precedenti alla 4.6.2, i clienti con chiavi di dimensioni non standard per i certificati RSA non possono accedere a queste chiavi tramite i metodi di estensione GetRSAPublicKey() e GetRSAPrivateKey(). Viene generato un CryptographicException oggetto 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 chiave non standard senza generare CryptographicException's.
  • Librerie interessate: mscorlib, System.Core
  • Azione consigliata: assicurarsi che le chiavi RSA funzionino come previsto

• I controlli della presenza di due punti nel percorso sono più severi

  • In .NET Framework 4.6.2 sono state apportate molte modifiche per supportare i percorsi precedentemente non supportati (sia in lunghezza che in formato). I controlli della sintassi corretta del separatore appropriato per le unità (due punti) sono ora più corretti. L'effetto collaterale è però il blocco di alcuni percorsi URI in un gruppo selezionato di API Path in cui l'uso era tollerato.
  • Librerie interessate: mscorlib, System.Runtime.Extensions
  • Azione suggerita:

• Chiamate dei costruttori ClaimsIdentity

  • A partire da .NET Framework 4.6.2, è possibile modificare il modo in cui T:System.Security.Claims.ClaimsIdentity i costruttori con un T:System.Security.Principal.IIdentity parametro impostano la P:System.Security.Claims.ClaimsIdentify.Actor proprietà. 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 allegata usando il metodo M:System.Security.Claims.ClaimsIdentity.Clone. In Framework 4.6.1 e versioni precedenti, la P:System.Security.Claims.ClaimsIdentify.Actor proprietà viene associata come riferimento esistente. A causa di questa modifica, a partire da .NET Framework 4.6.2, la P:System.Security.Claims.ClaimsIdentify.Actor proprietà del nuovo T:System.Security.Claims.ClaimsIdentity oggetto non è uguale alla P:System.Security.Claims.ClaimsIdentify.Actor proprietà dell'argomento del T:System.Security.Principal.IIdentity costruttore. Nelle versioni precedenti e .NET Framework 4.6.1 è uguale.
  • Librerie interessate: mscorlib
  • Azione suggerita: verificare che attestazioni funzionino 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 serializzava 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