Dela via

Ommåla ändringar för migrering till .NET Framework 4.6.x

  • Artikel

I den här artikeln visas de problem med appkompatibilitet som introducerades i .NET Framework 4.6, 4.6.1 och 4.6.2.

.NET framework 4.6

ASP.NET

HtmlTextWriter renderar <br/> inte elementet korrekt

Details

Från och med .NET Framework 4.6 infogas bara en <BR /> (i stället för två) genom att anropa RenderBeginTag(String) och RenderEndTag() med ett <BR /> element korrekt

Förslag

Om en app är beroende av den extra <BR /> taggen RenderBeginTag(String) ska den anropas en andra gång. Observera att den här beteendeändringen endast påverkar appar som riktar sig mot .NET Framework 4.6 eller senare, så ett annat alternativ är att rikta in sig på en tidigare version av .NET Framework för att få det gamla beteendet.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Berörda API:er

ClickOnce

Appar som publicerats med ClickOnce och som använder ett SHA-256-kodsigneringscertifikat kan misslyckas i Windows 2003

Details

Den körbara filen är signerad med SHA256. Tidigare signerades det med SHA1 oavsett om kodsigneringscertifikatet var SHA-1 eller SHA-256. Detta gäller för:

  • Alla program som skapats med Visual Studio 2012 eller senare.
  • Program som skapats med Visual Studio 2010 eller tidigare på system med .NET Framework 4.5 finns. Om .NET Framework 4.5 eller senare finns är ClickOnce-manifestet också signerat med SHA-256 för SHA-256-certifikat oavsett vilken .NET Framework-version som det kompilerades mot.

Förslag

Ändringen i signeringen av Den körbara Filen ClickOnce påverkar endast Windows Server 2003-system. de kräver att KB-938397 installeras. Ändringen i signeringen av manifestet med SHA-256 även när en app riktar in sig på .NET Framework 4.0 eller tidigare versioner introducerar ett körningsberoende för .NET Framework 4.5 eller en senare version.

Name Värde
Omfång Edge
Version 4,5
Typ Ommåla

ClickOnce stöder SHA-256 på 4.0-riktade appar

Details

Tidigare skulle en ClickOnce-app med ett certifikat signerat med SHA-256 kräva att .NET Framework 4.5 eller senare finns, även om appen är riktad mot 4.0. Nu kan .NET Framework 4.0-riktade ClickOnce-appar köras på .NET Framework 4.0, även om de är signerade med SHA-256.

Förslag

Den här ändringen tar bort beroendet och gör att SHA-256-certifikat kan användas för att signera ClickOnce-appar som är avsedda för .NET Framework 4 och tidigare versioner.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Kärna

CurrentCulture- och CurrentUICulture-flöde mellan aktiviteter

Details

Från och med .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture lagras i trådens System.Threading.ExecutionContext, som flödar över asynkrona åtgärder. Det innebär att ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture återspeglas i aktiviteter som senare körs asynkront. Detta skiljer sig från beteendet för tidigare .NET Framework-versioner (som skulle återställas System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture i alla asynkrona uppgifter).

Förslag

Appar som påverkas av den här ändringen kan kringgå den genom att uttryckligen ange önskad System.Globalization.CultureInfo.CurrentCulture åtgärd eller System.Globalization.CultureInfo.CurrentUICulture som den första åtgärden i en asynkron aktivitet. Du kan också välja det gamla beteendet (för att System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICultureinte flöda) genom att ange följande kompatibilitetsväxel:

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

Det här problemet har åtgärdats av WPF i .NET Framework 4.6.2. Det har också åtgärdats i .NET Frameworks 4.6, 4.6.1 via KB 3139549. Program som riktar sig till .NET Framework 4.6 eller senare får automatiskt rätt beteende i WPF-program – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) bevaras i olika Dispatcher-åtgärder.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

ETW-händelsenamn kan inte bara skilja sig åt med suffixet "Start" eller "Stop"

Details

I .NET Framework 4.6 och 4.6.1 genererar körningen en ArgumentException när två händelsespårning för Windows -händelsenamn (ETW) endast skiljer sig åt med suffixet "Start" eller "Stop" (som när en händelse namnges LogUser och en annan heter LogUserStart). I det här fallet kan körningen inte konstruera händelsekällan, som inte kan generera någon loggning.

Förslag

Om du vill förhindra undantaget kontrollerar du att inga två händelsenamn endast skiljer sig åt med suffixet "Start" eller "Stop". Det här kravet tas bort från och med .NET Framework 4.6.2. körningen kan skilja händelsenamn som endast skiljer sig åt med suffixet "Start" och "Stop".

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Entity Framework

Att skapa en Entity Framework edmx med Visual Studio 2013 kan misslyckas med fel MSB4062 om du använder EntityDeploySplit- eller EntityClean-uppgifter

Details

MSBuild 12.0-verktyg (ingår i Visual Studio 2013) ändrade MSBuild-filplatser, vilket gjorde att äldre Entity Framework-målfiler var ogiltiga. Resultatet är att EntityDeploySplit och EntityClean aktiviteter misslyckas eftersom de inte kan hitta Microsoft.Data.Entity.Build.Tasks.dll. Observera att den här pausen beror på en ändring av verktygsuppsättningen (MSBuild/VS), inte på grund av en .NET Framework-ändring. Det inträffar bara när du uppgraderar utvecklarverktyg, inte när du bara uppgraderar .NET Framework.

Förslag

