Azure Data Lake Analytics voert een upgrade uit naar de .NET Framework v4.7.2

Belangrijk

Azure Data Lake Analytics op 29 februari 2024 buiten gebruik gesteld. Meer informatie over deze aankondiging.

Voor gegevensanalyse kan uw organisatie gebruikmaken van Azure Synapse Analytics of Microsoft Fabric.

De standaardruntime van Azure Data Lake Analytics voert een upgrade uit van .NET Framework v4.5.2 naar .NET Framework v4.7.2. Deze wijziging leidt tot een klein risico op wijzigingen die fouten veroorzaken als uw U-SQL-code gebruikmaakt van aangepaste assembly's en deze aangepaste assembly's gebruikmaken van .NET-bibliotheken.

Deze upgrade van .NET Framework 4.5.2 naar versie 4.7.2 betekent dat de .NET Framework geïmplementeerd in een U-SQL-runtime (de standaardruntime) nu altijd 4.7.2 is. Er is geen optie naast elkaar voor .NET Framework versies.

Nadat deze upgrade naar .NET Framework 4.7.2 is voltooid, wordt de beheerde code van het systeem uitgevoerd als versie 4.7.2. Door de gebruiker verstrekte bibliotheken, zoals de aangepaste U-SQL-assembly's, worden uitgevoerd in de achterwaarts compatibele modus die geschikt is voor de versie waarvoor de assembly is gegenereerd.

• Als uw assembly-DLL's worden gegenereerd voor versie 4.5.2, behandelt het geïmplementeerde framework deze als 4.5.2-bibliotheken, met (enkele uitzonderingen) 4.5.2-semantiek.
• U kunt nu aangepaste U-SQL-assembly's gebruiken die gebruikmaken van versie 4.7.2-functies als u zich richt op de .NET Framework 4.7.2.

Vanwege deze upgrade naar .NET Framework 4.7.2 is het mogelijk om belangrijke wijzigingen aan te brengen in uw U-SQL-taken die gebruikmaken van aangepaste .NET-assembly's. We raden u aan om te controleren op compatibiliteitsproblemen met eerdere versies met behulp van de onderstaande procedure.

Controleren op compatibiliteitsproblemen met eerdere versies

Controleer op mogelijke problemen met achterwaartse compatibiliteit door de .NET-compatibiliteitscontroles uit te voeren op uw .NET-code in uw aangepaste U-SQL-assembly's.

Notitie

Het hulpprogramma detecteert geen werkelijke wijzigingen die fouten veroorzaken. het identificeert alleen aangeroepen .NET-API's die (voor bepaalde invoer) problemen kunnen veroorzaken. Als u op de hoogte wordt gesteld van een probleem, is uw code mogelijk nog steeds in orde, maar u moet meer details inchecken.

1. Voer de achterwaartse compatibiliteitscontrole uit op uw .NET DLL's door
   1. De Visual Studio-extensie op .NET Portability Analyzer Visual Studio-extensie gebruiken
   2. Het downloaden en gebruiken van het zelfstandige hulpprogramma van GitHub dotnetapiport. Instructies voor het uitvoeren van een zelfstandig hulpprogramma staan op GitHub dotnetapiport die wijzigingen veroorzaken die fouten veroorzaken
   3. Voor 4.7.2. compatibiliteit, read isRetargeting == True identificeert mogelijke problemen.
2. Als het hulpprogramma aangeeft of uw code kan worden beïnvloed door een van de mogelijke achterwaartse incompatibiliteit (enkele veelvoorkomende voorbeelden van incompatibiliteit worden hieronder vermeld), kunt u dit verder controleren door
   1. Uw code analyseren en bepalen of uw code waarden doorgeeft aan de betrokken API's
   2. Voer een runtime-controle uit. De runtime-implementatie wordt niet naast elkaar uitgevoerd in ADLA. U kunt vóór de upgrade een runtimecontrole uitvoeren met behulp van de lokale uitvoering van VisualStudio met een lokale .NET Framework 4.7.2 voor een representatieve gegevensset.
3. Als u inderdaad last hebt van een achterwaartse incompatibiliteit, voert u de benodigde stappen uit om dit op te lossen (zoals het herstellen van uw gegevens of codelogica).

In de meeste gevallen moet u niet worden beïnvloed door incompatibiliteit met eerdere versies.

