Ponowne pobieranie zmian migracji do programu .NET Framework 4.6.x

  • Artykuł

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 programu .NET Framework 4.6, wywołanie RenderBeginTag(String) metody i RenderEndTag() 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ść
Zakres Edge
Wersja 4.6
Typ Przekierowanie

Dotyczy interfejsów 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 938397 KB. 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ść
Zakres 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ść
Zakres Mały
Wersja 4.6
Typ Przekierowanie

Podstawowe funkcje

Przepływ CurrentCulture i CurrentUICulture między zadaniami

Szczegóły

Począwszy od programu .NET Framework 4.6 i System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture są przechowywane w wątku System.Threading.ExecutionContext, który przepływa w operacjach asynchronicznych. Oznacza to, że zmiany lub System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture zostaną odzwierciedlone w zadaniach, które są później uruchamiane 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ą przez jawne ustawienie żądanej operacji lub System.Globalization.CultureInfo.CurrentUICulture jako pierwszej operacji w asynchronicznych System.Globalization.CultureInfo.CurrentCulture zadaniach. Alternatywnie stare zachowanie (nie przepływające System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) może zostać wybrane przez ustawienie następującego przełącznika 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ść
Zakres 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 ArgumentException błąd, gdy dwie nazwy zdarzeń śledzenia zdarzeń systemu Windows (ETW) różnią się tylko sufiksem "Uruchom" lub "Zatrzymaj" (tak jak w przypadku, gdy jedno zdarzenie ma nazwę LogUser , a inne ma nazwę 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ść
Zakres 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źć biblioteki 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ść
Zakres Główna
Wersja 4.5.1
Typ Przekierowanie

JIT

Ponowna próba il nie jest dozwolona w regionie try

Szczegóły

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

Sugestia

Jeśli aplikacja generuje il, który zawiera kod operacji ponownej próby w regionie try, aplikacja może kierować program .NET Framework 4.5 do korzystania ze starego trybu JIT i uniknąć tego przerwania. Alternatywnie wygenerowany il może zostać zaktualizowany, aby powrócić po regionie try.

Nazwa/nazwisko Wartość
Zakres 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 rozpatrunia może zgłaszać NullReferenceException kompilacje wydania 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 wydania. 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 z ich zestawem bitów UInt16 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 spowodować nieobsługiwany wyjątek lub nieprawidłowe dane wyjściowe.
  • 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 wprowadzeniem try bloku i wyjścia z try bloku, a ten sam warunek jest obliczany w catch bloku lub finally , nowy kompilator 64-bitowy JIT usuwa if warunek z catch bloku lub finally podczas optymalizowania kodu. W rezultacie kod wewnątrz instrukcji if w catch bloku or finally jest wykonywany bezwarunkowo.

Sugestia

Środki zaradcze 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 usług programu .NET Framework 4.6 i 4.6.1 dotyczą każdego z tych problemów, z wyjątkiem NullReferenceException operacji rozpakowania.

  • Kompiluj przy użyciu starszego 64-bitowego kompilatora JIT. Aby uzyskać więcej informacji na temat tego, jak to zrobić, zobacz sekcję Środki zaradcze innych problemów . Środki zaradcze 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 starsze 64-bitowe kompilator JIT; wartość 0 wyłącza ją 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 witrynie Microsoft Połączenie.

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

Sieć

Walidacja OID certyfikatu EKU

Szczegóły

Począwszy od programu .NET Framework 4.6, SslStream klasy or 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 identyfikatora EKU używa zdalnych wywołań zwrotnych certyfikatów, aby upewnić się, że certyfikat zdalny ma poprawne identyfikatory OID przeznaczone do zamierzonego celu.

Sugestia

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

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

Ważne

To ustawienie jest dostępne tylko dla zgodności z poprzednimi wersjami. Jego użycie nie jest zalecane.

Nazwa/nazwisko Wartość
Zakres 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:

  • Programowe ustawianie przełączników compat na obiekcie , zgodnie z System.AppContextopisem w tym miejscu.
  • Dodając następujący wiersz do <runtime> sekcji pliku app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Nazwa/nazwisko Wartość
Zakres 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 podzielenie danych SCHANNEL na dwa oddzielne rekordy, pierwszy jako jeden bajt i drugi jako n-1 bajty. 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 dostępne tylko dla zgodności z poprzednimi wersjami. Jego użycie nie jest zalecane.

Nazwa/nazwisko Wartość
Zakres 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 zwrócona System.IdentityModel.Policy.AuthorizationContext przez wywołanie System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) elementu z argumentem authorizationPolicies o wartości null zmieniła swoją implementację 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ść
Zakres 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 zgłasza ArgumentOutOfRangeException wyjątek, Icon.ToBitmap jeśli obiekt Icon ma ramki PNG.