Entity Framework-målfiler har åtgärdats för att fungera med den nya MSBuild-layouten med början i .NET Framework 4.6. Om du uppgraderar till den versionen av ramverket åtgärdas det här problemet. Du kan också använda den här lösningen för att korrigera målfilerna direkt.

Name Värde
Omfång Huvudversion
Version 4.5.1
Typ Ommåla

JIT

IL-ret tillåts inte i en försöksregion

Details

Till skillnad från JIT64 just-in-time-kompilatorn tillåter RyuJIT (används i .NET Framework 4.6) inte en IL-ret-instruktion i en försöksregion. Att återvända från en try-region tillåts inte av ECMA-335-specifikationen, och ingen känd hanterad kompilator genererar en sådan IL. JIT64-kompilatorn kör dock en sådan IL om den genereras med reflektionsavsändare.

Förslag

Om en app genererar IL som innehåller en ret opcode i en försöksregion kan appen rikta in sig på .NET Framework 4.5 för att använda den gamla JIT:en och undvika den här pausen. Alternativt kan den genererade IL:en uppdateras för att returneras efter try-regionen.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Ny 64-bitars JIT-kompilator i .NET Framework 4.6

Details

Från och med .NET Framework 4.6 används en ny 64-bitars JIT-kompilator för just-in-time-kompilering. I vissa fall utlöses ett oväntat undantag eller ett annat beteende observeras än om en app körs med 32-bitars kompilatorn eller den äldre 64-bitars JIT-kompilatorn. Den här ändringen påverkar inte 32-bitars JIT-kompilatorn. De kända skillnaderna omfattar följande:

  • Under vissa förhållanden kan en unboxing-åtgärd utlösa en NullReferenceException i Versionsversioner med optimering aktiverad.
  • I vissa fall kan körning av produktionskod i en stor metodtext utlösa en StackOverflowException.
  • Under vissa förhållanden behandlas strukturer som skickas till en metod som referenstyper i stället för som värdetyper i Versionsversioner. En av manifestationerna av det här problemet är att de enskilda objekten i en samling visas i en oväntad ordning.
  • Under vissa förhållanden är jämförelsen av UInt16 värden med deras höga bituppsättning felaktig om optimering är aktiverat.
  • Under vissa förhållanden, särskilt vid initiering av matrisvärden, kan minnesinitiering av IL-instruktionen OpCodes.Initblk initiera minne med ett felaktigt värde. Detta kan resultera i antingen ett ohanterat undantag eller felaktiga utdata.
  • Under vissa sällsynta förhållanden kan ett villkorligt bittest returnera det felaktiga Boolean värdet eller utlösa ett undantag om kompilatoroptimeringar är aktiverade.
  • Under vissa förhållanden, om en if -instruktion används för att testa för ett villkor innan du anger ett try block och i slutet från try blocket, och samma villkor utvärderas i catch eller finally -blocket, tar den nya 64-bitars JIT-kompilatorn bort villkoret if catch från eller finally -blocket när koden optimeras. Därför körs kod i -instruktionen if catch i eller finally -blocket villkorslöst.

Förslag

Åtgärda kända problem
Om du stöter på problemen ovan kan du åtgärda dem genom att göra något av följande:

  • Uppgradera till .NET Framework 4.6.2. Den nya 64-bitars kompilatorn som ingår i .NET Framework 4.6.2 åtgärdar vart och ett av dessa kända problem.

  • Kontrollera att din version av Windows är uppdaterad genom att köra Windows Update. Tjänstuppdateringar till .NET Framework 4.6 och 4.6.1 löser vart och ett av dessa problem förutom NullReferenceException i en unboxing-åtgärd.

  • Kompilera med den äldre 64-bitars JIT-kompilatorn. Mer information om hur du gör detta finns i avsnittet Åtgärda andra problem . Åtgärd av andra problem
    Om du stöter på någon annan skillnad i beteende mellan kod som kompilerats med den äldre 64-bitars kompilatorn och den nya 64-bitars JIT-kompilatorn, eller mellan felsöknings- och versionsversionerna av din app som båda kompileras med den nya 64-bitars JIT-kompilatorn, kan du göra följande för att kompilera din app med den äldre 64-bitars JIT-kompilatorn:

  • Du kan lägga till elementet < i programmets konfigurationsfil per program. Följande inaktiverar kompilering med den nya 64-bitars JIT-kompilatorn och använder i stället den äldre 64-bitars JIT-kompilatorn.

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

  • Per användare kan du lägga till ett REG_DWORD värde med namnet useLegacyJit till HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework registrets nyckel. Värdet 1 aktiverar den äldre 64-bitars JIT-kompilatorn. värdet 0 inaktiverar det och aktiverar den nya 64-bitars JIT-kompilatorn.

  • Per dator kan du lägga till ett REG_DWORD värde med namnet useLegacyJit till HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework nyckeln i registret. Värdet 1 aktiverar den äldre 64-bitars JIT-kompilatorn. Värdet 0 inaktiverar den och aktiverar den nya 64-bitars JIT-kompilatorn. Du kan också meddela oss om problemet genom att rapportera en bugg på Microsoft Connect.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Nätverk

EKU-verifiering av certifikat

Details

Från och med .NET Framework 4.6 SslStream utför eller ServicePointManager -klasserna EKU-objektidentifierare (OID). Ett tillägg för förbättrad nyckelanvändning (EKU) är en samling objektidentifierare (OID) som anger vilka program som använder nyckeln. EKU OID-validering använder fjärrcertifikatåteranrop för att säkerställa att fjärrcertifikatet har rätt OID för det avsedda ändamålet.

