Azure Data Lake Analytics upgraduje na .NET Framework verze 4.7.2

Důležité

Azure Data Lake Analytics vyřazena 29. února 2024. Další informace najdete v tomto oznámení.

Pro analýzu dat může vaše organizace používat Azure Synapse Analytics nebo Microsoft Fabric.

Výchozí modul runtime Azure Data Lake Analytics upgraduje z rozhraní .NET Framework verze 4.5.2 na .NET Framework verze 4.7.2. Tato změna přináší malé riziko narušení změn, pokud váš kód U-SQL používá vlastní sestavení a tato vlastní sestavení používají knihovny .NET.

Tento upgrade z rozhraní .NET Framework 4.5.2 na verzi 4.7.2 znamená, že rozhraní .NET Framework nasazené v modulu runtime U-SQL (výchozí modul runtime) bude nyní vždy verze 4.7.2. Pro verze rozhraní .NET Framework neexistuje možnost vedle sebe.

Po dokončení tohoto upgradu na rozhraní .NET Framework 4.7.2 se spravovaný kód systému spustí jako verze 4.7.2. Knihovny poskytnuté uživatelem, jako jsou vlastní sestavení U-SQL, se spustí v zpětně kompatibilním režimu odpovídajícím verzi, pro kterou bylo sestavení vygenerováno.

• Pokud se vaše knihovny DLL sestavení vygenerují pro verzi 4.5.2, nasazená architektura s nimi bude zacházet jako s knihovnami verze 4.5.2 a poskytne (s několika výjimkami) sémantiku 4.5.2.
• Nyní můžete použít vlastní sestavení U-SQL, která využívají funkce verze 4.7.2, pokud cílíte na rozhraní .NET Framework 4.7.2.

Vzhledem k tomuto upgradu na rozhraní .NET Framework 4.7.2 může dojít k zavedení zásadních změn v úlohách U-SQL, které používají vlastní sestavení .NET. Doporučujeme zkontrolovat problémy se zpětnou kompatibilitou pomocí následujícího postupu.

Jak zkontrolovat problémy se zpětnou kompatibilitou

Zkontrolujte potenciální problémy se zpětnou kompatibilitou spuštěním kontrol kompatibility .NET na kódu .NET ve vlastních sestaveních U-SQL.

Poznámka

Nástroj nezjistí skutečné změny způsobující chybu. Identifikuje pouze rozhraní API .NET, která můžou (pro určité vstupy) způsobovat problémy. Pokud dostanete oznámení o problému, váš kód může být stále v pořádku, ale měli byste se podívat na další podrobnosti.

1. Spusťte u knihoven DLL .NET kontrolu zpětné kompatibility.
   1. Použití rozšíření sady Visual Studio v rozšíření .NET Portability Analyzer sady Visual Studio
   2. Stažení a použití samostatného nástroje z GitHubu dotnetapiport. Pokyny pro spuštění samostatného nástroje najdete v tématu Změny způsobující chybu dotnetapiport na GitHubu.
   3. Pro 4.7.2. kompatibilita, read isRetargeting == True identifikuje možné problémy.
2. Pokud nástroj indikuje, jestli by váš kód mohl být ovlivněn některou z možných zpětných nekompatibility (některé běžné příklady nekompatibility jsou uvedeny níže), můžete to dále zkontrolovat podle
   1. Analýza kódu a identifikace, jestli kód předává hodnoty ovlivněným rozhraním API
   2. Proveďte kontrolu za běhu. Nasazení modulu runtime se v ADLA neprovedlo vedle sebe. Před upgradem můžete provést kontrolu modulu runtime pomocí místního spuštění sady VisualStudio s místním rozhraním .NET Framework 4.7.2 pro reprezentativní sadu dat.
3. Pokud vás skutečně ovlivňuje zpětná nekompatibilita, proveďte potřebné kroky k jeho opravě (například oprava dat nebo logiky kódu).

Ve většině případů byste neměli být ovlivněni zpětnou nekompatibilitou.

Časová osa

