Usługa Azure Data Lake Analytics jest uaktualniona do wersji .NET Framework 4.7.2

Ważne

Usługa Azure Data Lake Analytics została wycofana 29 lutego 2024 r. Dowiedz się więcej z tym ogłoszeniem.

W przypadku analizy danych organizacja może używać Azure Synapse Analytics lub Microsoft Fabric.

Domyślne środowisko uruchomieniowe platformy Azure Data Lake Analytics jest uaktualniane z wersji .NET Framework w wersji 4.5.2 do .NET Framework w wersji 4.7.2. Ta zmiana wprowadza niewielkie ryzyko wystąpienia zmian powodujących niezgodność, jeśli kod U-SQL używa zestawów niestandardowych, a te zestawy niestandardowe używają bibliotek platformy .NET.

To uaktualnienie z .NET Framework 4.5.2 do wersji 4.7.2 oznacza, że .NET Framework wdrożony w środowisku uruchomieniowym U-SQL (domyślnym środowisku uruchomieniowym) będzie teraz zawsze 4.7.2. Nie ma opcji równoległej dla wersji .NET Framework.

Po zakończeniu uaktualniania do wersji .NET Framework 4.7.2 kod zarządzany systemu zostanie uruchomiony jako wersja 4.7.2, biblioteki udostępnione przez użytkownika, takie jak zestawy niestandardowe U-SQL, będą uruchamiane w trybie zgodnym z poprzednimi wersjami dla wersji, dla której został wygenerowany zestaw.

• Jeśli biblioteki DLL zestawu są generowane dla wersji 4.5.2, wdrożona struktura będzie traktować je jako biblioteki 4.5.2, zapewniając (z kilkoma wyjątkami) semantyka 4.5.2.
• Teraz możesz użyć niestandardowych zestawów U-SQL, które korzystają z funkcji w wersji 4.7.2, jeśli jest przeznaczony dla .NET Framework 4.7.2.

Ze względu na to uaktualnienie do wersji .NET Framework 4.7.2 istnieje możliwość wprowadzenia zmian powodujących niezgodność zadań U-SQL korzystających z zestawów niestandardowych platformy .NET. Zalecamy sprawdzenie problemów ze zgodnością z poprzednimi wersjami, korzystając z poniższej procedury.

Jak sprawdzić problemy ze zgodnością z poprzednimi wersjami

Sprawdź potencjalne problemy powodujące niezgodność z poprzednimi wersjami, uruchamiając testy zgodności platformy .NET w kodzie platformy .NET w niestandardowych zestawach U-SQL.

Uwaga

Narzędzie nie wykrywa rzeczywistych zmian powodujących niezgodność. identyfikuje tylko nazywane interfejsami API platformy .NET, które mogą (w przypadku niektórych danych wejściowych) powodować problemy. Jeśli otrzymasz powiadomienie o problemie, kod może nadal być w porządku, jednak należy sprawdzić więcej szczegółów.

1. Uruchom moduł sprawdzania zgodności z poprzednimi wersjami na bibliotekach DLL platformy .NET według
   1. Korzystanie z rozszerzenia programu Visual Studio w rozszerzeniu .NET Portability Analyzer Visual Studio
   2. Pobieranie i używanie autonomicznego narzędzia z witryny GitHub dotnetapiport. Instrukcje dotyczące uruchamiania autonomicznego narzędzia znajdują się w temacie Zmiany powodujące niezgodność w witrynie GitHub dotnetapiport
   3. Dla wersji 4.7.2. zgodność, read isRetargeting == True identyfikuje możliwe problemy.
2. Jeśli narzędzie wskazuje, czy twój kod może mieć wpływ na dowolną z możliwych niezgodności z poprzednimi wersjami (niektóre typowe przykłady niezgodności są wymienione poniżej), możesz dokładniej sprawdzić
   1. Analizowanie kodu i identyfikowanie, czy kod przekazuje wartości do dotkniętych interfejsów API
   2. Wykonaj sprawdzanie środowiska uruchomieniowego. Wdrożenie środowiska uruchomieniowego nie jest wykonywane równolegle w usłudze ADLA. Przed uaktualnieniem można przeprowadzić sprawdzanie środowiska uruchomieniowego przy użyciu lokalnego uruchomienia programu VisualStudio z lokalnym .NET Framework 4.7.2 względem reprezentatywnego zestawu danych.
3. Jeśli rzeczywiście masz wpływ na niezgodność z poprzednimi wersjami, wykonaj niezbędne kroki, aby je naprawić (takie jak naprawianie danych lub logiki kodu).