Tijdlijn

U kunt controleren op de implementatie van de nieuwe runtime hier Problemen met runtime oplossen en door te kijken naar eventuele eerdere geslaagde taken.

Wat gebeurt er als ik mijn code niet op tijd kan laten controleren

U kunt uw taak indienen voor de oude runtimeversie (die is gebouwd met als doel 4.5.2), maar vanwege het ontbreken van .NET Framework mogelijkheden naast elkaar, wordt deze nog steeds alleen uitgevoerd in de compatibiliteitsmodus 4.5.2. Als gevolg van dit gedrag kunnen er nog steeds problemen optreden met de compatibiliteit met eerdere versies.

Wat zijn de meest voorkomende achterwaartse compatibiliteitsproblemen die u kunt tegenkomen

De meest voorkomende achterwaartse incompatibiliteit die de controlefunctie waarschijnlijk identificeert zijn (we hebben deze lijst gegenereerd door de controle uit te voeren op onze eigen interne ADLA-taken), welke bibliotheken worden beïnvloed (opmerking: u kunt de bibliotheken alleen indirect aanroepen, dus het is belangrijk om de vereiste actie 1 uit te voeren om te controleren of uw taken worden beïnvloed) en mogelijke acties om dit op te lossen. Opmerking: In bijna alle gevallen voor onze eigen taken bleken de waarschuwingen fout-positieven te zijn vanwege de beperkte aard van de meeste belangrijke wijzigingen.

• De eigenschap IAsyncResult.CompletedSynchronously moet juist zijn om de resulterende taak te voltooien

  • Wanneer u TaskFactory.FromAsync aanroept, moet de implementatie van de eigenschap IAsyncResult.CompletedSynchronously juist zijn om de resulterende taak te voltooien. Dat wil gezegd dat de eigenschap true moet retourneren als, en alleen als, de implementatie synchroon is voltooid. Voorheen is de eigenschap niet gecontroleerd.
  • Betrokken bibliotheken: mscorlib, System.Threading.Tasks
  • Voorgestelde actie: Zorg ervoor dat TaskFactory.FromAsync correct waar retourneert

• DataObject.GetData haalt nu gegevens op als UTF-8

  • Voor apps die gericht zijn op de .NET Framework 4 of die worden uitgevoerd op de .NET Framework 4.5.1 of eerdere versies, haalt DataObject.GetData HTML-opgemaakte gegevens op als een ASCII-tekenreeks. Als gevolg hiervan worden niet-ASCII-tekens (tekens waarvan de ASCII-codes groter zijn dan 0x7F) vertegenwoordigd door twee willekeurige tekens.#N##N#For apps die gericht zijn op de .NET Framework 4.5 of hoger en worden uitgevoerd op de .NET Framework 4.5.2, DataObject.GetData worden gegevens in HTML-indeling opgehaald als UTF-8, wat tekens vertegenwoordigt die groter zijn dan 0x7F juist.
  • Betrokken bibliotheken: glo
  • Voorgestelde actie: Zorg ervoor dat de opgehaalde gegevens de gewenste indeling hebben

• XmlWriter genereert ongeldige surrogaatparen

  • Voor apps die gericht zijn op de .NET Framework 4.5.2 of eerdere versies, genereert het schrijven van een ongeldig surrogaatpaar met behulp van uitzonderingsterugvalverwerking niet altijd een uitzondering. Voor apps die gericht zijn op de .NET Framework 4.6, genereert een poging om een ongeldig surrogaatpaar te schrijven een ArgumentException.
  • Betrokken bibliotheken: System.Xml, System.Xml. ReaderWriter
  • Voorgestelde actie: zorg ervoor dat u geen ongeldig surrogaatpaar schrijft dat een argumentuitzondering veroorzaakt

• HtmlTextWriter geeft het element niet correct weer <br/>

  • Vanaf de .NET Framework 4.6 wordt aanroepen HtmlTextWriter.RenderBeginTag() en HtmlTextWriter.RenderEndTag() met een <BR /> -element slechts één <BR /> correct ingevoegd (in plaats van twee)
  • Betrokken bibliotheken: System.Web
  • Voorgestelde actie: zorg ervoor dat u de hoeveelheid invoegt die <BR /> u verwacht te zien, zodat er geen willekeurig gedrag wordt gezien in de productietaak