Ta zmiana dotyczy aplikacji, które są ponownie skompilowane w celu kierowania programu .NET Framework 4.6 i implementują specjalną obsługę zgłaszaną ArgumentOutOfRangeException , gdy obiekt Ikona ma ramki 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 zawiera AppContextSwitchOverrides już element, 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ść
Zakres 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 programu .NET Framework 4.6, zmiany lub System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture wprowadzone w ramach elementu System.Windows.Threading.Dispatcher zostaną utracone na końcu tej operacji dyspozytora. Podobnie zmiany operacji System.Globalization.CultureInfo.CurrentCulture dyspozytora lub System.Globalization.CultureInfo.CurrentUICulture wprowadzone poza operacją dyspozytora mogą nie zostać odzwierciedlone podczas wykonywania tej operacji. Praktycznie oznacza to, że System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture zmiany 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 System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture jest przechowywana w kontekście wykonywania, począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6. Operacje dyspozytora WPF przechowują kontekst wykonywania używany do rozpoczęcia operacji i przywracania poprzedniego kontekstu po zakończeniu operacji. 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 wszystkie jednostki operacji dyspozytora (w tym programy obsługi wywołania zwrotnego zdarzeń interfejsu użytkownika), które są poprawne System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture ustawione. Alternatywnie, ponieważ zmiana ExecutionContext bazowa tej zmiany WPF dotyczy tylko aplikacji przeznaczonych dla platformy .NET Framework 4.6 lub nowszej, tej przerwy można uniknąć przez ustawienie przełącznika zgodności programu .NET Framework 4.5.2.Apps, które są przeznaczone dla platformy .NET Framework 4.6 lub nowszej, można 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ść
Zakres 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ąglone i obramowania, a tło wewnątrz nich uległo 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.
  • Wyśrodkowane elementy mogą być wyśrodkowane w pionie lub w poziomie przez 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 wycinków z prawej lub dolnej części kontrolek WPF w dużych wystąpieniach DPI, aplikacje przeznaczone dla wcześniejszych wersji programu .NET Framework, ale działają na platformie .NET Framework 4.6, mogą zdecydować się na to nowe zachowanie, dodając następujący wiersz do <runtime> sekcji 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ść
Zakres Mały
Wersja 4.6
Typ Przekierowanie

Języki XML, XSLT

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

Szczegóły

W przypadku aplikacji przeznaczonych dla programu .NET Framework 4.5.2 lub wcześniejszych wersji pisanie nieprawidłowej pary zastępczej przy użyciu obsługi rezerwowej wyjątku 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ść
Zakres 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 poprawną walidację, ale może również spowodować, że niektóre elementy XML nie zweryfikują, które zostałyby wcześniej zweryfikowane.

Sugestia

Jeśli wymagana jest luźna weryfikacja programu .NET Framework 4.0, walidacja aplikacji może być docelowa w wersji 4.5 (lub starszej) programu .NET Framework. Podczas ponownego pobierania do programu .NET Framework 4.6 należy jednak przeprowadzić przegląd kodu, aby upewnić się, że zduplikowane klucze złożone (zgodnie z opisem tego problemu) nie powinny być weryfikowane.

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

.NET Framework 4.6.1

Podstawowe funkcje

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 i Switch.System.IO.Compression.ZipFile.UseBackslash przełącznik zgody.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Nazwa/nazwisko Wartość
Zakres 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ść
Zakres Transparent
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 w przypadku określania wartości docelowej przed 4.6.1) z przełącznikiem zgodności DisableMultipleDNSEntries .

Nazwa/nazwisko Wartość
Zakres 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 programem .NET Framework 4.6.1 wywołanie metody lub (podczas wywoływania ) spowoduje wywołanie FilterMessage(Message)PreFilterMessage(Message)DoEvents()System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) metody .System.IndexOutOfRangeExceptionSystem.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter)

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.1, ten wyjątek nie jest już zgłaszany, a filtry ponownego uczestnika zgodnie z powyższym opisem mogą być używane.

Sugestia

Należy pamiętać, że FilterMessage(Message) nie będzie już zgłaszać ponownego 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ść
Zakres Edge
Wersja 4.6.1
Typ Przekierowanie

