Zmiany związane z migracją do zmieniania kierowania w ramach .NET Framework 4.6.x

W tym artykule wymieniono problemy ze zgodnością aplikacji wprowadzone w programie .NET Framework 4.6, 4.6.1 i 4.6.2.

.NET framework 4.6

ASP.NET

Funkcja HtmlTextWriter nie renderuje <br/> elementu poprawnie

Szczegóły

Począwszy od .NET Framework 4.6, wywołanie metody RenderBeginTag(String) i RenderEndTag() z elementem <BR /> poprawnie wstawi tylko jeden <BR /> (zamiast dwóch)

Sugestia

Jeśli aplikacja zależy od dodatkowego <BR /> tagu, RenderBeginTag(String) powinna zostać wywołana po raz drugi. Należy pamiętać, że ta zmiana zachowania dotyczy tylko aplikacji przeznaczonych dla programu .NET Framework 4.6 lub nowszego, więc inną opcją jest skierowanie poprzedniej wersji programu .NET Framework w celu uzyskania starego zachowania.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Zagrożone interfejsy API

ClickOnce

Aplikacje opublikowane za pomocą technologii ClickOnce korzystające z certyfikatu podpisywania kodu SHA-256 mogą zakończyć się niepowodzeniem w systemie Windows 2003

Szczegóły

Plik wykonywalny jest podpisany przy użyciu algorytmu SHA256. Wcześniej został podpisany przy użyciu algorytmu SHA1 niezależnie od tego, czy certyfikat podpisywania kodu to SHA-1, czy SHA-256. Dotyczy to:

  • Wszystkie aplikacje utworzone przy użyciu programu Visual Studio 2012 lub nowszego.
  • Aplikacje utworzone przy użyciu programu Visual Studio 2010 lub starszego w systemach z obecnym programem .NET Framework 4.5. Ponadto, jeśli jest obecny program .NET Framework 4.5 lub nowszy, manifest ClickOnce jest również podpisany przy użyciu algorytmu SHA-256 dla certyfikatów SHA-256 niezależnie od wersji programu .NET Framework, względem której został skompilowany.

Sugestia

Zmiana podpisywania pliku wykonywalnego ClickOnce ma wpływ tylko na systemy Windows Server 2003; wymagają zainstalowania KB 938397. Zmiana podpisywania manifestu przy użyciu algorytmu SHA-256 nawet wtedy, gdy aplikacja jest przeznaczona dla programu .NET Framework 4.0 lub starszej wersji, wprowadza zależność środowiska uruchomieniowego od programu .NET Framework 4.5 lub nowszej wersji.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.5
Typ Przekierowanie

Aplikacja ClickOnce obsługuje algorytm SHA-256 w aplikacjach docelowych 4.0

Szczegóły

Wcześniej aplikacja ClickOnce z certyfikatem podpisanym przy użyciu algorytmu SHA-256 wymagałaby obecności programu .NET Framework 4.5 lub nowszego, nawet jeśli aplikacja jest przeznaczona dla wersji 4.0. Teraz aplikacje ClickOnce przeznaczone dla programu .NET Framework 4.0 mogą działać na platformie .NET Framework 4.0, nawet jeśli są podpisane przy użyciu algorytmu SHA-256.

Sugestia

Ta zmiana usuwa tę zależność i umożliwia używanie certyfikatów SHA-256 do podpisywania aplikacji ClickOnce przeznaczonych dla platformy .NET Framework 4 i starszych wersji.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Rdzeń

Przepływ ustawień CurrentCulture i CurrentUICulture przez zadania

Szczegóły

Począwszy od programu .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są przechowywane w System.Threading.ExecutionContext wątku, który kontynuuje przepływ w operacjach asynchronicznych. Oznacza to, że zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture zostaną odzwierciedlone w zadaniach uruchamianych później asynchronicznie. Różni się to od zachowania poprzednich wersji programu .NET Framework (co spowoduje zresetowanie System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture we wszystkich zadaniach asynchronicznych).

Sugestia

Aplikacje, których dotyczy ta zmiana, mogą obejść ją, jawnie ustawiając żądaną operację System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture jako pierwszą operację w zadaniach asynchronicznych. Alternatywnie, poprzednie działanie funkcji (polegające na braku przepływu System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) można wybrać, ustawiając następujący przełącznik zgodności:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ten problem został rozwiązany przez WPF w programie .NET Framework 4.6.2. Naprawiono ją również w programach .NET Framework 4.6, 4.6.1 do KB 3139549. Aplikacje przeznaczone dla platformy .NET Framework 4.6 lub nowszej automatycznie uzyskają odpowiednie zachowanie w aplikacjach WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) zostaną zachowane w operacjach dyspozytora.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Nazwy zdarzeń ETW nie mogą się różnić tylko od sufiksu "Start" lub "Stop"

Szczegóły

W programach .NET Framework 4.6 i 4.6.1 środowisko uruchomieniowe zgłasza wyjątek ArgumentException, gdy dwie nazwy zdarzeń Śledzenia Zdarzeń dla Windows (ETW) różnią się tylko sufiksem „Start” lub „Stop” (tak jak w przypadku, gdy jedno zdarzenie ma nazwę LogUser, a inne LogUserStart). W takim przypadku środowisko uruchomieniowe nie może skonstruować źródła zdarzeń, które nie może emitować żadnego rejestrowania.

Sugestia

Aby zapobiec wyjątkowi, upewnij się, że żadne dwie nazwy zdarzeń nie różnią się tylko sufiksem "Start" lub "Stop". To wymaganie jest usuwane, począwszy od programu .NET Framework 4.6.2; środowisko uruchomieniowe może uściślać nazwy zdarzeń, które różnią się tylko sufiksem "Start" i "Stop".

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Entity Framework

Tworzenie pliku edmx Entity Framework w programie Visual Studio 2013 może zakończyć się niepowodzeniem z powodu błędu MSB4062 w przypadku korzystania z zadań EntityDeploySplit lub EntityClean

Szczegóły

