Azure Data Lake Analytics uppgraderar till .NET Framework v4.7.2

Viktigt

Azure Data Lake Analytics drog sig tillbaka den 29 februari 2024. Läs mer med det här meddelandet.

För dataanalys kan din organisation använda Azure Synapse Analytics eller Microsoft Fabric.

Azure Data Lake Analytics standardkörning uppgraderar från .NET Framework v4.5.2 till .NET Framework v4.7.2. Den här ändringen medför en liten risk för icke-bakåtkompatibla ändringar om U-SQL-koden använder anpassade sammansättningar, och de anpassade sammansättningarna använder .NET-bibliotek.

Den här uppgraderingen från .NET Framework 4.5.2 till version 4.7.2 innebär att .NET Framework distribueras i en U-SQL-körning (standardkörningen) nu alltid är 4.7.2. Det finns inget alternativ sida vid sida för .NET Framework versioner.

När den här uppgraderingen till .NET Framework 4.7.2 är klar körs systemets hanterade kod som version 4.7.2. Användardefinierade bibliotek som U-SQL-anpassade sammansättningar körs i det bakåtkompatibla läge som är lämpligt för den version som sammansättningen har genererats för.

• Om dina sammansättnings-DLL:er genereras för version 4.5.2 behandlar det distribuerade ramverket dem som 4.5.2-bibliotek, vilket ger (med några få undantag) 4.5.2-semantik.
• Nu kan du använda U-SQL-anpassade sammansättningar som använder funktionerna i version 4.7.2, om du riktar in dig på .NET Framework 4.7.2.

På grund av den här uppgraderingen till .NET Framework 4.7.2 finns det en potential att införa icke-bakåtkompatibla ändringar i dina U-SQL-jobb som använder anpassade .NET-sammansättningar. Vi rekommenderar att du söker efter problem med bakåtkompatibilitet med hjälp av proceduren nedan.

Så här söker du efter problem med bakåtkompatibilitet

Kontrollera risken för problem med bakåtkompatibilitetsproblem genom att köra .NET-kompatibilitetskontrollerna på .NET-koden i dina anpassade U-SQL-sammansättningar.

Anteckning

Verktyget identifierar inte faktiska icke-bakåtkompatibla ändringar. den identifierar endast .NET-API:er som (för vissa indata) kan orsaka problem. Om du får ett meddelande om ett problem kan koden fortfarande vara bra, men du bör checka in mer information.

1. Kör bakåtkompatibilitetskontrollen på dina .NET-DLL:er antingen genom att
   1. Använda Visual Studio-tillägget på .NET Portability Analyzer Visual Studio-tillägget
   2. Ladda ned och använda det fristående verktyget från GitHub dotnetapiport. Instruktioner för att köra fristående verktyg finns på GitHub dotnetapiport icke-bakåtkompatibla ändringar
   3. För 4.7.2. kompatibilitet identifierar read isRetargeting == True möjliga problem.
2. Om verktyget anger om koden kan påverkas av någon av de möjliga bakåtkompatibiliteterna (några vanliga exempel på inkompatibiliteter visas nedan), kan du kontrollera genom att
   1. Analysera koden och identifiera om koden skickar värden till de påverkade API:erna
   2. Utför en körningskontroll. Körningsdistributionen görs inte sida vid sida i ADLA. Du kan utföra en körningskontroll före uppgraderingen med hjälp av VisualStudios lokala körning med en lokal .NET Framework 4.7.2 mot en representativ datauppsättning.
3. Om du verkligen påverkas av en bakåtkompatibel, vidta nödvändiga åtgärder för att åtgärda det (till exempel att åtgärda dina data eller kodlogik).

I de flesta fall bör du inte påverkas av bakåtkompatibel.

Tidslinje

Du kan söka efter distributionen av den nya körningen här Runtime-felsökningen och genom att titta på alla tidigare lyckade jobb.

Vad händer om jag inte kan få min kod granskad i tid

Du kan skicka jobbet mot den gamla körningsversionen (som har skapats med 4.5.2 som mål), men på grund av bristen på .NET Framework funktioner sida vid sida körs det fortfarande bara i 4.5.2-kompatibilitetsläge. Du kan fortfarande stöta på några problem med bakåtkompatibilitet på grund av det här beteendet.

Vilka är de vanligaste problem med bakåtkompatibilitet som kan uppstå