Dotyczy interfejsów API

Windows Presentation Foundation (WPF)

Wywołania elementu 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.Intput.PenContext.Disable w systemach z obsługą dotykową mogą zgłaszać nieobsługiwane 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ść
Zakres 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 błąd podczas pobierania wartości zawierającej P:System.Web.HttpRuntime.AppDomainAppPath znaki null. W programie .NET Framework 4.6.1 i starszych wersjach środowisko uruchomieniowe zgłasza błąd T:System.ArgumentNullException.

Sugestia

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

  • Obsługa aplikacji T:System.NullReferenceException , jeśli aplikacja jest uruchomiona w programie .NET Framework 4.6.2.
  • Uaktualnij program do programu .NET Framework 4.7, który przywraca poprzednie zachowanie i zgłasza błąd T:System.ArgumentNullException.
Nazwa/nazwisko Wartość
Zakres Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Podstawowe funkcje

Odszyfrowywanie AesCryptoServiceProvider zapewnia przekształcenie wielokrotnego użytku

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, AesCryptoServiceProvider odszyfrowywanie zapewnia przekształcenie wielokrotnego użytku. Po wywołaniu System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)metody , transformacja zostanie ponownie zainicjowana i może zostać ponownie użyta. W przypadku aplikacji przeznaczonych dla wcześniejszych wersji programu .NET Framework próba ponownego użycia odszyfrowywania przez wywołanie System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) wywołania w celu System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) zgłoszenia CryptographicException lub wygenerowania 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ść
Zakres Mały
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Wywołania konstruktorów ClaimsIdentity

Szczegóły

Począwszy od programu .NET Framework 4.6.2, istnieje zmiana sposobu, w jaki ClaimsIdentity konstruktory z parametrem System.Security.Principal.IIdentity ustawiają System.Security.Claims.ClaimsIdentity.Actor właściwość . System.Security.Principal.IIdentity Jeśli argument jest obiektemClaimsIdentity, a System.Security.Claims.ClaimsIdentity.Actor właściwość tego ClaimsIdentity obiektu nie nulljest , System.Security.Claims.ClaimsIdentity.Actor właściwość jest dołączona przy użyciu Clone() metody . W programie Framework 4.6.1 i starszych wersjach System.Security.Claims.ClaimsIdentity.Actor właściwość jest dołączona jako istniejące odwołanie. Ze względu na tę zmianę, począwszy od programu .NET Framework 4.6.2, System.Security.Claims.ClaimsIdentity.Actor właściwość nowego ClaimsIdentity obiektu nie jest równa System.Security.Claims.ClaimsIdentity.Actor właściwości 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ść
Zakres 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:

  • Canonicalizing component and directory separators (Kanoniczne separatory składników i katalogów).
  • Zastosowanie bieżącego katalogu do ś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 odchyli do 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 \\.\ 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ść
Zakres Mały
Wersja 4.6.2
Typ Przekierowanie

Przepływ CurrentCulture i CurrentUICulture między zadaniami

Szczegóły

Począwszy od programu .NET Framework 4.6 i System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture są przechowywane w wątku System.Threading.ExecutionContext, który przepływa w operacjach asynchronicznych. Oznacza to, że zmiany lub System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture zostaną odzwierciedlone w zadaniach, które są później uruchamiane 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ą przez jawne ustawienie żądanej operacji lub System.Globalization.CultureInfo.CurrentUICulture jako pierwszej operacji w asynchronicznych System.Globalization.CultureInfo.CurrentCulture zadaniach. Alternatywnie stare zachowanie (nie przepływające System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) może zostać wybrane przez ustawienie następującego przełącznika 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ść
Zakres 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 ArgumentException błąd, gdy dwie nazwy zdarzeń śledzenia zdarzeń systemu Windows (ETW) różnią się tylko sufiksem "Uruchom" lub "Zatrzymaj" (tak jak w przypadku, gdy jedno zdarzenie ma nazwę LogUser , a inne ma nazwę 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ść
Zakres Edge
Wersja 4.6
Typ Przekierowanie

Obsługa długich ścieżek

Szczegóły

Począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6.2, obsługiwane są długie ścieżki (maksymalnie 32K), a ograniczenie długości ścieżek 260 znaków (lub MAX_PATH) zostało usunięte. W przypadku aplikacji, które zostały ponownie skompilowane w celu kierowania programu .NET Framework 4.6.2, ścieżki kodu, które wcześniej rzuciły element, System.IO.PathTooLongException ponieważ ścieżka przekroczyła 260 znaków, będzie teraz zgłaszać System.IO.PathTooLongException tylko następujące warunki:

  • 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 za każdym razem, gdy ścieżka przekracza 260 znaków.

Sugestia

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

<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ść
Zakres 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 miało efekt uboczny blokowania niektórych ścieżek identyfikatora URI w kilku wybranych interfejsach API ścieżki, 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 Uri klasy i użyj polecenia LocalPath.

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

Nazwa/nazwisko Wartość
Zakres 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 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) metod i System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) rozszerzenia. Komunikat System.Security.Cryptography.CryptographicException "Żądany rozmiar klucza nie jest obsługiwany" jest zgłaszany. W programie .NET Framework 4.6.2 ten problem został rozwiązany. Podobnie i ImportParameters(RSAParameters)ImportParameters(RSAParameters) teraz działają z niestandardowymi rozmiarami kluczy bez zgłaszania elementu 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ść
Zakres Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