W większości przypadków nie należy wpływać na niezgodność z poprzednimi wersjami.

Oś czasu

Możesz sprawdzić wdrożenie nowego środowiska uruchomieniowego tutaj Rozwiązywanie problemów ze środowiskiem uruchomieniowym i przeglądając wcześniejsze pomyślne zadanie.

Co zrobić, jeśli nie mogę przejrzeć kodu w czasie

Zadanie można przesłać do starej wersji środowiska uruchomieniowego (która została skompilowana w wersji docelowej 4.5.2), jednak ze względu na brak .NET Framework możliwości równoległych nadal będzie działać tylko w trybie zgodności 4.5.2. Niektóre problemy ze zgodnością z poprzednimi wersjami mogą nadal występować z powodu tego zachowania.

Jakie są najczęstsze problemy ze zgodnością z poprzednimi wersjami, które mogą wystąpić

Najbardziej typowe niezgodności z poprzednimi wersjami, które mogą zostać zidentyfikowane przez moduł sprawdzania, to (wygenerowaliśmy tę listę, uruchamiając narzędzie sprawdzania we własnych wewnętrznych zadaniach usługi ADLA), które biblioteki mają wpływ (należy pamiętać, że biblioteki mogą być wywoływane tylko pośrednio, dlatego ważne jest, aby podjąć wymagane działanie #1, aby sprawdzić, czy twoje zadania mają wpływ) i możliwe działania w celu rozwiązania problemu. Uwaga: W prawie wszystkich przypadkach dla naszych własnych zadań ostrzeżenia okazały się fałszywie dodatnie ze względu na wąskie charaktery większości przełomowych zmian.

• Właściwość IAsyncResult.CompletedSynchronously musi być poprawna, aby wynikowe zadanie zostało ukończone

  • Podczas wywoływania elementu TaskFactory.FromAsync implementacja właściwości IAsyncResult.CompletedSynchronously musi być poprawna, aby wykonać wynikowe zadanie. Oznacza to, że właściwość musi zwracać wartość true, jeśli i tylko wtedy implementacja została ukończona synchronicznie. Wcześniej właściwość nie została sprawdzona.
  • Biblioteki, których to dotyczy: mscorlib, System.Threading.Tasks
  • Sugerowana akcja: upewnij się, że funkcja TaskFactory.FromAsync zwraca wartość true poprawnie

• DataObject.GetData pobiera teraz dane jako UTF-8

  • W przypadku aplikacji przeznaczonych dla .NET Framework 4 lub uruchamianych w .NET Framework 4.5.1 lub starszych wersjach dataObject.GetData pobiera dane w formacie HTML jako ciąg ASCII. W rezultacie znaki inne niż ASCII (znaki, których kody ASCII są większe niż 0x7F) są reprezentowane przez dwa losowe znaki.#N##N#For aplikacje przeznaczone dla .NET Framework 4.5 lub nowszego i uruchamiane w .NET Framework 4.5.2, pobiera dane w formacie HTML w formacie UTF-8, DataObject.GetData które reprezentują znaki większe niż 0x7F.
  • Biblioteki, których to dotyczy: Glo
  • Sugerowana akcja: Upewnij się, że pobrane dane są formatem, który chcesz

• Narzędzie XmlWriter zgłasza nieprawidłowe pary zastępcze

  • W przypadku aplikacji przeznaczonych dla .NET Framework 4.5.2 lub poprzednich wersji pisanie nieprawidłowej pary zastępczej przy użyciu obsługi rezerwowej wyjątków nie zawsze zgłasza wyjątek. W przypadku aplikacji przeznaczonych dla .NET Framework 4.6 próba zapisania nieprawidłowej pary zastępczej zgłasza błąd ArgumentException.
  • Biblioteki, których to dotyczy: System.Xml, System.Xml. ReaderWriter
  • Sugerowana akcja: Upewnij się, że nie piszesz nieprawidłowej pary zastępczej, która spowoduje wyjątek argumentu

• Funkcja HtmlTextWriter nie renderuje <br/> poprawnie elementu

  • Począwszy od .NET Framework 4.6, wywołanie HtmlTextWriter.RenderBeginTag() elementu i HtmlTextWriter.RenderEndTag() element <BR /> poprawnie wstawi tylko jeden <BR /> (zamiast dwóch)
  • Biblioteki, których to dotyczy: System.Web
  • Sugerowana akcja: Upewnij się, że wstawiasz oczekiwaną ilość <BR /> , aby w zadaniu produkcyjnym nie było widoczne żadne losowe zachowanie

• Wywoływanie metody CreateDefaultAuthorizationContext z argumentem null zostało zmienione

  • Implementacja elementu AuthorizationContext zwrócona przez wywołanie CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argumentu authorizationPolicies o wartości null zmieniła jego implementację w .NET Framework 4.6.
  • Biblioteki, których to dotyczy: System.IdentityModel
  • Sugerowana akcja: upewnij się, że obsługujesz nowe oczekiwane zachowanie, gdy istnieją zasady autoryzacji o wartości null

• RsACng teraz poprawnie ładuje klucze RSA o niestandardowym rozmiarze klucza

  • W wersji .NET Framework starszych niż 4.6.2 klienci z niestandardowymi rozmiarami kluczy dla certyfikatów RSA nie mogą uzyskać dostępu do tych kluczy za pośrednictwem GetRSAPublicKey() metod i GetRSAPrivateKey() rozszerzeń. Zgłaszany CryptographicException jest komunikat "Żądany rozmiar klucza nie jest obsługiwany". Rozwiązano .NET Framework 4.6.2. Podobnie, RSA.ImportParameters() a RSACng.ImportParameters() teraz pracować z niestandardowymi rozmiarami kluczy bez zgłaszania CryptographicExceptionwartości "s".
  • Biblioteki, których to dotyczy: mscorlib, System.Core
  • Sugerowana akcja: upewnij się, że klucze RSA działają zgodnie z oczekiwaniami

• Kontrole dwukropka ścieżki są bardziej rygorystyczne

  • W .NET Framework 4.6.2 wprowadzono wiele zmian w celu obsługi wcześniej nieobsługiwanych ścieżek (zarówno długości, jak i formatu). Sprawdzanie prawidłowej składni separatora dysku (dwukropka) było bardziej poprawne, co miało efekt uboczny blokowania niektórych ścieżek URI w kilku wybranych interfejsach API ścieżki, w których były tolerowane.
  • Biblioteki, których to dotyczy: mscorlib, System.Runtime.Extensions
  • Sugerowana akcja:

• Wywołania konstruktorów ClaimsIdentity

  • Począwszy od .NET Framework 4.6.2, istnieje zmiana sposobu, w jaki T:System.Security.Claims.ClaimsIdentity konstruktory z parametrem T:System.Security.Principal.IIdentity ustawić P:System.Security.Claims.ClaimsIdentify.Actor właściwość. T:System.Security.Principal.IIdentity Jeśli argument jest obiektemT:System.Security.Claims.ClaimsIdentity, a P:System.Security.Claims.ClaimsIdentify.Actor właściwość tego T:System.Security.Claims.ClaimsIdentity obiektu nie nulljest , P:System.Security.Claims.ClaimsIdentify.Actor właściwość jest dołączona przy użyciu M:System.Security.Claims.ClaimsIdentity.Clone metody . W programie Framework 4.6.1 i starszych wersjach P:System.Security.Claims.ClaimsIdentify.Actor właściwość jest dołączona jako istniejące odwołanie. Ze względu na tę zmianę, począwszy od .NET Framework 4.6.2, P:System.Security.Claims.ClaimsIdentify.Actor właściwość nowego T:System.Security.Claims.ClaimsIdentity obiektu nie jest równa P:System.Security.Claims.ClaimsIdentify.Actor właściwości argumentu konstruktoraT:System.Security.Principal.IIdentity. W wersji .NET Framework 4.6.1 i starszych jest to równe.
  • Biblioteki, których to dotyczy: mscorlib
  • Sugerowana akcja: upewnij się, że oświadczeniaDentyfikacja działa zgodnie z oczekiwaniami w nowym środowisku uruchomieniowym

• Serializacja znaków kontrolek za pomocą elementu DataContractJsonSerializer jest teraz zgodna z programem ECMAScript V6 i V8

  • W programie .NET Framework 4.6.2 i starszych wersjach moduł DataContractJsonSerializer nie serializował niektórych znaków kontrolek specjalnych, takich jak \b, \f i \t, w sposób zgodny ze standardami ECMAScript V6 i V8. Począwszy od .NET Framework 4.7, serializacja tych znaków kontrolnych jest zgodna z programem ECMAScript V6 i V8.
  • Biblioteki, których to dotyczy: System.Runtime.Serialization.Json
  • Sugerowana akcja: Upewnij się, że takie samo zachowanie jest zachowywane przy użyciu elementu DataContractJsonSerializer