W narzędziach MSBuild 12.0 (dołączonych do programu Visual Studio 2013) zostały zmienione lokalizacje plików programu MSBuild, co powoduje, że starsze pliki obiektów docelowych programu Entity Framework są nieprawidłowe. W wyniku tego zadania EntityDeploySplit i EntityClean kończą się niepowodzeniem, ponieważ nie można odnaleźć Microsoft.Data.Entity.Build.Tasks.dll. Należy pamiętać, że ten problem wynika ze zmiany dotyczącej zestawu narzędzi (MSBuild/VS), a nie ze zmiany w programie .NET Framework. Wystąpi on tylko w przypadku uaktualniania narzędzi dla deweloperów, a nie w przypadku uaktualniania samego programu .NET Framework.

Sugestia

Pliki obiektów docelowych Entity Framework są naprawione do pracy z nowym układem MSBuild począwszy od wersji .NET Framework 4.6. Uaktualnienie do tej wersji platformy Framework rozwiąże ten problem. Alternatywnie można zastosować to obejście do poprawiania bezpośrednio plików obiektów docelowych.

Nazwa/nazwisko Wartość
Scope Główna
Wersja 4.5.1
Typ Przekierowanie

JIT

IL ret nie jest dozwolony w bloku try

Szczegóły

W przeciwieństwie do kompilatora JIT64 just-in-time, RyuJIT (używany w programie .NET Framework 4.6) nie pozwala na instrukcję IL ret w regionie try. Powrót z bloku try jest niedozwolony przez specyfikację ECMA-335 i żaden znany zarządzany w sposób bezpieczny kompilator nie generuje takiego IL. Jednak kompilator JIT64 wykona taki IL, jeśli zostanie wygenerowany przy użyciu Reflection.Emit.

Sugestia

Jeśli aplikacja generuje IL, który zawiera opcode 'ret' w bloku try, aplikacja może być ukierunkowana na .NET Framework 4.5, aby korzystać ze starego JIT i uniknąć tego problemu. Alternatywnie wygenerowany il może zostać zaktualizowany, aby powrócić po regionie try.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Nowy 64-bitowy kompilator JIT w programie .NET Framework 4.6

Szczegóły

Począwszy od programu .NET Framework 4.6, nowy 64-bitowy kompilator JIT jest używany do kompilacji typu just in time. W niektórych przypadkach zgłaszany jest nieoczekiwany wyjątek lub zaobserwowano inne zachowanie niż w przypadku uruchomienia aplikacji przy użyciu kompilatora 32-bitowego lub starszego kompilatora JIT w wersji 64-bitowej. Ta zmiana nie ma wpływu na 32-bitowy kompilator JIT. Znane różnice obejmują następujące elementy:

  • W pewnych warunkach operacja odpakowania może zgłaszać NullReferenceException w trybie kompilacji Release z włączoną optymalizacją.
  • W niektórych przypadkach wykonanie kodu produkcyjnego w dużej treści metody może zgłosić błąd StackOverflowException.
  • W pewnych warunkach struktury przekazywane do metody są traktowane jako typy referencyjne, a nie jako typy wartości w kompilacjach w trybie Release. Jednym z objawów tego problemu jest to, że poszczególne elementy w kolekcji pojawiają się w nieoczekiwanej kolejności.
  • W pewnych warunkach, porównanie wartości UInt16 z ustawionym najwyższym bitem jest niepoprawne, jeśli włączono optymalizację.
  • W pewnych warunkach, szczególnie podczas inicjowania wartości tablicy, inicjowanie pamięci przez OpCodes.Initblk instrukcję IL może zainicjować pamięć z nieprawidłową wartością. Może to skutkować nieobsługiwanym wyjątkiem lub nieprawidłowym wynikiem wyjściowym.
  • W pewnych rzadkich warunkach test bitowy warunkowy może zwrócić nieprawidłową Boolean wartość lub zgłosić wyjątek, jeśli włączono optymalizacje kompilatora.
  • W pewnych warunkach, jeśli instrukcja if jest używana do testowania warunku przed wejściem do bloku try i wyjściem z bloku try, a ten sam warunek jest obliczany w bloku catch lub finally, nowy 64-bitowy kompilator JIT usuwa warunek if z bloku catch lub finally w trakcie optymalizacji kodu. W rezultacie kod wewnątrz instrukcji if w bloku catch lub finally jest wykonywany bezwarunkowo.

Sugestia

Rozwiązanie znanych problemów
Jeśli napotkasz wymienione powyżej problemy, możesz rozwiązać je, wykonując dowolną z następujących czynności:

  • Uaktualnij program .NET Framework do wersji 4.6.2. Nowy kompilator 64-bitowy dołączony do programu .NET Framework 4.6.2 rozwiązuje każde z tych znanych problemów.

  • Upewnij się, że twoja wersja systemu Windows jest aktualna, uruchamiając usługę Windows Update. Aktualizacje do programu .NET Framework 4.6 i 4.6.1 rozwiązują każdy z tych problemów, z wyjątkiem NullReferenceException w operacjach rozpakowywania.

  • Kompiluj przy użyciu starszego 64-bitowego kompilatora JIT. Zobacz sekcję Łagodzenie innych problemów , aby uzyskać więcej informacji na temat tego, jak to zrobić. Łagodzenie innych problemów
    Jeśli wystąpi inna różnica w zachowaniu między kodem skompilowanym ze starszym kompilatorem 64-bitowym i nowym kompilatorem JIT 64-bitowym lub między wersjami debugowania i wydania aplikacji skompilowanymi przy użyciu nowego kompilatora JIT w wersji 64-bitowej, możesz wykonać następujące czynności, aby skompilować aplikację przy użyciu starszego kompilatora JIT w wersji 64-bitowej:

  • Dla poszczególnych aplikacji można dodać < element do pliku konfiguracji aplikacji. Poniższe polecenie wyłącza kompilację przy użyciu nowego 64-bitowego kompilatora JIT, a zamiast tego używa starszego kompilatora JIT w wersji 64-bitowej.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Dla poszczególnych użytkowników można dodać REG_DWORD wartość o nazwie useLegacyJit do HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework klucza rejestru. Wartość 1 umożliwia starszy 64-bitowy kompilator JIT; wartość 0 wyłącza go i włącza nowy 64-bitowy kompilator JIT.

  • Dla poszczególnych maszyn można dodać REG_DWORD wartość o nazwie useLegacyJit do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework klucza rejestru. Wartość 1 umożliwia korzystanie ze starszego kompilatora 64-bitowego JIT; wartość 0 wyłącza ją i włącza nowy 64-bitowy kompilator JIT. Możesz również poinformować nas o problemie, zgłaszając usterkę w programie Microsoft Connect.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Sieć