De vanligaste bakåtkompatibiliseringarna som kontrollen sannolikt kommer att identifiera är (vi genererade den här listan genom att köra kontrollen på våra egna interna ADLA-jobb), vilka bibliotek som påverkas (observera: att du kan anropa biblioteken endast indirekt, vilket innebär att det är viktigt att vidta nödvändiga åtgärder #1 för att kontrollera om dina jobb påverkas) och möjliga åtgärder att åtgärda. Obs! I nästan alla fall för våra egna jobb visade sig varningarna vara falska positiva på grund av de smalaste förändringarna.

• Egenskapen IAsyncResult.CompletedSynchronously måste vara korrekt för att den resulterande uppgiften ska slutföras

  • När du anropar TaskFactory.FromAsync måste implementeringen av egenskapen IAsyncResult.CompletedSynchronously vara korrekt för att den resulterande aktiviteten ska slutföras. Det innebär att egenskapen måste returnera sant om, och endast om, implementeringen slutfördes synkront. Tidigare kontrollerades inte egenskapen.
  • Påverkade bibliotek: mscorlib, System.Threading.Tasks
  • Föreslagen åtgärd: Se till att TaskFactory.FromAsync returnerar sant korrekt

• DataObject.GetData hämtar nu data som UTF-8

  • För appar som är inriktade på .NET Framework 4 eller som körs på .NET Framework 4.5.1 eller tidigare versioner hämtar DataObject.GetData HTML-formaterade data som en ASCII-sträng. Därför representeras icke-ASCII-tecken (tecken vars ASCII-koder är större än 0x7F) av två slumpmässiga tecken.#N##N#For appar som riktar sig mot .NET Framework 4.5 eller senare och körs på .NET Framework 4.5.2, DataObject.GetData hämtar HTML-formaterade data som UTF-8, vilket representerar tecken som är större än 0x7F korrekt.
  • Påverkade bibliotek: Glo
  • Föreslagen åtgärd: Kontrollera att data som hämtas är det format som du vill ha

• XmlWriter genererar ogiltiga surrogatpar

  • För appar som riktar sig till .NET Framework 4.5.2 eller tidigare versioner utlöser det inte alltid något undantag att skriva ett ogiltigt surrogatpar med undantagsåterställningshantering. För appar som är inriktade på .NET Framework 4.6 genererar försök att skriva ett ogiltigt surrogatpar ett ArgumentException.
  • Påverkade bibliotek: System.Xml, System.Xml. Läsare
  • Föreslagen åtgärd: Kontrollera att du inte skriver ett ogiltigt surrogatpar som orsakar argumentfel

• HtmlTextWriter renderar <br/> inte elementet korrekt

  • Från och med .NET Framework 4.6 infogas endast ett <BR /> (i stället för två) genom att anropa HtmlTextWriter.RenderBeginTag() och HtmlTextWriter.RenderEndTag() med ett <BR /> element korrekt
  • Påverkade bibliotek: System.Web
  • Föreslagen åtgärd: Se till att du infogar den mängd som <BR /> du förväntar dig att se så att inget slumpmässigt beteende visas i produktionsjobbet

• Anropar CreateDefaultAuthorizationContext med ett null-argument har ändrats

  • Implementeringen av AuthorizationContext som returnerades av ett anrop till CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argumentet med null authorizationPolicies har ändrat dess implementering i .NET Framework 4.6.
  • Påverkade bibliotek: System.IdentityModel
  • Föreslagen åtgärd: Se till att du hanterar det nya förväntade beteendet när det finns en princip för null-auktorisering

• RSACng läser nu in RSA-nycklar med icke-standardnyckelstorlek

  • I .NET Framework versioner före 4.6.2 kan kunder med icke-standardnyckelstorlekar för RSA-certifikat inte komma åt dessa nycklar via tilläggsmetoderna GetRSAPublicKey() och GetRSAPrivateKey() . A CryptographicException med meddelandet "Den begärda nyckelstorleken stöds inte" genereras. Med .NET Framework 4.6.2 har det här problemet åtgärdats. RSA.ImportParameters() På samma sätt, och RSACng.ImportParameters() nu arbeta med icke-standard nyckelstorlekar utan att kasta CryptographicException's.
  • Påverkade bibliotek: mscorlib, System.Core
  • Föreslagen åtgärd: Kontrollera att RSA-nycklar fungerar som förväntat

• Sökvägskolonkontroller är strängare

  • I .NET Framework 4.6.2 gjordes många ändringar för att stödja sökvägar som tidigare inte stöds (både i längd och format). Kontroller av rätt syntax för enhetsavgränsare (kolon) har korrigerats, vilket hade sidoeffekten att blockera vissa URI-sökvägar i några få välja Sökvägs-API:er där de tidigare tolererades.
  • Påverkade bibliotek: mscorlib, System.Runtime.Extensions
  • Föreslagen åtgärd:

• Anrop till ClaimsIdentity-konstruktorer

  • Från och med .NET Framework 4.6.2 ändras hur T:System.Security.Claims.ClaimsIdentity konstruktorer med en T:System.Security.Principal.IIdentity parameter anger P:System.Security.Claims.ClaimsIdentify.Actor egenskapen. T:System.Security.Principal.IIdentity Om argumentet är ett T:System.Security.Claims.ClaimsIdentity objekt och P:System.Security.Claims.ClaimsIdentify.Actor egenskapen för objektet T:System.Security.Claims.ClaimsIdentity inte nullär , P:System.Security.Claims.ClaimsIdentify.Actor kopplas egenskapen med hjälp M:System.Security.Claims.ClaimsIdentity.Clone av metoden . I Framework 4.6.1 och tidigare versioner P:System.Security.Claims.ClaimsIdentify.Actor kopplas egenskapen som en befintlig referens. På grund av den här ändringen, från och med .NET Framework 4.6.2, P:System.Security.Claims.ClaimsIdentify.Actor är egenskapen för det nya T:System.Security.Claims.ClaimsIdentity objektet inte lika med egenskapen för P:System.Security.Claims.ClaimsIdentify.Actor konstruktorns T:System.Security.Principal.IIdentity argument. I .NET Framework 4.6.1 och tidigare versioner är den lika med.
  • Påverkade bibliotek: mscorlib
  • Föreslagen åtgärd: Se till att ClaimsIdentity fungerar som förväntat vid ny körning

• Serialisering av kontrolltecken med DataContractJsonSerializer är nu kompatibel med ECMAScript V6 och V8

  • I .NET Framework 4.6.2 och tidigare versioner serialiserade DataContractJsonSerializer inte vissa specialkontrolltecken, till exempel \b, \f och \t, på ett sätt som var kompatibelt med ECMAScript V6- och V8-standarderna. Från och med .NET Framework 4.7 är serialiseringen av dessa kontrolltecken kompatibel med ECMAScript V6 och V8.
  • Påverkade bibliotek: System.Runtime.Serialization.Json
  • Föreslagen åtgärd: Kontrollera samma beteende med DataContractJsonSerializer