• Het aanroepen van CreateDefaultAuthorizationContext met een null-argument is gewijzigd

  • De implementatie van de AuthorizationContext die wordt geretourneerd door een aanroep naar de CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) met het argument null authorizationPolicies, heeft de implementatie gewijzigd in de .NET Framework 4.6.
  • Betrokken bibliotheken: System.IdentityModel
  • Voorgestelde actie: Zorg ervoor dat u het nieuwe verwachte gedrag verwerkt wanneer er een null-autorisatiebeleid is

• RSACng laadt nu correct RSA-sleutels van niet-standaardsleutelgrootte

  • In .NET Framework versies ouder dan 4.6.2 hebben klanten met niet-standaardsleutelgrootten voor RSA-certificaten geen toegang tot deze sleutels via de GetRSAPublicKey() extensiemethoden enGetRSAPrivateKey(). Een CryptographicException met het bericht 'De aangevraagde sleutelgrootte wordt niet ondersteund' wordt gegenereerd. Met de .NET Framework 4.6.2 is dit probleem opgelost. Op dezelfde manier RSA.ImportParameters()RSACng.ImportParameters() kunt u nu werken met niet-standaardsleutelgrootten zonder te gooien CryptographicException.
  • Betrokken bibliotheken: mscorlib, System.Core
  • Voorgestelde actie: controleren of RSA-sleutels werken zoals verwacht

• Controles van padkomma's zijn strenger

  • In .NET Framework 4.6.2 zijn veel wijzigingen aangebracht om eerder niet-ondersteunde paden te ondersteunen (zowel in lengte als indeling). Controles op de juiste syntaxis van het stationscheidingsteken (dubbele punt) zijn correcter gemaakt, wat het neveneffect had van het blokkeren van sommige URI-paden in een paar geselecteerde pad-API's waar ze voorheen werden getolereerd.
  • Betrokken bibliotheken: mscorlib, System.Runtime.Extensions
  • Voorgestelde actie:

• Aanroepen van ClaimsIdentity-constructors

  • Vanaf de .NET Framework 4.6.2 is er een wijziging in de wijze waarop T:System.Security.Claims.ClaimsIdentity constructors met een T:System.Security.Principal.IIdentity parameter de P:System.Security.Claims.ClaimsIdentify.Actor eigenschap instellen. Als het T:System.Security.Principal.IIdentity argument een T:System.Security.Claims.ClaimsIdentity object is en de P:System.Security.Claims.ClaimsIdentify.Actor eigenschap van dat T:System.Security.Claims.ClaimsIdentity object niet nullis, wordt de P:System.Security.Claims.ClaimsIdentify.Actor eigenschap gekoppeld met behulp van de M:System.Security.Claims.ClaimsIdentity.Clone methode . In Framework 4.6.1 en eerdere versies is de P:System.Security.Claims.ClaimsIdentify.Actor eigenschap gekoppeld als een bestaande verwijzing. Vanwege deze wijziging is de eigenschap van het nieuwe T:System.Security.Claims.ClaimsIdentity object vanaf de .NET Framework 4.6.2 P:System.Security.Claims.ClaimsIdentify.Actor niet gelijk aan de eigenschap van het P:System.Security.Claims.ClaimsIdentify.Actor argument van de constructorT:System.Security.Principal.IIdentity. In de .NET Framework 4.6.1 en eerdere versies is dit gelijk.
  • Betrokken bibliotheken: mscorlib
  • Voorgestelde actie: Controleren of ClaimsIdentity werkt zoals verwacht in een nieuwe runtime

• Serialisatie van besturingstekens met DataContractJsonSerializer is nu compatibel met ECMAScript V6 en V8

  • In .NET Framework 4.6.2 en eerdere versies heeft de DataContractJsonSerializer bepaalde speciale besturingstekens, zoals \b, \f en \t, niet geserialiseerd op een manier die compatibel was met de ECMAScript V6- en V8-standaarden. Vanaf de .NET Framework 4.7 is serialisatie van deze besturingstekens compatibel met ECMAScript V6 en V8.
  • Betrokken bibliotheken: System.Runtime.Serialization.Json
  • Voorgestelde actie: Zorg voor hetzelfde gedrag met DataContractJsonSerializer