Walidacja OID certyfikatu EKU

Szczegóły

Począwszy od programu .NET Framework 4.6, klasy SslStream lub ServicePointManager przeprowadzają walidację identyfikatora obiektu rozszerzonego użycia klucza (EKU). Rozszerzenie rozszerzonego użycia klucza (EKU) to kolekcja identyfikatorów obiektów (OID), które wskazują aplikacje używające klucza. Walidacja OID EKU używa zdalnych wywołań zwrotnych certyfikatu, aby upewnić się, że zdalny certyfikat ma odpowiednie OIDy dla zamierzonego celu.

Sugestia

Jeśli ta zmiana jest niepożądana, możesz wyłączyć walidację EKU OID certyfikatu, dodając następujący przełącznik do <AppContextSwitchOverrides> w ` pliku konfiguracji aplikacji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Ważne

To ustawienie jest udostępnione tylko dla zachowania kompatybilności wstecznej. Jego użycie w innych przypadkach nie jest zalecane.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Tylko protokoły Tls 1.0, 1.1 i 1.2 obsługiwane w system.Net.ServicePointManager i System.Net.Security.SslStream

Szczegóły

Począwszy od programu .NET Framework 4.6, ServicePointManager klasy i SslStream mogą używać tylko jednego z następujących trzech protokołów: Tls1.0, Tls1.1 lub Tls1.2. Protokół SSL3.0 i szyfr RC4 nie są obsługiwane.

Sugestia

Zalecane ograniczenie ryzyka polega na uaktualnieniu aplikacji po stronie serwera do protokołu Tls1.0, Tls1.1 lub Tls1.2. Jeśli nie jest to możliwe lub jeśli aplikacje klienckie są uszkodzone, System.AppContext klasa może służyć do rezygnacji z tej funkcji na jeden z dwóch sposobów:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Protokół TLS 1.x domyślnie przekazuje flagę SCH_SEND_AUX_RECORD do bazowego interfejsu API SCHANNEL

Szczegóły

W przypadku korzystania z protokołu TLS 1.x platforma .NET Framework korzysta z bazowego interfejsu API SCHANNEL systemu Windows. Począwszy od programu .NET Framework 4.6, flaga SCH_SEND_AUX_RECORD jest domyślnie przekazywana do SCHANNEL. Powoduje to, że SCHANNEL dzieli dane do zaszyfrowania na dwa oddzielne rekordy: pierwszy jako pojedynczy bajt, a drugi jako n-1 bajtów. W rzadkich przypadkach przerywa to komunikację między klientami a istniejącymi serwerami, które zakładają, że dane znajdują się w jednym rekordzie.

Sugestia

Jeśli ta zmiana przerywa komunikację z istniejącym serwerem, możesz wyłączyć wysyłanie flagi SCH_SEND_AUX_RECORD i przywrócić poprzednie zachowanie nieudzielenia danych na oddzielne rekordy, dodając następujący przełącznik do <AppContextSwitchOverrides> elementu w <runtime> sekcji pliku konfiguracji aplikacji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Ważne

To ustawienie jest udostępnione tylko dla zachowania kompatybilności wstecznej. Jego użycie w innych przypadkach nie jest zalecane.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Windows Communication Foundation (WCF)

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

Szczegóły

Implementacja System.IdentityModel.Policy.AuthorizationContext, która została zwrócona przez wywołanie System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) z argumentem authorizationPolicies o wartości null, została zmieniona w programie .NET Framework 4.6.

Sugestia

W rzadkich przypadkach aplikacje WCF korzystające z uwierzytelniania niestandardowego mogą widzieć różnice behawioralne. W takich przypadkach poprzednie zachowanie można przywrócić na jeden z dwóch sposobów:

  • Ponownie skompiluj aplikację, aby kierować do wcześniejszej wersji programu .NET Framework niż 4.6. W przypadku usług hostowanych przez usługi IIS użyj <httpRuntime targetFramework="x.x"> elementu , aby kierować do wcześniejszej wersji programu .NET Framework.

  • Dodaj następujący wiersz do <appSettings> sekcji pliku app.config:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Windows Forms

Icon.ToBitmap pomyślnie konwertuje ikony z ramkami PNG na obiekty mapy bitowej

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6, Icon.ToBitmap metoda pomyślnie konwertuje ikony z ramkami PNG na obiekty mapy bitowej.

W aplikacjach przeznaczonych dla programu .NET Framework 4.5.2 i starszych wersji metoda Icon.ToBitmap zgłasza wyjątek ArgumentOutOfRangeException, jeśli obiekt Icon ma ramki PNG.

Ta zmiana dotyczy aplikacji, które są ponownie skompilowane do docelowego użycia .NET Framework 4.6 i które implementują specjalną obsługę dla wyjątku ArgumentOutOfRangeException, zgłaszanego, gdy obiekt Icon ma klatki PNG. W przypadku uruchamiania w programie .NET Framework 4.6 konwersja zakończy się pomyślnie, ArgumentOutOfRangeException nie zostanie już zgłoszona, a zatem program obsługi wyjątków nie jest już wywoływany.

Sugestia

Jeśli to zachowanie jest niepożądane, możesz zachować poprzednie zachowanie, dodając następujący element do <runtime> sekcji pliku app.config:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Jeśli plik app.config już zawiera element AppContextSwitchOverrides, nowa wartość powinna zostać scalona z atrybutem 'value' w następujący sposób:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Windows Presentation Foundation (WPF)

CurrentCulture nie jest zachowywana w operacjach dyspozytora WPF

Szczegóły

Począwszy od wersji .NET Framework 4.6, zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture wprowadzone w ramach procedury System.Windows.Threading.Dispatcher zostaną utracone na końcu tej operacji. Podobnie, zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture dokonane poza operacją dyspozytora mogą nie być odzwierciedlone podczas wykonywania tej operacji. Praktycznie oznacza to, że zmiany System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture mogą nie przepływać między wywołaniami zwrotnymi interfejsu użytkownika WPF a innym kodem w aplikacji WPF. Jest to spowodowane zmianą System.Threading.ExecutionContext, która powoduje, że System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są przechowywane w kontekście wykonywania, począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6. Operacje dyspozytora WPF przechowują kontekst wykonawczy, który jest używany do rozpoczęcia operacji i przywrócenia poprzedniego kontekstu po jej zakończeniu. Ponieważ System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są teraz częścią tego kontekstu, zmiany w nich w ramach operacji dyspozytora nie są utrwalane poza operacją.

Sugestia

Aplikacje, których dotyczy ta zmiana, mogą obejść ten problem, przechowując żądane System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture w polu i sprawdzając we wszystkich jednostkach operacji dyspozytora (w tym procedury obsługi zdarzeń zwrotnych interfejsu użytkownika), że poprawne System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są ustawione. Alternatywnie, ponieważ zmiana ExecutionContext będąca podstawą tej zmiany w WPF dotyczy tylko aplikacji przeznaczonych dla platformy .NET Framework 4.6 lub nowszej, tej rozbieżności można uniknąć, celując w platformę .NET Framework 4.5.2. Aplikacje, które są przeznaczone dla platformy .NET Framework 4.6 lub nowszej, mogą również obejść ten problem, ustawiając następujący przełącznik zgodności:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ten problem został rozwiązany przez WPF w programie .NET Framework 4.6.2. Naprawiono ją również w programach .NET Framework 4.6, 4.6.1 do KB 3139549. Aplikacje przeznaczone dla platformy .NET Framework 4.6 lub nowszej automatycznie uzyskają odpowiednie zachowanie w aplikacjach WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) zostaną zachowane w operacjach dyspozytora.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Zaokrąglanie marginesów w układzie WPF zostało zmienione

Szczegóły

Sposób, w jaki marginesy są zaokrąglane, oraz obramowania i tło wewnątrz nich uległy zmianie. W wyniku tej zmiany:

  • Szerokość lub wysokość elementów mogą rosnąć lub zmniejszać o najwyżej jeden piksel.
  • Umieszczanie obiektu może być przenoszone przez co najwyżej jeden piksel.
  • Elementy wyśrodkowane mogą być przesunięte od środka w pionie lub poziomie o co najwyżej jeden piksel. Domyślnie ten nowy układ jest włączony tylko dla aplikacji przeznaczonych dla programu .NET Framework 4.6.

Sugestia

Ponieważ ta modyfikacja ma tendencję do wyeliminowania przycinania z prawej lub dolnej części kontrolek WPF przy wysokich rozdzielczościach DPI, aplikacje kierowane na wcześniejsze wersje .NET Framework, pracujące na .NET Framework 4.6, mogą zdecydować się na to nowe zachowanie, dodając następujący wiersz do sekcji <runtime> pliku app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Aplikacje przeznaczone dla programu .NET Framework 4.6, ale chcą, aby kontrolki WPF były renderowane przy użyciu poprzedniego algorytmu układu, mogą to zrobić, dodając następujący wiersz do <runtime> sekcji pliku app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

XML, XSLT

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

Szczegóły

W przypadku aplikacji, które są przeznaczone dla .NET Framework 4.5.2 lub wcześniejszych wersji, zapisywanie nieprawidłowej pary zastępczej przy użyciu mechanizmu zastępowania wyjątków nie zawsze zgłasza wyjątek. W przypadku aplikacji przeznaczonych dla programu .NET Framework 4.6 próba zapisania nieprawidłowej pary zastępczej zgłasza błąd System.ArgumentException.

Sugestia

W razie potrzeby można uniknąć tego przerwania, kierując się do programu .NET Framework 4.5.2 lub starszego. Alternatywnie nieprawidłowe pary zastępcze można wstępnie przetworzyć do prawidłowego pliku XML przed ich zapisaniem.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Sprawdzanie poprawności schematu XSD teraz prawidłowo wykrywa naruszenia unikatowych ograniczeń, jeśli używane są klucze złożone, a jeden klucz jest pusty

Szczegóły

Wersje programu .NET Framework wcześniejsze niż 4.6 zawierały usterkę, która spowodowała, że walidacja XSD nie wykryła unikatowych ograniczeń dotyczących kluczy złożonych, jeśli jeden z kluczy był pusty. W programie .NET Framework 4.6 ten problem został poprawiony. Spowoduje to bardziej poprawną walidację, ale może również powodować, że niektóre elementy XML, które wcześniej były weryfikowane, teraz nie przejdą weryfikacji.

Sugestia

Jeśli wymagane są luźniejsze zasady weryfikacji w programie .NET Framework 4.0, aplikacja może być ukierunkowana na wersję 4.5 (lub starszą) programu .NET Framework. Podczas przeniesienia na .NET Framework 4.6 należy jednak przeprowadzić przegląd kodu, aby upewnić się, że weryfikacja zduplikowanych kluczy złożonych (zgodnie z opisem tego problemu) nie jest oczekiwana.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

.NET Framework 4.6.1

Rdzeń

Zmień znak separatora ścieżki we właściwości FullName obiektów ZipArchiveEntry

Szczegóły

W przypadku aplikacji przeznaczonych dla programu .NET Framework 4.6.1 i nowszych wersji znak separatora ścieżki zmienił się z ukośnika odwrotnego ("\") na ukośnik odwrotny ("/") we FullName właściwości ZipArchiveEntry obiektów utworzonych przez przeciążenia CreateFromDirectory metody. Zmiana powoduje, że implementacja platformy .NET jest zgodna z sekcją 4.4.17.1 specyfikacji formatu plików .ZIP i umożliwia dekompresowane archiwa .ZIP w systemach innych niż Windows.
Dekompresowanie pliku zip utworzonego przez aplikację, która jest przeznaczona dla poprzedniej wersji programu .NET Framework w systemach operacyjnych innych niż Windows, takich jak Macintosh, nie może zachować struktury katalogów. Na przykład na komputerze Macintosh tworzy zestaw plików, których nazwa pliku łączy ścieżkę katalogu wraz z dowolnymi znakami ukośnika odwrotnego ("\") i nazwą pliku. W związku z tym struktura katalogów dekompresowanych plików nie jest zachowywana.

Sugestia

Wpływ tej zmiany na pliki .ZIP, które są dekompresowane w systemie operacyjnym Windows przez interfejsy API w przestrzeni nazw programu .NET Framework System.IO , powinny być minimalne, ponieważ te interfejsy API mogą bezproblemowo obsługiwać ukośnik do przodu ("/") lub ukośnik odwrotny ("\") jako znak separatora ścieżki.
Jeśli ta zmiana jest niepożądana, możesz zrezygnować z niej, dodając ustawienie konfiguracji do <runtime> sekcji pliku konfiguracji aplikacji. W poniższym przykładzie przedstawiono zarówno sekcję, <runtime> jak i przełącznik rezygnacji Switch.System.IO.Compression.ZipFile.UseBackslash :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Ponadto aplikacje przeznaczone dla poprzednich wersji programu .NET Framework, ale są uruchomione w programie .NET Framework 4.6.1 i nowszych wersjach, mogą zdecydować się na to zachowanie, dodając ustawienie konfiguracji do <runtime> sekcji pliku konfiguracji aplikacji. Poniżej przedstawiono zarówno sekcję <runtime>, jak również przełącznik zgody Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.1
Typ Przekierowanie

Dotyczy interfejsów API

Windows Communication Foundation (WCF)

Powiązanie WCF z trybem zabezpieczeń TransportWithMessageCredential

Szczegóły

Począwszy od programu .NET Framework 4.6.1, powiązanie WCF korzystające z trybu zabezpieczeń TransportWithMessageCredential można skonfigurować do odbierania komunikatów z niepodpisanymi nagłówkami "do" dla kluczy zabezpieczeń asymetrycznych. Domyślnie nagłówki "do" niepodpisane będą nadal odrzucane w programie .NET Framework 4.6.1. Zostaną one zaakceptowane tylko wtedy, gdy aplikacja zdecyduje się na ten nowy tryb działania przy użyciu przełącznika Switch.System.ServiceModel.AllowUnsignedToHeader.

Sugestia

Ponieważ jest to funkcja zgody, nie powinna mieć wpływu na zachowanie istniejących aplikacji.
Aby kontrolować, czy nowe zachowanie jest używane, czy nie, użyj następującego ustawienia konfiguracji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Nazwa/nazwisko Wartość
Scope Przejrzysty
Wersja 4.6.1
Typ Przekierowanie

Dotyczy interfejsów API

X509CertificateClaimSet.FindClaims uwzględnia wszystkie typy oświadczeń

Szczegóły

W aplikacjach przeznaczonych dla programu .NET Framework 4.6.1, jeśli zestaw oświadczeń X509 jest inicjowany z certyfikatu, który ma wiele wpisów DNS w polu SAN, System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) metoda próbuje dopasować argument claimType ze wszystkimi wpisami DNS. W przypadku aplikacji przeznaczonych dla poprzednich wersji programu .NET Framework System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) metoda próbuje dopasować argument claimType tylko do ostatniego wpisu DNS.

Sugestia

Ta zmiana dotyczy tylko aplikacji przeznaczonych dla programu .NET Framework 4.6.1. Ta zmiana może zostać wyłączona (lub włączona, jeśli jest stosowana wersja przed 4.6.1) za pomocą przełącznika zgodności DisableMultipleDNSEntries.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.1
Typ Przekierowanie

Dotyczy interfejsów API

Windows Forms

Application.FilterMessage nie zgłasza już ponownie wdrożeń IMessageFilter.PreFilterMessage

Szczegóły

Przed wersją .NET Framework 4.6.1, wywołanie FilterMessage(Message) z PreFilterMessage(Message), która wywoływała System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) lub System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (podczas wywoływania DoEvents()), powodowało System.IndexOutOfRangeException.

Począwszy od aplikacji przeznaczonych dla .NET Framework 4.6.1, ten wyjątek nie jest już zgłaszany, a filtry reentrancyjne, jak opisano powyżej, mogą być używane.

Sugestia

Należy pamiętać, że FilterMessage(Message) nie będzie już zgłaszać reentrantnego zachowania opisanego PreFilterMessage(Message) powyżej. Ma to wpływ tylko na aplikacje przeznaczone dla platformy .NET Framework 4.6.1.Apps przeznaczone dla platformy .NET Framework 4.6.1 mogą zrezygnować z tej zmiany (lub aplikacje przeznaczone dla starszych platform mogą wyrazić zgodę) przy użyciu przełącznika zgodności DontSupportReentrantFilterMessage .

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.1
Typ Przekierowanie

Dotyczy interfejsów API

Windows Presentation Foundation (WPF)

Wywołania metody System.Windows.Input.PenContext.Disable w systemach z obsługą dotykową mogą zgłaszać wyjątek ArgumentException

Szczegóły

W niektórych okolicznościach wywołania wewnętrznej metody System.Windows.Input.PenContext.Disable w systemach z obsługą dotykową mogą prowadzić do zgłoszenia nieobsługiwanej T:System.ArgumentException z powodu ponownego wywołania.

Sugestia

Ten problem został rozwiązany w programie .NET Framework 4.7. Aby zapobiec wyjątkowi, przeprowadź uaktualnienie do wersji programu .NET Framework, począwszy od programu .NET Framework 4.7.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.1
Typ Przekierowanie

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath zgłasza wyjątek NullReferenceException

Szczegóły

W programie .NET Framework 4.6.2 środowisko uruchomieniowe zgłasza T:System.NullReferenceException podczas pobierania wartości zawierającej P:System.Web.HttpRuntime.AppDomainAppPath znaki null, natomiast w wersji 4.6.1 i wcześniejszych zgłasza błąd T:System.ArgumentNullException.

Sugestia

Możesz wykonać jedną z następujących czynności, aby odpowiedzieć na tę zmianę:

  • Jeśli Twoja aplikacja jest uruchomiona na platformie .NET Framework 4.6.2, obsłuż element T:System.NullReferenceException.
  • Uaktualnij program do programu .NET Framework 4.7, który przywraca poprzednie zachowanie i zgłasza błąd T:System.ArgumentNullException.
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Rdzeń

Odszyfrowywacz AesCryptoServiceProvider zapewnia transformację wielokrotnego użytku

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, moduł odszyfrowujący AesCryptoServiceProvider zapewnia przekształcenie wielokrotnego użytku. Po wywołaniu System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), transformacja zostanie ponownie zainicjowana i może zostać ponownie użyta. W przypadku aplikacji przeznaczonych dla wcześniejszych wersji .NET Framework, próba ponownego użycia deszyfratora poprzez wywołanie System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) po wywołaniu System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) spowoduje zgłoszenie CryptographicException lub wygenerowanie uszkodzonych danych.

Sugestia

Wpływ tej zmiany powinien być minimalny, ponieważ jest to oczekiwane zachowanie. Aplikacje, które zależą od poprzedniego zachowania, mogą zrezygnować z korzystania z niego, dodając następujące ustawienie konfiguracji do <runtime> sekcji pliku konfiguracji aplikacji:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Ponadto aplikacje przeznaczone dla poprzedniej wersji programu .NET Framework, ale działają w wersji programu .NET Framework, począwszy od programu .NET Framework 4.6.2, mogą wyrazić zgodę, dodając następujące ustawienie konfiguracji do <runtime> sekcji pliku konfiguracji aplikacji:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Wywołania konstruktorów ClaimsIdentity

Szczegóły

Począwszy od .NET Framework 4.6.2, nastąpiła zmiana w sposobie, w jaki konstruktory ClaimsIdentity z parametrem System.Security.Principal.IIdentity ustawiają właściwość System.Security.Claims.ClaimsIdentity.Actor. System.Security.Principal.IIdentity Jeśli argument jest obiektemClaimsIdentity, a właściwość System.Security.Claims.ClaimsIdentity.Actor tego obiektuClaimsIdentity nie jest null, właściwość System.Security.Claims.ClaimsIdentity.Actor jest dołączana przy użyciu metody Clone(). W Frameworkie 4.6.1 i starszych wersjach właściwość System.Security.Claims.ClaimsIdentity.Actor jest przypisana jako istniejące odwołanie. Ze względu na tę zmianę, począwszy od .NET Framework 4.6.2, właściwość System.Security.Claims.ClaimsIdentity.Actor nowego obiektu ClaimsIdentity nie jest równa właściwości System.Security.Claims.ClaimsIdentity.Actor argumentu konstruktora System.Security.Principal.IIdentity. W programie .NET Framework 4.6.1 i starszych wersjach jest to równe.

Sugestia

Jeśli to zachowanie jest niepożądane, możesz przywrócić poprzednie zachowanie, ustawiając Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity przełącznik w pliku konfiguracji aplikacji na true. Wymaga to dodania następujących elementów do <runtime> sekcji pliku web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Zmiany w normalizacji ścieżki

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, sposób, w jaki środowisko uruchomieniowe normalizuje ścieżki, uległ zmianie. Normalizacja ścieżki polega na zmodyfikowaniu ciągu identyfikującego ścieżkę lub plik, tak aby była zgodna z prawidłową ścieżką w docelowym systemie operacyjnym. Normalizacja zwykle obejmuje:

  • Kanonizacja separatorów składników i katalogów.
  • Zastosowanie bieżącego katalogu jako podstawy dla ścieżki względnej.
  • Ocenianie katalogu względnego (.) lub katalogu nadrzędnego (..) w ścieżce.
  • Przycinanie określonych znaków. Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, następujące zmiany w normalizacji ścieżki są domyślnie włączone:
    • Środowisko uruchomieniowe używa funkcji GetFullPathName systemu operacyjnego w celu normalizacji ścieżek.
  • Normalizacja nie obejmuje już przycinania końca segmentów katalogu (takich jak spacja na końcu nazwy katalogu).
  • Obsługa składni ścieżki urządzenia w pełnym zaufaniu, w tym \\.\ i, dla interfejsów API we/wy plików w mscorlib.dll, \\?\.
  • Środowisko uruchomieniowe nie weryfikuje ścieżek składni urządzenia.
  • Używanie składni urządzenia do uzyskiwania dostępu do alternatywnych strumieni danych jest obsługiwane. Te zmiany zwiększają wydajność, umożliwiając metodom uzyskiwanie dostępu do wcześniej niedostępnych ścieżek. Te zmiany nie mają wpływu na aplikacje przeznaczone dla programu .NET Framework 4.6.1 i starszych wersji, ale działają w programie .NET Framework 4.6.2 lub nowszym.

Sugestia

Aplikacje przeznaczone dla programu .NET Framework 4.6.2 lub nowszego mogą zrezygnować z tej zmiany i korzystać ze starszej normalizacji, dodając następujące informacje do <runtime> sekcji pliku konfiguracji aplikacji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Aplikacje przeznaczone dla programu .NET Framework 4.6.1 lub starszego, ale są uruchomione w programie .NET Framework 4.6.2 lub nowszym, mogą włączyć zmiany normalizacji ścieżki, dodając następujący wiersz do <runtime> sekcji pliku konfiguracji aplikacji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.2
Typ Przekierowanie

Przepływ ustawień CurrentCulture i CurrentUICulture przez zadania

Szczegóły

Począwszy od programu .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są przechowywane w System.Threading.ExecutionContext wątku, który kontynuuje przepływ w operacjach asynchronicznych. Oznacza to, że zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture zostaną odzwierciedlone w zadaniach uruchamianych później asynchronicznie. Różni się to od zachowania poprzednich wersji programu .NET Framework (co spowoduje zresetowanie System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture we wszystkich zadaniach asynchronicznych).

Sugestia

Aplikacje, których dotyczy ta zmiana, mogą obejść ją, jawnie ustawiając żądaną operację System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture jako pierwszą operację w zadaniach asynchronicznych. Alternatywnie, poprzednie działanie funkcji (polegające na braku przepływu System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) można wybrać, ustawiając następujący przełącznik zgodności:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ten problem został rozwiązany przez WPF w programie .NET Framework 4.6.2. Naprawiono ją również w programach .NET Framework 4.6, 4.6.1 do KB 3139549. Aplikacje przeznaczone dla platformy .NET Framework 4.6 lub nowszej automatycznie uzyskają odpowiednie zachowanie w aplikacjach WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) zostaną zachowane w operacjach dyspozytora.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów API

Nazwy zdarzeń ETW nie mogą się różnić tylko od sufiksu "Start" lub "Stop"

Szczegóły

W programach .NET Framework 4.6 i 4.6.1 środowisko uruchomieniowe zgłasza wyjątek ArgumentException, gdy dwie nazwy zdarzeń Śledzenia Zdarzeń dla Windows (ETW) różnią się tylko sufiksem „Start” lub „Stop” (tak jak w przypadku, gdy jedno zdarzenie ma nazwę LogUser, a inne LogUserStart). W takim przypadku środowisko uruchomieniowe nie może skonstruować źródła zdarzeń, które nie może emitować żadnego rejestrowania.

Sugestia

Aby zapobiec wyjątkowi, upewnij się, że żadne dwie nazwy zdarzeń nie różnią się tylko sufiksem "Start" lub "Stop". To wymaganie jest usuwane, począwszy od programu .NET Framework 4.6.2; środowisko uruchomieniowe może uściślać nazwy zdarzeń, które różnią się tylko sufiksem "Start" i "Stop".

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6
Typ Przekierowanie

Obsługa długich ścieżek

Szczegóły

Począwszy od aplikacji przeznaczonych dla platformy .NET Framework 4.6.2, obsługiwane są długie ścieżki (maksymalnie 32K znaków), a ograniczenie do 260 znaków (lub MAX_PATH) zostało usunięte. W przypadku aplikacji, które zostały ponownie skompilowane z myślą o platformie .NET Framework 4.6.2, ścieżki kodu, które wcześniej zgłaszały wyjątek System.IO.PathTooLongException, ponieważ ścieżka przekroczyła 260 znaków, będą teraz zgłaszać System.IO.PathTooLongException tylko w następujących warunkach:

  • Długość ścieżki jest większa niż MaxValue (32 767 znaków).
  • System operacyjny zwraca COR_E_PATHTOOLONG lub jego odpowiednik. W przypadku aplikacji przeznaczonych dla platformy .NET Framework 4.6.1 i starszych wersji środowisko uruchomieniowe automatycznie zgłasza wyjątek System.IO.PathTooLongException, gdy ścieżka przekracza 260 znaków.

Sugestia

W przypadku aplikacji przeznaczonych dla platformy .NET Framework 4.6.2 możesz zrezygnować z obsługi długich ścieżek, jeśli nie jest to pożądane, dodając następujący kod do sekcji <runtime> pliku app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

W przypadku aplikacji przeznaczonych dla starszych wersji programu .NET Framework, ale uruchamianych w programie .NET Framework 4.6.2 lub nowszym, możesz wyrazić zgodę na obsługę długiej ścieżki, dodając następujące informacje do <runtime> sekcji app.config pliku:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.2
Typ Przekierowanie

Kontrole dwukropka ścieżki są bardziej rygorystyczne

Szczegóły

W programie .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) zostało poprawione, co skutkowało zablokowaniem niektórych ścieżek identyfikatora URI w kilku wybranych interfejsach API ścieżek, w których wcześniej były tolerowane.

Sugestia

W przypadku przekazania identyfikatora URI do dotkniętych interfejsów API najpierw zmodyfikuj ciąg, aby był ścieżką prawną.

  • Usuń schemat z adresów URL ręcznie (na przykład usuń file:// z adresów URL).

  • Przekaż identyfikator URI do klasy Uri i użyj LocalPath.

Alternatywnie możesz zrezygnować z nowej normalizacji ścieżki, ustawiając Switch.System.IO.UseLegacyPathHandling przełącznik AppContext na true.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Zabezpieczenia

RsACng teraz poprawnie ładuje klucze RSA o niestandardowym rozmiarze klucza

Szczegóły

W wersjach programu .NET Framework wcześniejszych niż 4.6.2 klienci z niestandardowymi rozmiarami kluczy dla certyfikatów RSA nie mogą uzyskać dostępu do tych kluczy za pośrednictwem metod System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) i rozszerzeń System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Komunikat System.Security.Cryptography.CryptographicException "Żądany rozmiar klucza nie jest obsługiwany" zostaje zgłoszony. W programie .NET Framework 4.6.2 ten problem został rozwiązany. Podobnie, ImportParameters(RSAParameters) i ImportParameters(RSAParameters) teraz działają z niestandardowymi rozmiarami kluczy bez zgłaszania wyjątku System.Security.Cryptography.CryptographicException.

Sugestia

Jeśli istnieje logika obsługi wyjątków, która opiera się na poprzednim zachowaniu, w którym System.Security.Cryptography.CryptographicException jest zgłaszany podczas użycia niestandardowych rozmiarów kluczy, rozważ usunięcie logiki.

Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

SignedXml.GetPublicKey zwraca RSACng w net462 (lub lightup) bez zmiany celu

Szczegóły

Od platformy .NET Framework 4.6.2 konkretny typ obiektu zwracanego przez metodę SignedXml.GetPublicKey zmienił się (bez wprowadzenia zmiany charakteru) z implementacji opartej na CryptoServiceProvider na implementację opartą na Cng. Jest to spowodowane tym, że implementacja zmieniła się z użycia certificate.PublicKey.Key na użycie wewnętrznego certificate.GetAnyPublicKey, który przekazuje do RSACertificateExtensions.GetRSAPublicKey.

Sugestia

Począwszy od aplikacji uruchomionych w programie .NET Framework 4.7.1, możesz użyć implementacji CryptoServiceProvider używanej domyślnie w programie .NET Framework 4.6.1 i starszych wersjach, dodając następujący przełącznik konfiguracji do sekcji środowiska uruchomieniowego pliku konfiguracji aplikacji:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Windows Communication Foundation (WCF)

Może wystąpić zakleszczenie podczas używania usług reentrantnych.

Szczegóły

Zakleszczenie może spowodować wystąpienie usługi Reentrant, która jednocześnie ogranicza wystąpienia usługi do jednego wątku wykonywania. Usługi podatne na ten problem będą miały następujące elementy ServiceBehaviorAttribute w kodzie:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Sugestia

Aby rozwiązać ten problem, możesz wykonać następujące czynności:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Zainstaluj najnowszą aktualizację programu .NET Framework 4.6.2 lub uaktualnij ją do nowszej wersji programu .NET Framework. Spowoduje to wyłączenie przepływu ExecutionContext w OperationContext.Current. To zachowanie można skonfigurować; Jest to równoważne dodaniu następującego ustawienia aplikacji do pliku konfiguracji:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Wartość Switch.System.ServiceModel.DisableOperationContextAsyncFlow nigdy nie powinna być ustawiona na false dla usług reentrantnych.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

OperationContext.Current może zwracać wartość null, gdy jest wywoływana w klauzuli using

Szczegóły

OperationContext.Current może zwrócić null, a NullReferenceException może wystąpić, jeśli wszystkie następujące warunki są prawdziwe:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Sugestia

Aby rozwiązać ten problem, możesz wykonać następujące czynności:

  • Zmodyfikuj kod w następujący sposób, aby utworzyć wystąpienie nowego obiektu innego niż: nullCurrent

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Zainstaluj najnowszą aktualizację programu .NET Framework 4.6.2 lub uaktualnij ją do nowszej wersji programu .NET Framework. To wyłącza przepływ ExecutionContext w OperationContext.Current i przywraca zachowanie aplikacji WCF w .NET Framework 4.6.1 i wcześniejszych wersjach. To zachowanie można skonfigurować; Jest to równoważne dodaniu następującego ustawienia aplikacji do pliku konfiguracji:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Jeśli ta zmiana jest niepożądana, a aplikacja zależy od kontekstu wykonywania przepływającego między kontekstami operacji, możesz włączyć jej przepływ w następujący sposób:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Transportowe zabezpieczenia WCF obsługują certyfikaty przechowywane przy użyciu CNG.

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, zabezpieczenia transportu WCF obsługują certyfikaty przechowywane przy użyciu biblioteki kryptograficznej systemu Windows (CNG). Ta obsługa jest ograniczona do certyfikatów z kluczem publicznym, który ma wykładnik nie więcej niż 32 bity długości. Gdy aplikacja jest przeznaczona dla programu .NET Framework 4.6.2, ta funkcja jest domyślnie włączona. We wcześniejszych wersjach programu .NET Framework próba użycia certyfikatów X509 u dostawcy magazynu kluczy CSG zgłasza wyjątek.

Sugestia

Aplikacje przeznaczone dla platformy .NET Framework 4.6.1 lub starszej, ale są uruchomione w programie .NET Framework 4.6.2, mogą włączyć obsługę certyfikatów CNG, dodając następujący wiersz do <runtime> sekcji pliku app.config lub web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Można to również zrobić programowo za pomocą następującego kodu:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Należy pamiętać, że ze względu na tę zmianę każdy kod obsługi wyjątków, który zależy od próby zainicjowania bezpiecznej komunikacji z certyfikatem CNG, który zakończy się niepowodzeniem, nie będzie już wykonywany.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6.2
Typ Przekierowanie

Windows Forms

Niepoprawna implementacja elementu MemberDescriptor.Equals

Szczegóły

Oryginalna implementacja MemberDescriptor.Equals metody porównuje dwie różne właściwości ciągu z porównywanych obiektów: nazwę kategorii i ciąg opisu. Poprawka polega na porównaniu Category pierwszego obiektu z Category drugim, a Description z pierwszego do Description drugiego.

Sugestia

Jeśli aplikacja zależy od MemberDescriptor.Equals i czasami zwraca false , gdy deskryptory są równoważne, a Ty celujesz w .NET Framework 4.6.2 lub nowszy, masz kilka opcji:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Jeśli aplikacja jest przeznaczona dla programu .NET Framework 4.6.1 lub starszego i działa na programie .NET Framework 4.6.2 lub nowszym i chcesz włączyć tę zmianę, możesz ustawić przełącznik zgodności na false, dodając następującą wartość do pliku app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Nazwa/nazwisko Wartość
Scope Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Windows Presentation Foundation (WPF)

CurrentCulture nie jest zachowywana w operacjach dyspozytora WPF

Szczegóły

Począwszy od wersji .NET Framework 4.6, zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture wprowadzone w ramach procedury System.Windows.Threading.Dispatcher zostaną utracone na końcu tej operacji. Podobnie, zmiany w System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture dokonane poza operacją dyspozytora mogą nie być odzwierciedlone podczas wykonywania tej operacji. Praktycznie oznacza to, że zmiany System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture mogą nie przepływać między wywołaniami zwrotnymi interfejsu użytkownika WPF a innym kodem w aplikacji WPF. Jest to spowodowane zmianą System.Threading.ExecutionContext, która powoduje, że System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są przechowywane w kontekście wykonywania, począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6. Operacje dyspozytora WPF przechowują kontekst wykonawczy, który jest używany do rozpoczęcia operacji i przywrócenia poprzedniego kontekstu po jej zakończeniu. Ponieważ System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są teraz częścią tego kontekstu, zmiany w nich w ramach operacji dyspozytora nie są utrwalane poza operacją.

Sugestia

Aplikacje, których dotyczy ta zmiana, mogą obejść ten problem, przechowując żądane System.Globalization.CultureInfo.CurrentCulture lub System.Globalization.CultureInfo.CurrentUICulture w polu i sprawdzając we wszystkich jednostkach operacji dyspozytora (w tym procedury obsługi zdarzeń zwrotnych interfejsu użytkownika), że poprawne System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture są ustawione. Alternatywnie, ponieważ zmiana ExecutionContext będąca podstawą tej zmiany w WPF dotyczy tylko aplikacji przeznaczonych dla platformy .NET Framework 4.6 lub nowszej, tej rozbieżności można uniknąć, celując w platformę .NET Framework 4.5.2. Aplikacje, które są przeznaczone dla platformy .NET Framework 4.6 lub nowszej, mogą również obejść ten problem, ustawiając następujący przełącznik zgodności:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ten problem został rozwiązany przez WPF w programie .NET Framework 4.6.2. Naprawiono ją również w programach .NET Framework 4.6, 4.6.1 do KB 3139549. Aplikacje przeznaczone dla platformy .NET Framework 4.6 lub nowszej automatycznie uzyskają odpowiednie zachowanie w aplikacjach WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) zostaną zachowane w operacjach dyspozytora.

Nazwa/nazwisko Wartość
Scope Mały
Wersja 4.6
Typ Przekierowanie
  • Last updated on