Nasazení nového modulu runtime můžete zkontrolovat tady : Řešení potíží s modulem Runtime a projděte si všechny předchozí úspěšné úlohy.

Co když se mi nedaří kód zkontrolovat včas

Úlohu můžete odeslat ve staré verzi modulu runtime (která je vytvořená na verzi 4.5.2), ale vzhledem k nedostatku souběžných funkcí rozhraní .NET Framework bude stále běžet pouze v režimu kompatibility verze 4.5.2. Kvůli tomuto chování se stále můžete setkat s některými problémy se zpětnou kompatibilitou.

Jaké jsou nejčastější problémy se zpětnou kompatibilitou, se kterými se můžete setkat?

Nejběžnější zpětné nekompatibility, které kontrolní nástroj pravděpodobně identifikuje, jsou (tento seznam jsme vygenerovali spuštěním kontroly u vlastních interních úloh ADLA), kterých se to týká knihoven (poznámka: knihovny můžete volat jenom nepřímo, proto je důležité provést požadovanou akci č. 1, abyste zkontrolovali, jestli jsou ovlivněné vaše úlohy) a možné akce k nápravě. Poznámka: Téměř ve všech případech pro naše vlastní pracovní pozice se upozornění ukázala jako falešně pozitivní kvůli úzké povaze většiny zásadních změn.

• Vlastnost IAsyncResult.CompletedSynchronously musí být správná, aby se výsledný úkol dokončil.

  • Při volání TaskFactory.FromAsync musí být implementace vlastnosti IAsyncResult.CompletedSynchronously správná, aby se výsledný úkol dokončil. To znamená, že vlastnost musí vrátit hodnotu true, pokud a pouze pokud se implementace dokončila synchronně. Dříve se vlastnost nekontrolovala.
  • Ovlivněné knihovny: mscorlib, System.Threading.Tasks
  • Navrhovaná akce: Ujistěte se, že TaskFactory.FromAsync správně vrací hodnotu true.

• DataObject.GetData teď načítá data jako UTF-8.

  • U aplikací, které cílí na rozhraní .NET Framework 4 nebo které běží v rozhraní .NET Framework 4.5.1 nebo starších verzích, data data ve formátu HTML načte jako řetězec ASCII. V důsledku toho jsou znaky jiné než ASCII (znaky, jejichž kódy ASCII jsou větší než 0x7F) reprezentovány dvěma náhodnými znaky.#N##N#For aplikace, které cílí na rozhraní .NET Framework 4.5 nebo novější a běží na rozhraní .NET Framework 4.5.2, DataObject.GetData načte data ve formátu HTML jako UTF-8, což představuje znaky větší než 0x7F správně.
  • Ovlivněné knihovny: Glo
  • Navrhovaná akce: Ujistěte se, že načtená data mají požadovaný formát.

• XmlWriter vyvolá na neplatné náhradní páry

  • U aplikací, které cílí na rozhraní .NET Framework 4.5.2 nebo předchozí verze, nemusí zápis neplatného náhradního páru s využitím náhradního zpracování výjimek vždy vyvolat výjimku. U aplikací, které cílí na rozhraní .NET Framework 4.6, vyvolá pokus o zápis neplatného náhradního páru chybu ArgumentException.
  • Ovlivněné knihovny: System.Xml, System.Xml. ReaderWriter
  • Navrhovaná akce: Ujistěte se, že nepíšete neplatný náhradní pár, který způsobí výjimku argumentu.

• HtmlTextWriter nevykresluje <br/> správně element

  • Počínaje rozhraním .NET Framework 4.6, volání HtmlTextWriter.RenderBeginTag() a HtmlTextWriter.RenderEndTag() s elementem <BR /> správně vloží pouze jeden <BR /> (místo dvou).
  • Ovlivněné knihovny: System.Web
  • Navrhovaná akce: Ujistěte se, že vkládáte očekávané množství <BR /> , aby se v produkční úloze nechodilo žádné náhodné chování.