Förslag

Om den här ändringen inte är önskvärd kan du inaktivera EKU OID-validering av certifikat genom att lägga till följande växel i <AppContextSwitchOverrides> i ` appkonfigurationsfilen:

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

Viktigt!

Den här inställningen tillhandahålls endast för bakåtkompatibilitet. Dess användning rekommenderas annars inte.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

Endast Tls 1.0-, 1.1- och 1.2-protokoll som stöds i System.Net.ServicePointManager och System.Net.Security.SslStream

Details

Från och med .NET Framework 4.6 ServicePointManager tillåts klasserna och SslStream endast använda något av följande tre protokoll: Tls1.0, Tls1.1 eller Tls1.2. SSL3.0-protokollet och RC4-chiffer stöds inte.

Förslag

Den rekommenderade åtgärden är att uppgradera appen på serversidan till Tls1.0, Tls1.1 eller Tls1.2. Om detta inte är möjligt, eller om klientappar bryts, System.AppContext kan klassen användas för att välja bort den här funktionen på något av två sätt:

  • Genom att programmatiskt ställa in kompatibilitetsväxlar på System.AppContext, som förklaras här.
  • Genom att lägga till följande rad i <runtime> avsnittet i filen app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

TLS 1.x skickar som standard flaggan SCH_SEND_AUX_RECORD till det underliggande SCHANNEL-API:et

Details

När du använder TLS 1.x förlitar sig .NET Framework på det underliggande Windows SCHANNEL-API:et. Från och med .NET Framework 4.6 skickas flaggan SCH_SEND_AUX_RECORD som standard till SCHANNEL. Detta gör att SCHANNEL delar upp data i två separata poster, den första som en enda byte och den andra som n-1 byte. I sällsynta fall bryter detta kommunikationen mellan klienter och befintliga servrar som gör antagandet att data finns i en enda post.

Förslag

Om den här ändringen bryter kommunikationen med en befintlig server kan du inaktivera sändning av flaggan SCH_SEND_AUX_RECORD och återställa det tidigare beteendet att inte dela upp data i separata poster genom att lägga till följande växling till elementet <AppContextSwitchOverrides> <runtime> i avsnittet i appkonfigurationsfilen:

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

Viktigt!

Den här inställningen tillhandahålls endast för bakåtkompatibilitet. Dess användning rekommenderas annars inte.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Berörda API:er

Windows Communication Foundation (WCF)

Att anropa CreateDefaultAuthorizationContext med ett null-argument har ändrats

Details

Implementeringen av det System.IdentityModel.Policy.AuthorizationContext som returneras av ett anrop till System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argumentet med null authorizationPolicies har ändrat dess implementering i .NET Framework 4.6.

Förslag

I sällsynta fall kan WCF-appar som använder anpassad autentisering se beteendeskillnader. I sådana fall kan det tidigare beteendet återställas på något av två sätt:

  • Kompilera om din app till en tidigare version av .NET Framework än 4.6. För IIS-värdbaserade tjänster använder du -elementet <httpRuntime targetFramework="x.x"> för att rikta in sig på en tidigare version av .NET Framework.

  • Lägg till följande rad i <appSettings> avsnittet i filen app.config:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

Windows Forms

Icon.ToBitmap konverterar ikoner med PNG-ramar till bitmappsobjekt

Details

Från och med de appar som riktar sig mot .NET Framework 4.6 Icon.ToBitmap konverterar metoden ikoner med PNG-ramar till Bitmap-objekt.

I appar som riktar sig mot .NET Framework 4.5.2 och tidigare versioner Icon.ToBitmap utlöser metoden ett ArgumentOutOfRangeException undantag om Ikonobjektet har PNG-ramar.

Den här ändringen påverkar appar som omkompileras för att rikta in sig på .NET Framework 4.6 och som implementerar särskild hantering för ArgumentOutOfRangeException det som genereras när ett Ikonobjekt har PNG-ramar. När du kör under .NET Framework 4.6 lyckas konverteringen, en ArgumentOutOfRangeException genereras inte längre och därför anropas inte undantagshanteraren längre.

Förslag

Om det här beteendet är oönskat kan du behålla det tidigare beteendet genom att lägga till följande element i <runtime> avsnittet i filen app.config:

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

Om filen app.config redan innehåller elementet AppContextSwitchOverrides ska det nya värdet sammanfogas med värdeattributet så här:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

Windows Presentation Foundation (WPF)

CurrentCulture bevaras inte i WPF Dispatcher-åtgärder

Details

Från och med .NET Framework 4.6 går ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture görs i en System.Windows.Threading.Dispatcher förlorade i slutet av den dispatcher-åtgärden. På samma sätt kanske ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture görs utanför en Dispatcher-åtgärd inte återspeglas när åtgärden körs. Praktiskt taget innebär detta att System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture ändringar kanske inte flödar mellan WPF UI-återanrop och annan kod i ett WPF-program. Detta beror på en ändring i System.Threading.ExecutionContext som gör System.Globalization.CultureInfo.CurrentCulture att och System.Globalization.CultureInfo.CurrentUICulture lagras i körningskontexten som börjar med appar som riktar sig till .NET Framework 4.6. WPF-avsändare lagrar körningskontexten som används för att starta åtgärden och återställa den tidigare kontexten när åtgärden har slutförts. Eftersom System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture nu är en del av den kontexten sparas inte ändringar i dem i en dispatcher-åtgärd utanför åtgärden.

Förslag

Appar som påverkas av den här ändringen kan kringgå den genom att lagra önskade System.Globalization.CultureInfo.CurrentCulture eller System.Globalization.CultureInfo.CurrentUICulture i ett fält och checka in alla Dispatcher-åtgärdsorgan (inklusive UI-händelseåteranropshanterare) som är korrekta System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture har angetts. Alternativt, eftersom ExecutionContext-ändringen som ligger till grund för den här WPF-ändringen endast påverkar appar som är riktade mot .NET Framework 4.6 eller senare, kan den här pausen undvikas genom att rikta in sig på .NET Framework 4.5.2.Apps som riktar sig mot .NET Framework 4.6 eller senare kan också kringgå detta genom att ange följande kompatibilitetsväxel:

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

Det här problemet har åtgärdats av WPF i .NET Framework 4.6.2. Det har också åtgärdats i .NET Frameworks 4.6, 4.6.1 via KB 3139549. Program som riktar sig till .NET Framework 4.6 eller senare får automatiskt rätt beteende i WPF-program – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) bevaras i olika Dispatcher-åtgärder.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

WPF-layoutens avrundning av marginaler har ändrats

Details

Det sätt på vilket marginalerna avrundas och kantlinjer och bakgrunden inuti dem har ändrats. Som ett resultat av den här ändringen:

  • Elementens bredd eller höjd kan växa eller krympa med högst en bildpunkt.
  • Placeringen av ett objekt kan flyttas med högst en pixel.
  • Centrerade element kan vara lodrätt eller vågrätt av mitten med högst en bildpunkt. Som standard är den här nya layouten endast aktiverad för appar som riktar sig mot .NET Framework 4.6.

Förslag

Eftersom den här ändringen tenderar att eliminera urklipp av WPF-kontroller till höger eller längst ned vid höga DPI:er kan appar som riktar sig mot tidigare versioner av .NET Framework men körs på .NET Framework 4.6 välja det här nya beteendet genom att lägga till <runtime> följande rad i avsnittet i filen app.config:

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

Appar som riktar in sig på .NET Framework 4.6 men vill att WPF-kontroller ska återges med hjälp av den tidigare layoutalgoritmen kan göra det genom att lägga till följande rad i <runtime> avsnittet i filen app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

XML, XSLT

XmlWriter kastar på ogiltiga surrogatpar

Details

För appar som riktar sig mot .NET Framework 4.5.2 eller tidigare versioner utlöser det inte alltid ett undantag att skriva ett ogiltigt surrogatpar med undantagshantering. För appar som riktar sig mot .NET Framework 4.6 genererar försök att skriva ett ogiltigt surrogatpar en System.ArgumentException.

Förslag

Om det behövs kan du undvika den här pausen genom att rikta in dig på .NET Framework 4.5.2 eller tidigare. Alternativt kan ogiltiga surrogatpar förbearbetas till giltig XML innan de skrivs.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Berörda API:er

XSD-schemaverifiering identifierar nu korrekt överträdelser av unika begränsningar om sammansatta nycklar används och en nyckel är tom

Details

Versioner av .NET Framework före 4.6 hade en bugg som gjorde att XSD-valideringen inte identifierade unika begränsningar för sammansatta nycklar om en av nycklarna var tom. I .NET Framework 4.6 korrigeras det här problemet. Detta resulterar i mer korrekt validering, men det kan också leda till att viss XML inte verifierar vilket tidigare skulle ha gjort det.

Förslag

Om en lös .NET Framework 4.0-validering krävs kan valideringsprogrammet rikta in sig på version 4.5 (eller tidigare) av .NET Framework. När du omdirigerar till .NET Framework 4.6 bör dock kodgranskning göras för att se till att dubbletter av sammansatta nycklar (som beskrivs i beskrivningen av det här problemet) inte förväntas verifiera.

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

.NET Framework 4.6.1

Kärna

Ändra sökvägsavgränsartecken i egenskapen FullName för ZipArchiveEntry-objekt

Details

För appar som riktar in sig på .NET Framework 4.6.1 och senare versioner har sökvägsavgränsartecknet ändrats från ett omvänt snedstreck ("\") till ett snedstreck ("/") i FullName egenskapen ZipArchiveEntry för objekt som skapats av överlagringar av CreateFromDirectory metoden. Ändringen bringar .NET-implementeringen i överensstämmelse med avsnitt 4.4.17.1 i .ZIP-filformatspecifikationen och gör att .ZIP arkiv kan dekomprimeras på icke-Windows-system.
Det går inte att bevara katalogstrukturen genom att expandera en zip-fil som skapats av en app som riktar sig mot en tidigare version av .NET Framework på andra operativsystem än Windows, till exempel Macintosh. På Macintosh skapas till exempel en uppsättning filer vars filnamn sammanfogar katalogsökvägen, tillsammans med eventuella omvänt snedstreck ("\") och filnamnet. Därför bevaras inte katalogstrukturen för dekomprimerade filer.

Förslag

Effekten av den här ändringen på .ZIP filer som komprimeras på Windows-operativsystemet av API:er i .NET Framework-namnområdet System.IO bör vara minimal, eftersom dessa API:er sömlöst kan hantera antingen ett snedstreck ("/") eller ett omvänt snedstreck ("\") som sökvägsavgränsare.
Om den här ändringen inte är önskvärd kan du välja bort den genom att lägga till en konfigurationsinställning i <runtime> avsnittet i programkonfigurationsfilen. I följande exempel visas både <runtime> avsnittet och avaktiveringsväxeln Switch.System.IO.Compression.ZipFile.UseBackslash :

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

Dessutom kan appar som riktar sig mot tidigare versioner av .NET Framework men som körs på .NET Framework 4.6.1 och senare versioner välja det här beteendet genom att lägga till <runtime> en konfigurationsinställning i avsnittet i programkonfigurationsfilen. Följande visar både <runtime> avsnittet och Switch.System.IO.Compression.ZipFile.UseBackslash opt-in-växeln.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Name Värde
Omfång Edge
Version 4.6.1
Typ Ommåla

Berörda API:er

Windows Communication Foundation (WCF)

WCF-bindning med säkerhetsläget TransportWithMessageCredential

Details

Från och med .NET Framework 4.6.1 kan WCF-bindning som använder säkerhetsläget TransportWithMessageCredential konfigureras för att ta emot meddelanden med osignerade "till"-huvuden för asymmetriska säkerhetsnycklar. Som standard kommer osignerade "till"-huvuden att fortsätta att avvisas i .NET Framework 4.6.1. De godkänns endast om ett program väljer det nya driftsläget med hjälp av konfigurationsväxeln Switch.System.ServiceModel.AllowUnsignedToHeader.

Förslag

Eftersom det här är en opt-in-funktion bör det inte påverka beteendet för befintliga appar.
Om du vill kontrollera om det nya beteendet används eller inte använder du följande konfigurationsinställning:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Name Värde
Omfång Transparent
Version 4.6.1
Typ Ommåla

Berörda API:er

X509CertificateClaimSet.FindClaims tar hänsyn till alla claimTypes

Details

Om en X509-anspråksuppsättning initieras från ett certifikat som har flera DNS-poster i SAN-fältet System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) i appar som riktar sig mot .NET Framework 4.6.1, försöker metoden matcha argumentet claimType med alla DNS-poster. För appar som riktar sig mot tidigare versioner av .NET Framework System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) försöker metoden endast matcha argumentet claimType med den senaste DNS-posten.

Förslag

Den här ändringen påverkar endast program som riktar sig till .NET Framework 4.6.1. Den här ändringen kan inaktiveras (eller aktiveras om den är riktad mot pre-4.6.1) med kompatibilitetsväxeln DisableMultipleDNSEntries .

Name Värde
Omfång Mindre
Version 4.6.1
Typ Ommåla

Berörda API:er

Windows Forms

Application.FilterMessage genererar inte längre för implementeringar av IMessageFilter.PreFilterMessage

Details

Innan .NET Framework 4.6.1 anropas med en PreFilterMessage(Message) som anropar System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) eller System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (även anropar DoEvents()) skulle orsaka en System.IndexOutOfRangeException.FilterMessage(Message)

Från och med program som riktar sig till .NET Framework 4.6.1 genereras inte längre det här undantaget, och filter för återinträde enligt beskrivningen ovan kan användas.

Förslag

Tänk på att inte längre kommer att FilterMessage(Message) utlösas för det beteende för återdeltagare PreFilterMessage(Message) som beskrivs ovan. Detta påverkar endast program som riktar sig till .NET Framework 4.6.1.Apps som riktar sig till .NET Framework 4.6.1 kan välja bort den här ändringen (eller appar som riktar sig till äldre ramverk kan välja att delta) med hjälp av kompatibilitetsväxeln DontSupportReentrantFilterMessage .

Name Värde
Omfång Edge
Version 4.6.1
Typ Ommåla

Berörda API:er

Windows Presentation Foundation (WPF)

Anrop till System.Windows.Input.PenContext.Disable på touch-aktiverade system kan utlösa ett ArgumentException

Details

Under vissa omständigheter kan anrop till den interna metoden System.Windows.Intput.PenContext.Disable på touch-aktiverade system utlösa en ohanterad T:System.ArgumentException på grund av återaktivering.

Förslag

Det här problemet har åtgärdats i .NET Framework 4.7. Om du vill förhindra undantaget uppgraderar du till en version av .NET Framework som börjar med .NET Framework 4.7.

Name Värde
Omfång Edge
Version 4.6.1
Typ Ommåla

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath kastar en NullReferenceException

Details

I .NET Framework 4.6.2 genererar körningen ett T:System.NullReferenceException när ett P:System.Web.HttpRuntime.AppDomainAppPath värde som innehåller null-tecken hämtas. I .NET Framework 4.6.1 och tidigare versioner genererar körningen en T:System.ArgumentNullException.

Förslag

Du kan göra något av följande för att svara på den här ändringen:

  • T:System.NullReferenceException Hantera om du-programmet körs på .NET Framework 4.6.2.
  • Uppgradera till .NET Framework 4.7, som återställer det tidigare beteendet och genererar en T:System.ArgumentNullException.
Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

Kärna

AesCryptoServiceProvider decryptor tillhandahåller en återanvändbar transformering

Details

Från och med appar som riktar sig mot .NET Framework 4.6.2 tillhandahåller AesCryptoServiceProvider dekryptatorn en återanvändbar transformering. Efter ett anrop till System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)initieras transformen igen och kan återanvändas. För appar som riktar in sig på tidigare versioner av .NET Framework försöker du återanvända dekryptatorn genom att anropa System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) efter ett anrop för att System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) generera skadade CryptographicException data.

Förslag

Effekten av den här ändringen bör vara minimal, eftersom detta är det förväntade beteendet. Program som är beroende av det tidigare beteendet kan välja bort det genom att lägga till följande konfigurationsinställning i <runtime> avsnittet i programmets konfigurationsfil:

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

Dessutom kan program som riktar sig mot en tidigare version av .NET Framework men som körs under en version av .NET Framework från och med .NET Framework 4.6.2 välja att använda det genom att lägga till följande konfigurationsinställning <runtime> i avsnittet i programmets konfigurationsfil:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Name Värde
Omfång Mindre
Version 4.6.2
Typ Ommåla

Berörda API:er

Anrop till ClaimsIdentity-konstruktorer

Details

Från och med .NET Framework 4.6.2 sker en ändring i hur ClaimsIdentity konstruktorer med en System.Security.Principal.IIdentity parameter anger System.Security.Claims.ClaimsIdentity.Actor egenskapen. System.Security.Principal.IIdentity Om argumentet är ett ClaimsIdentity objekt och System.Security.Claims.ClaimsIdentity.Actor egenskapen för det ClaimsIdentity objektet inte nullär , System.Security.Claims.ClaimsIdentity.Actor kopplas egenskapen med hjälp Clone() av metoden . I Framework 4.6.1 och tidigare versioner System.Security.Claims.ClaimsIdentity.Actor kopplas egenskapen som en befintlig referens. På grund av den här ändringen, från och med .NET Framework 4.6.2, System.Security.Claims.ClaimsIdentity.Actor är egenskapen för det nya ClaimsIdentity objektet inte lika System.Security.Claims.ClaimsIdentity.Actor med egenskapen för konstruktorns System.Security.Principal.IIdentity argument. I .NET Framework 4.6.1 och tidigare versioner är det lika med.

Förslag

Om det här beteendet är oönskat kan du återställa det tidigare beteendet genom att ange växeln Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity i programkonfigurationsfilen till true. Detta kräver att du lägger till följande i <runtime> avsnittet i filen web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

Ändringar i sökvägsnormalisering

Details

Från och med appar som riktar in sig på .NET Framework 4.6.2 har det sätt på vilket körningen normaliserar sökvägar ändrats. Normalisering av en sökväg innebär att ändra strängen som identifierar en sökväg eller fil så att den överensstämmer med en giltig sökväg i måloperativsystemet. Normalisering omfattar vanligtvis:

  • Kanonisera komponent- och katalogavgränsare.
  • Tillämpa den aktuella katalogen på en relativ sökväg.
  • Utvärdera den relativa katalogen (.) eller den överordnade katalogen (..) i en sökväg.
  • Trimma angivna tecken. Från och med appar som riktar sig mot .NET Framework 4.6.2 aktiveras följande ändringar i sökvägsnormalisering som standard:
  • Normalisering innebär inte längre att slutet av katalogsegmenten trimmas (till exempel ett blanksteg i slutet av ett katalognamn).
  • Stöd för syntax för enhetssökväg i fullständigt förtroende, inklusive \\.\ och för fil-I/O-API:er i mscorlib.dll, \\?\.
  • Körningen validerar inte enhetssyntaxsökvägar.
  • Användning av enhetssyntax för åtkomst till alternativa dataströmmar stöds. Dessa ändringar förbättrar prestanda samtidigt som metoder kan komma åt tidigare otillgängliga sökvägar. Appar som riktar sig mot .NET Framework 4.6.1 och tidigare versioner men som körs under .NET Framework 4.6.2 eller senare påverkas inte av den här ändringen.

Förslag

Appar som riktar sig mot .NET Framework 4.6.2 eller senare kan välja bort den här ändringen och använda äldre normalisering genom att lägga till följande i <runtime> avsnittet i programkonfigurationsfilen:

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

Appar som riktar in sig på .NET Framework 4.6.1 eller tidigare men som körs på .NET Framework 4.6.2 eller senare kan aktivera ändringar i sökvägsnormalisering genom att lägga till följande rad i <runtime> avsnittet i programmets .configuration-fil:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Name Värde
Omfång Mindre
Version 4.6.2
Typ Ommåla

CurrentCulture- och CurrentUICulture-flöde mellan aktiviteter

Details

Från och med .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture lagras i trådens System.Threading.ExecutionContext, som flödar över asynkrona åtgärder. Det innebär att ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture återspeglas i aktiviteter som senare körs asynkront. Detta skiljer sig från beteendet för tidigare .NET Framework-versioner (som skulle återställas System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture i alla asynkrona uppgifter).

Förslag

Appar som påverkas av den här ändringen kan kringgå den genom att uttryckligen ange önskad System.Globalization.CultureInfo.CurrentCulture åtgärd eller System.Globalization.CultureInfo.CurrentUICulture som den första åtgärden i en asynkron aktivitet. Du kan också välja det gamla beteendet (för att System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICultureinte flöda) genom att ange följande kompatibilitetsväxel:

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

Det här problemet har åtgärdats av WPF i .NET Framework 4.6.2. Det har också åtgärdats i .NET Frameworks 4.6, 4.6.1 via KB 3139549. Program som riktar sig till .NET Framework 4.6 eller senare får automatiskt rätt beteende i WPF-program – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) bevaras i olika Dispatcher-åtgärder.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla

Berörda API:er

ETW-händelsenamn kan inte bara skilja sig åt med suffixet "Start" eller "Stop"

Details

I .NET Framework 4.6 och 4.6.1 genererar körningen en ArgumentException när två händelsespårning för Windows -händelsenamn (ETW) endast skiljer sig åt med suffixet "Start" eller "Stop" (som när en händelse namnges LogUser och en annan heter LogUserStart). I det här fallet kan körningen inte konstruera händelsekällan, som inte kan generera någon loggning.

Förslag

Om du vill förhindra undantaget kontrollerar du att inga två händelsenamn endast skiljer sig åt med suffixet "Start" eller "Stop". Det här kravet tas bort från och med .NET Framework 4.6.2. körningen kan skilja händelsenamn som endast skiljer sig åt med suffixet "Start" och "Stop".

Name Värde
Omfång Edge
Version 4,6
Typ Ommåla

Stöd för lång sökväg

Details

Från och med appar som riktar sig mot .NET Framework 4.6.2 stöds långa sökvägar (upp till 32 000 tecken) och begränsningen på 260 tecken (eller MAX_PATH) för sökvägslängder har tagits bort. För appar som har omkompilerats för att rikta in sig på .NET Framework 4.6.2 genererar kodsökvägar som tidigare kastade en System.IO.PathTooLongException eftersom en sökväg överskred 260 tecken nu endast en System.IO.PathTooLongException under följande villkor:

  • Sökvägens längd är större än MaxValue (32 767) tecken.
  • Operativsystemet returnerar COR_E_PATHTOOLONG eller motsvarande. För appar som riktar sig mot .NET Framework 4.6.1 och tidigare versioner genererar körningen automatiskt en System.IO.PathTooLongException när en sökväg överskrider 260 tecken.

Förslag

För appar som riktar sig till .NET Framework 4.6.2 kan du välja bort stöd för långa sökvägar om det inte är önskvärt genom att lägga till följande i <runtime> avsnittet i app.config filen:

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

För appar som riktar in sig på tidigare versioner av .NET Framework men körs på .NET Framework 4.6.2 eller senare kan du välja stöd för långa sökvägar genom att lägga till <runtime> följande i avsnittet i app.config filen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Name Värde
Omfång Mindre
Version 4.6.2
Typ Ommåla

Sökvägskolonkontroller är striktare

Details

I .NET Framework 4.6.2 gjordes ett antal ändringar för att stödja sökvägar som tidigare inte stöds (både i längd och format). Kontroller av korrekt syntax för enhetsavgränsare (kolon) har korrigerats, vilket hade sidoeffekten att blockera vissa URI-sökvägar i några få sökvägs-API:er där de tidigare tolererades.

Förslag

Om du skickar en URI till berörda API:er ändrar du strängen till att först vara en juridisk sökväg.

  • Ta bort schemat från URL:er manuellt (till exempel ta bort file:// från URL:er).

  • Skicka URI:n till Uri klassen och använd LocalPath.

Du kan också välja bort den nya sökvägsnormaliseringen genom att ange AppContext-växeln Switch.System.IO.UseLegacyPathHandling till true.

Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

Säkerhet

RSACng läser nu in RSA-nycklar med icke-standardnyckelstorlek

Details

I .NET Framework-versioner före 4.6.2 kan kunder med icke-standardnyckelstorlekar för RSA-certifikat inte komma åt dessa nycklar via tilläggsmetoderna System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) och System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) . A System.Security.Cryptography.CryptographicException med meddelandet "Den begärda nyckelstorleken stöds inte" genereras. I .NET Framework 4.6.2 har det här problemet åtgärdats. ImportParameters(RSAParameters) På samma sätt, och ImportParameters(RSAParameters) nu arbeta med icke-standard nyckelstorlekar utan att kasta en System.Security.Cryptography.CryptographicException.

Förslag

Om det finns någon undantagshanteringslogik som förlitar sig på det tidigare beteendet där en System.Security.Cryptography.CryptographicException genereras när icke-standardnyckelstorlekar används kan du överväga att ta bort logiken.

Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

SignedXml.GetPublicKey returnerar RSACng på net462 (eller lightup) utan att ändra på nytt

Details

Från och med .NET Framework 4.6.2 ändrades den konkreta typen av objektet som returnerades av SignedXml.GetPublicKey metoden (utan egenhet) från en CryptoServiceProvider-implementering till en Cng-implementering. Det beror på att implementeringen har ändrats från att använda certificate.PublicKey.Key till att använda det interna certificate.GetAnyPublicKey som vidarebefordras till RSACertificateExtensions.GetRSAPublicKey.

Förslag

Från och med appar som körs på .NET Framework 4.7.1 kan du använda CryptoServiceProvider-implementeringen som standard i .NET Framework 4.6.1 och tidigare versioner genom att lägga till följande konfigurationsväxling i körningsavsnittet i appkonfigurationsfilen:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

Windows Communication Foundation (WCF)

Dödläge kan uppstå när du använder Reentrant-tjänster

Details

Ett dödläge kan resultera i en Reentrant-tjänst som begränsar instanser av tjänsten till en körningstråd i taget. Tjänster som är benägna att stöta på det här problemet har följande ServiceBehaviorAttribute i sin kod:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Förslag

Du kan åtgärda det här problemet genom att göra följande:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Installera den senaste uppdateringen av .NET Framework 4.6.2 eller uppgradera till en senare version av .NET Framework. Detta inaktiverar flödet i ExecutionContext i OperationContext.Current. Det här beteendet kan konfigureras. det motsvarar att lägga till följande appinställning i konfigurationsfilen:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Värdet Switch.System.ServiceModel.DisableOperationContextAsyncFlow för bör aldrig anges till false för Reentrant-tjänster.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Ommåla

Berörda API:er

OperationContext.Current kan returnera null när det anropas i en användningssats

Details

OperationContext.Current kan returnera null och ett NullReferenceException kan uppstå om alla följande villkor är uppfyllda:

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

    // ...
}

Förslag

Du kan åtgärda det här problemet genom att göra följande:

  • Ändra koden på följande sätt för att instansiera ett nytt icke-objekt null Current :

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

    // ...
}

  • Installera den senaste uppdateringen av .NET Framework 4.6.2 eller uppgradera till en senare version av .NET Framework. Detta inaktiverar inflödet ExecutionContext OperationContext.Current och återställer beteendet för WCF-program i .NET Framework 4.6.1 och tidigare versioner. Det här beteendet kan konfigureras. det motsvarar att lägga till följande appinställning i konfigurationsfilen:

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

    Om den här ändringen är oönskad och ditt program är beroende av körningskontext som flödar mellan åtgärdskontexter kan du aktivera dess flöde på följande sätt:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

WCF-transportsäkerhet stöder certifikat som lagras med CNG

Details

Från och med appar som riktar sig mot .NET Framework 4.6.2 stöder WCF-transportsäkerhet certifikat som lagras med hjälp av Windows Kryptografibibliotek (CNG). Det här stödet är begränsat till certifikat med en offentlig nyckel som inte har en exponent som är längre än 32 bitar. När ett program är avsett för .NET Framework 4.6.2 är den här funktionen aktiverad som standard. I tidigare versioner av .NET Framework utlöser försöket att använda X509-certifikat med en CSG-nyckellagringsprovider ett undantag.

Förslag

Appar som riktar sig mot .NET Framework 4.6.1 och tidigare men som körs på .NET Framework 4.6.2 kan aktivera stöd för CNG-certifikat genom att lägga till följande rad i <runtime> avsnittet i filen app.config eller web.config:

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

Detta kan också göras programmatiskt med följande kod:

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

AppContext.SetSwitch(disableCngCertificates, false);

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

Observera att på grund av den här ändringen kommer all undantagshanteringskod som är beroende av försöket att initiera säker kommunikation med ett CNG-certifikat att misslyckas inte längre att köras.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Ommåla

Windows Forms

Felaktig implementering av MemberDescriptor.Equals

Details

Den ursprungliga implementeringen av MemberDescriptor.Equals metoden jämför två olika strängegenskaper från de objekt som jämförs: kategorinamnet och beskrivningssträngen. Korrigeringen är att jämföra det Category första objektet Category med det andra objektet och det Description första med det Description andra.

Förslag

Om ditt program är beroende av att false ibland returnera när deskriptorer är likvärdiga och du riktar in dig på MemberDescriptor.Equals .NET Framework 4.6.2 eller senare, har du flera alternativ:

  • Gör kodändringar för att jämföra fälten Category och Description manuellt förutom att anropa MemberDescriptor.Equals metoden.
  • Avregistrera dig från den här ändringen genom att lägga till följande värde i filen app.config:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Om ditt program är avsett för .NET Framework 4.6.1 eller tidigare och körs på .NET Framework 4.6.2 eller senare och du vill att den här ändringen ska vara aktiverad, kan du ange kompatibilitetsväxlingen till genom att lägga till false följande värde i filen app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Name Värde
Omfång Edge
Version 4.6.2
Typ Ommåla

Berörda API:er

Windows Presentation Foundation (WPF)

CurrentCulture bevaras inte i WPF Dispatcher-åtgärder

Details

Från och med .NET Framework 4.6 går ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture görs i en System.Windows.Threading.Dispatcher förlorade i slutet av den dispatcher-åtgärden. På samma sätt kanske ändringar System.Globalization.CultureInfo.CurrentCulture i eller System.Globalization.CultureInfo.CurrentUICulture görs utanför en Dispatcher-åtgärd inte återspeglas när åtgärden körs. Praktiskt taget innebär detta att System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture ändringar kanske inte flödar mellan WPF UI-återanrop och annan kod i ett WPF-program. Detta beror på en ändring i System.Threading.ExecutionContext som gör System.Globalization.CultureInfo.CurrentCulture att och System.Globalization.CultureInfo.CurrentUICulture lagras i körningskontexten som börjar med appar som riktar sig till .NET Framework 4.6. WPF-avsändare lagrar körningskontexten som används för att starta åtgärden och återställa den tidigare kontexten när åtgärden har slutförts. Eftersom System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture nu är en del av den kontexten sparas inte ändringar i dem i en dispatcher-åtgärd utanför åtgärden.

Förslag

Appar som påverkas av den här ändringen kan kringgå den genom att lagra önskade System.Globalization.CultureInfo.CurrentCulture eller System.Globalization.CultureInfo.CurrentUICulture i ett fält och checka in alla Dispatcher-åtgärdsorgan (inklusive UI-händelseåteranropshanterare) som är korrekta System.Globalization.CultureInfo.CurrentCulture och System.Globalization.CultureInfo.CurrentUICulture har angetts. Alternativt, eftersom ExecutionContext-ändringen som ligger till grund för den här WPF-ändringen endast påverkar appar som är riktade mot .NET Framework 4.6 eller senare, kan den här pausen undvikas genom att rikta in sig på .NET Framework 4.5.2.Apps som riktar sig mot .NET Framework 4.6 eller senare kan också kringgå detta genom att ange följande kompatibilitetsväxel:

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

Det här problemet har åtgärdats av WPF i .NET Framework 4.6.2. Det har också åtgärdats i .NET Frameworks 4.6, 4.6.1 via KB 3139549. Program som riktar sig till .NET Framework 4.6 eller senare får automatiskt rätt beteende i WPF-program – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) bevaras i olika Dispatcher-åtgärder.

Name Värde
Omfång Mindre
Version 4,6
Typ Ommåla