SignedXml.GetPublicKey zwraca rsACng na net462 (lub lightup) bez zmiany retargeting

Szczegóły

Począwszy od programu .NET Framework 4.6.2, konkretny typ obiektu zwrócony przez SignedXml.GetPublicKey metodę został zmieniony (bez dziwactwa) z implementacji CryptoServiceProvider do implementacji Cng. Jest to spowodowane tym, że implementacja zmieniła się z użycia certificate.PublicKey.Key na użycie wewnętrznego certificate.GetAnyPublicKey , które przekazuje do elementu 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ść
Zakres Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Windows Communication Foundation (WCF)

Zakleszczenie może spowodować użycie usług reentrant

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 w elem.ExecutionContextOperationContext.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ść parametru Switch.System.ServiceModel.DisableOperationContextAsyncFlow nigdy nie powinna być ustawiona na false wartość dla usług Reentrant.

Nazwa/nazwisko Wartość
Zakres 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ć wartość null i może NullReferenceException spowodować, że wszystkie następujące warunki są spełnione:

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. Spowoduje to wyłączenie przepływu ExecutionContext elementu w OperationContext.Current systemie i przywrócenie zachowania aplikacji WCF w programie .NET Framework 4.6.1 i starszych 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ść
Zakres Edge
Wersja 4.6.2
Typ Przekierowanie

Dotyczy interfejsów API

Zabezpieczenia transportu 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ść
Zakres 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 czasami zwracania false , gdy deskryptory są równoważne, a docelową wersją programu .NET Framework 4.6.2 lub nowszą jest 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 w programie .NET Framework 4.6.2 lub nowszym i chcesz włączyć tę zmianę, możesz ustawić przełącznik false zgodności na, dodając następującą wartość do pliku app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Nazwa/nazwisko Wartość
Zakres 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 programu .NET Framework 4.6, zmiany lub System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture wprowadzone w ramach elementu System.Windows.Threading.Dispatcher zostaną utracone na końcu tej operacji dyspozytora. Podobnie zmiany operacji System.Globalization.CultureInfo.CurrentCulture dyspozytora lub System.Globalization.CultureInfo.CurrentUICulture wprowadzone poza operacją dyspozytora mogą nie zostać odzwierciedlone podczas wykonywania tej operacji. Praktycznie oznacza to, że System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture zmiany 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 System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture jest przechowywana w kontekście wykonywania, począwszy od aplikacji przeznaczonych dla programu .NET Framework 4.6. Operacje dyspozytora WPF przechowują kontekst wykonywania używany do rozpoczęcia operacji i przywracania poprzedniego kontekstu po zakończeniu operacji. 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 wszystkie jednostki operacji dyspozytora (w tym programy obsługi wywołania zwrotnego zdarzeń interfejsu użytkownika), które są poprawne System.Globalization.CultureInfo.CurrentCulture i System.Globalization.CultureInfo.CurrentUICulture ustawione. Alternatywnie, ponieważ zmiana ExecutionContext bazowa tej zmiany WPF dotyczy tylko aplikacji przeznaczonych dla platformy .NET Framework 4.6 lub nowszej, tej przerwy można uniknąć przez ustawienie przełącznika zgodności programu .NET Framework 4.5.2.Apps, które są przeznaczone dla platformy .NET Framework 4.6 lub nowszej, można 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ść
Zakres Mały
Wersja 4.6
Typ Przekierowanie