• Volání Metody CreateDefaultAuthorizationContext s argumentem null se změnilo.

  • Implementace AuthorizationContext vrácená voláním CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argumentu s hodnotou null authorizationPolicies změnila jeho implementaci v rozhraní .NET Framework 4.6.
  • Ovlivněné knihovny: System.IdentityModel
  • Navrhovaná akce: Ujistěte se, že zpracováváte nové očekávané chování, pokud existují zásady autorizace s hodnotou null.

• RSACng teď správně načte klíče RSA nestandardní velikosti klíče

  • Ve verzích rozhraní .NET Framework starších než 4.6.2 nemají zákazníci s nestandardními velikostmi klíčů pro certifikáty RSA přístup k těmto klíčům prostřednictvím GetRSAPublicKey() metod rozšíření a GetRSAPrivateKey() . Vyvolá CryptographicException se zpráva "Požadovaná velikost klíče není podporovaná". V rozhraní .NET Framework 4.6.2 byl tento problém opraven. Podobně RSA.ImportParameters() a RSACng.ImportParameters() teď můžete pracovat s nestandardními velikostmi klíčů bez vyvolání CryptographicExceptionkláves.
  • Ovlivněné knihovny: mscorlib, System.Core
  • Navrhovaná akce: Ujistěte se, že klíče RSA fungují podle očekávání.

• Kontroly dvojtečky cest jsou přísnější.

  • V rozhraní .NET Framework 4.6.2 bylo provedeno mnoho změn pro podporu dříve nepodporovaných cest (délkou i formátem). Kontroly správné syntaxe oddělovače jednotek (dvojtečky) byly správnější, což mělo vedlejší účinek blokování některých cest URI v několika vybraných rozhraních API cest, kde byly tolerovány.
  • Ovlivněné knihovny: mscorlib, System.Runtime.Extensions
  • Navrhovaná akce:

• Volání konstruktorů ClaimsIdentity

  • Počínaje rozhraním .NET Framework 4.6.2 došlo ke změně způsobu, jakým T:System.Security.Claims.ClaimsIdentity konstruktory s parametrem T:System.Security.Principal.IIdentity nastavují P:System.Security.Claims.ClaimsIdentify.Actor vlastnost. T:System.Security.Principal.IIdentity Pokud je argument objekt a T:System.Security.Claims.ClaimsIdentityP:System.Security.Claims.ClaimsIdentify.Actor vlastnost tohoto objektu T:System.Security.Claims.ClaimsIdentity není null, P:System.Security.Claims.ClaimsIdentify.Actor vlastnost je připojena pomocí M:System.Security.Claims.ClaimsIdentity.Clone metody . V frameworku 4.6.1 a starších verzích P:System.Security.Claims.ClaimsIdentify.Actor je vlastnost připojena jako existující odkaz. Z důvodu této změny počínaje rozhraním .NET Framework 4.6.2 se P:System.Security.Claims.ClaimsIdentify.Actor vlastnost nového T:System.Security.Claims.ClaimsIdentity objektu nerovná P:System.Security.Claims.ClaimsIdentify.Actor vlastnosti argumentu konstruktoru T:System.Security.Principal.IIdentity . V rozhraní .NET Framework 4.6.1 a starších verzích je stejný.
  • Ovlivněné knihovny: mscorlib
  • Navrhovaná akce: Ujistěte se, že identita ClaimsIdentity funguje v novém modulu runtime podle očekávání.

• Serializace řídicích znaků pomocí DataContractJsonSerializer je nyní kompatibilní s ECMAScript v6 a V8

  • V rozhraní .NET Framework 4.6.2 a starších verzích dataContractJsonSerializer ne serializoval některé speciální řídicí znaky, například \b, \f a \t způsobem, který byl kompatibilní se standardy ECMAScript V6 a V8. Počínaje rozhraním .NET Framework 4.7 je serializace těchto řídicích znaků kompatibilní s ECMAScript verze 6 a V8.
  • Ovlivněné knihovny: System.Runtime.Serialization.Json
  • Navrhovaná akce: Zajištění stejného chování pomocí DataContractJsonSerializer