Delen via

Wijzigingen voor migratie naar .NET Framework 4.6.x wijzigen

  • Artikel

Dit artikel bevat de compatibiliteitsproblemen met apps die zijn geïntroduceerd in .NET Framework 4.6, 4.6.1 en 4.6.2.

.NET framework 4.6

ASP.NET

HtmlTextWriter geeft het element niet correct weer <br/>

DETAILS

Vanaf .NET Framework 4.6 wordt met aanroepen RenderBeginTag(String) en RenderEndTag() met een <BR /> element slechts één <BR /> correct ingevoegd (in plaats van twee)

Suggestie

Als een app afhankelijk is van de extra <BR /> tag, RenderBeginTag(String) moet deze een tweede keer worden aangeroepen. Houd er rekening mee dat dit gedrag alleen van invloed is op apps die zijn gericht op .NET Framework 4.6 of hoger, dus een andere optie is om een eerdere versie van .NET Framework te gebruiken om het oude gedrag te verkrijgen.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Betrokken API's

ClickOnce

Apps die zijn gepubliceerd met ClickOnce die gebruikmaken van een SHA-256-certificaat voor ondertekening van programmacode, kunnen mislukken in Windows 2003

DETAILS

Het uitvoerbare bestand is ondertekend met SHA256. Voorheen was het ondertekend met SHA1, ongeacht of het certificaat voor ondertekening van programmacode SHA-1 of SHA-256 was. Dit is van toepassing op:

  • Alle toepassingen die zijn gebouwd met Visual Studio 2012 of hoger.
  • Toepassingen die zijn gebouwd met Visual Studio 2010 of eerder op systemen met .NET Framework 4.5 aanwezig. Als het .NET Framework 4.5 of hoger aanwezig is, wordt het ClickOnce-manifest ook ondertekend met SHA-256 voor SHA-256-certificaten, ongeacht de .NET Framework-versie waarop het is gecompileerd.

Suggestie

De wijziging in het ondertekenen van het uitvoerbare ClickOnce-bestand is alleen van invloed op Windows Server 2003-systemen; ze vereisen dat KB-938397 worden geïnstalleerd. De wijziging in het ondertekenen van het manifest met SHA-256, zelfs wanneer een app is gericht op .NET Framework 4.0 of eerdere versies, introduceert een runtime-afhankelijkheid van .NET Framework 4.5 of een latere versie.

Naam Weergegeven als
Bereik Edge
Versie 4.5
Type Opnieuw targeting

ClickOnce ondersteunt SHA-256 op 4.0-gerichte apps

DETAILS

Voorheen zou voor een ClickOnce-app met een certificaat dat is ondertekend met SHA-256 vereist dat .NET Framework 4.5 of hoger aanwezig is, zelfs als de app op 4.0 is gericht. Nu kunnen .NET Framework 4.0-gerichte ClickOnce-apps worden uitgevoerd op .NET Framework 4.0, zelfs als ze zijn ondertekend met SHA-256.

Suggestie

Met deze wijziging wordt die afhankelijkheid verwijderd en kunnen SHA-256-certificaten worden gebruikt om ClickOnce-apps te ondertekenen die gericht zijn op .NET Framework 4 en eerdere versies.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Basis

CurrentCulture- en CurrentUICulture-stroom tussen taken

DETAILS

Beginnend in .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture worden opgeslagen in de threads System.Threading.ExecutionContext, die stromen over asynchrone bewerkingen. Dit betekent dat wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture worden doorgevoerd in taken die later asynchroon worden uitgevoerd. Dit verschilt van het gedrag van eerdere .NET Framework-versies (die opnieuw zouden worden ingesteld System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture in alle asynchrone taken).

Suggestie

Apps die door deze wijziging worden beïnvloed, kunnen er omheen werken door expliciet de gewenste System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture als eerste bewerking in een asynchrone taak in te stellen. U kunt ook het oude gedrag (van niet stromen System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) kiezen door de volgende compatibiliteitsswitch in te stellen:

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

Dit probleem is opgelost door WPF in .NET Framework 4.6.2. Het is ook opgelost in .NET Frameworks 4.6, 4.6.1 tot en met KB 3139549. Toepassingen die gericht zijn op .NET Framework 4.6 of hoger, krijgen automatisch het juiste gedrag in WPF-toepassingen - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) blijven behouden voor dispatcherbewerkingen.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

ETW-gebeurtenisnamen kunnen niet alleen verschillen met een achtervoegsel 'Starten' of 'Stoppen'.

DETAILS

In .NET Framework 4.6 en 4.6.1 genereert de runtime een ArgumentException wanneer twee ETW-gebeurtenisnamen (Event Tracing for Windows) alleen verschillen met een achtervoegsel 'Starten' of 'Stoppen' (zoals wanneer een gebeurtenis een naam LogUser heeft en een andere naam LogUserStartheeft). In dit geval kan de runtime de gebeurtenisbron niet samenstellen, waardoor er geen logboekregistratie kan worden verzonden.

Suggestie

Om de uitzondering te voorkomen, moet u ervoor zorgen dat er slechts twee gebeurtenisnamen verschillen met het achtervoegsel 'Starten' of 'Stoppen'. Deze vereiste wordt verwijderd vanaf .NET Framework 4.6.2; de runtime kan namen van gebeurtenissen die alleen verschillen door het achtervoegsel 'Start' en 'Stop'.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Entity Framework

Het bouwen van een Entity Framework edmx met Visual Studio 2013 kan mislukken met fout MSB4062 als u de EntityDeploySplit- of EntityClean-taken gebruikt

DETAILS

MSBuild 12.0-hulpprogramma's (opgenomen in Visual Studio 2013) hebben MSBuild-bestandslocaties gewijzigd, waardoor oudere Entity Framework-doelenbestanden ongeldig zijn. Het resultaat is dat EntityDeploySplit taken EntityClean mislukken omdat ze niet kunnen worden gevonden Microsoft.Data.Entity.Build.Tasks.dll. Houd er rekening mee dat deze onderbreking te maken heeft met een toolset (MSBuild/VS), niet vanwege een .NET Framework-wijziging. Dit gebeurt alleen wanneer u ontwikkelhulpprogramma's bijwerkt, niet wanneer u alleen het .NET Framework bijwerkt.

Suggestie

Entity Framework-doelenbestanden zijn vast voor gebruik met de nieuwe MSBuild-indeling vanaf .NET Framework 4.6. Als u een upgrade uitvoert naar die versie van het Framework, wordt dit probleem opgelost. U kunt deze tijdelijke oplossing ook gebruiken om de doelbestanden rechtstreeks te patchen.

Naam Weergegeven als
Bereik Primair
Versie 4.5.1
Type Opnieuw targeting

JIT

IL ret niet toegestaan in een try-regio

DETAILS

In tegenstelling tot de JIT64 Just-In-Time-compiler staat RyuJIT (gebruikt in .NET Framework 4.6) geen IL-instructie toe in een try-regio. Terugkeren vanuit een try-regio is niet toegestaan door de ECMA-335-specificatie en geen bekende beheerde compiler genereert een dergelijke IL. De JIT64-compiler voert dergelijke IL echter uit als deze wordt gegenereerd met behulp van reflectie-emit.

Suggestie

Als een app IL genereert die een ret-opcode in een try-regio bevat, kan de app zich richten op .NET Framework 4.5 om de oude JIT te gebruiken en deze onderbreking te voorkomen. U kunt de gegenereerde IL ook bijwerken om terug te keren na de probeerregio.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Nieuwe 64-bits JIT-compiler in .NET Framework 4.6

DETAILS

Vanaf .NET Framework 4.6 wordt een nieuwe 64-bits JIT-compiler gebruikt voor Just-In-Time-compilatie. In sommige gevallen wordt een onverwachte uitzondering gegenereerd of wordt een ander gedrag waargenomen dan wanneer een app wordt uitgevoerd met behulp van de 32-bits compiler of de oudere 64-bits JIT-compiler. Deze wijziging heeft geen invloed op de 32-bits JIT-compiler. De bekende verschillen zijn onder andere:

  • Onder bepaalde voorwaarden kan een uitboxing-bewerking een NullReferenceException release-builds genereren met optimalisatie ingeschakeld.
  • In sommige gevallen kan de uitvoering van productiecode in een grote methodetekst een StackOverflowException.
  • Onder bepaalde voorwaarden worden structuren die worden doorgegeven aan een methode behandeld als referentietypen in plaats van als waardetypen in Release-builds. Een van de manifestaties van dit probleem is dat de afzonderlijke items in een verzameling in een onverwachte volgorde worden weergegeven.
  • Onder bepaalde omstandigheden is de vergelijking van UInt16 waarden met hun hoge bitset onjuist als optimalisatie is ingeschakeld.
  • Onder bepaalde omstandigheden, met name bij het initialiseren van matrixwaarden, kan de initialisatie van het geheugen door de OpCodes.Initblk IL-instructie geheugen initialiseren met een onjuiste waarde. Dit kan resulteren in een niet-verwerkte uitzondering of onjuiste uitvoer.
  • Onder bepaalde zeldzame omstandigheden kan een voorwaardelijke bittest de onjuiste Boolean waarde retourneren of een uitzondering genereren als compileroptimalisaties zijn ingeschakeld.
  • Als onder bepaalde voorwaarden een if instructie wordt gebruikt om te testen op een voorwaarde voordat u een try blok invoert en in de uitgang van het try blok, en dezelfde voorwaarde wordt geëvalueerd in het catch of finally blok, verwijdert de nieuwe 64-bits JIT-compiler de if voorwaarde uit de catch of finally blokkering wanneer code wordt geoptimaliseerd. Als gevolg hiervan wordt code in de if instructie in het catch of finally blok onvoorwaardelijke uitgevoerd.

Suggestie

Beperking van bekende problemen
Als u de bovenstaande problemen ondervindt, kunt u deze oplossen door een van de volgende handelingen uit te voeren:

  • Voer een upgrade uit naar .NET Framework 4.6.2. De nieuwe 64-bits compiler die deel uitmaakt van .NET Framework 4.6.2, lost elk van deze bekende problemen op.

  • Zorg ervoor dat uw versie van Windows up-to-date is door Windows Update uit te voeren. Service-updates voor .NET Framework 4.6 en 4.6.1 verhelpen elk van deze problemen, behalve de NullReferenceException in een uitbox-bewerking.

  • Compileer met de oudere 64-bits JIT-compiler. Zie de sectie Oplossingen voor andere problemen voor meer informatie over hoe u dit doet. Risicobeperking van andere problemen
    Als er een ander verschil in gedrag is tussen code die is gecompileerd met de oudere 64-bits compiler en de nieuwe 64-bits JIT-compiler, of tussen de foutopsporings- en releaseversies van uw app die beide zijn gecompileerd met de nieuwe 64-bits JIT-compiler, kunt u het volgende doen om uw app te compileren met de oudere 64-bits JIT-compiler:

  • Per toepassing kunt u het element toevoegen aan het < configuratiebestand van uw toepassing. Met het volgende wordt compilatie met de nieuwe 64-bits JIT-compiler uitgeschakeld en wordt in plaats daarvan de verouderde 64-bits JIT-compiler gebruikt.

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

  • U kunt per gebruiker een REG_DWORD waarde met de naam useLegacyJit toevoegen aan de HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework sleutel van het register. Een waarde van 1 maakt de verouderde 64-bits JIT-compiler mogelijk; met de waarde 0 wordt deze uitgeschakeld en wordt de nieuwe 64-bits JIT-compiler ingeschakeld.

  • U kunt per machine een REG_DWORD waarde met de naam useLegacyJit toevoegen aan de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework sleutel van het register. Een waarde van het inschakelen van 1 de verouderde 64-bits JIT-compiler; een waarde van het uitschakelen en het inschakelen van 0 de nieuwe 64-bits JIT-compiler. U kunt ons ook op de hoogte stellen van het probleem door een bug in Microsoft Connect te melden.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Netwerken

Certificaat-EKU OID-validatie

DETAILS

Vanaf .NET Framework 4.6 voeren de SslStream of ServicePointManager klassen een OID-validatie (Enhanced Key Use) uit. Een uitbreiding voor uitgebreid sleutelgebruik (EKU) is een verzameling object-id's (OID's) die de toepassingen aangeven die gebruikmaken van de sleutel. EKU OID-validatie maakt gebruik van callbacks van externe certificaten om ervoor te zorgen dat het externe certificaat de juiste OID's voor het beoogde doel heeft.

Suggestie

Als deze wijziging ongewenst is, kunt u certificaat-EKU OID-validatie uitschakelen door de volgende switch toe te voegen aan de <AppContextSwitchOverrides> in het configuratiebestand van uw ` app:

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

Belangrijk

Deze instelling is alleen beschikbaar voor compatibiliteit met eerdere versies. Het gebruik wordt anders niet aanbevolen.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

Alleen tls 1.0-, 1.1- en 1.2-protocollen die worden ondersteund in System.Net.ServicePointManager en System.Net.Security.SslStream

DETAILS

Vanaf .NET Framework 4.6 mogen de ServicePointManager en SslStream klassen slechts een van de volgende drie protocollen gebruiken: Tls1.0, Tls1.1 of Tls1.2. Het SSL3.0-protocol en RC4-codering worden niet ondersteund.

Suggestie

De aanbevolen oplossing is om de app aan de serverzijde te upgraden naar Tls1.0, Tls1.1 of Tls1.2. Als dit niet haalbaar is of als client-apps zijn verbroken, kan de System.AppContext klasse worden gebruikt om deze functie op twee manieren uit te schakelen:

  • Door programmatisch compatibiliteitsschakelaars in te stellen op de System.AppContext, zoals hier wordt uitgelegd.
  • Door de volgende regel toe te voegen aan de <runtime> sectie van het bestand app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

TLS 1.x geeft standaard de vlag SCH_SEND_AUX_RECORD door aan de onderliggende SCHANNEL-API

DETAILS

Wanneer u TLS 1.x gebruikt, is .NET Framework afhankelijk van de onderliggende Windows SCHANNEL-API. Vanaf .NET Framework 4.6 wordt de vlag SCH_SEND_AUX_RECORD standaard doorgegeven aan SCHANNEL. Dit zorgt ervoor dat SCHANNEL gegevens in twee afzonderlijke records splitst, de eerste als één byte en de tweede als n-1 bytes. In zeldzame gevallen wordt de communicatie tussen clients en bestaande servers verbroken die ervan uitgaan dat de gegevens zich in één record bevinden.

Suggestie

Als deze wijziging de communicatie met een bestaande server onderbreekt, kunt u het verzenden van de SCH_SEND_AUX_RECORD vlag uitschakelen en het vorige gedrag herstellen van het niet splitsen van gegevens in afzonderlijke records door de volgende schakeloptie toe te voegen aan het element in de <AppContextSwitchOverrides> sectie van uw <runtime> app-configuratiebestand:

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

Belangrijk

Deze instelling is alleen beschikbaar voor compatibiliteit met eerdere versies. Het gebruik wordt anders niet aanbevolen.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Betrokken API's

Windows Communication Foundation (WCF)

CreateDefaultAuthorizationContext aanroepen met een null-argument is gewijzigd

DETAILS

De implementatie van de System.IdentityModel.Policy.AuthorizationContext geretourneerde door een aanroep naar het System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argument null authorizationPolicies heeft de implementatie in .NET Framework 4.6 gewijzigd.

Suggestie

In zeldzame gevallen kunnen WCF-apps die gebruikmaken van aangepaste verificatie gedragsverschillen zien. In dergelijke gevallen kan het vorige gedrag op twee manieren worden hersteld:

  • Uw app opnieuw compileren om een eerdere versie van .NET Framework te gebruiken dan 4.6. Gebruik het <httpRuntime targetFramework="x.x"> element voor iis-gehoste services om een eerdere versie van .NET Framework te gebruiken.

  • Voeg de volgende regel toe aan de <appSettings> sectie van uw app.config-bestand:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

Windows Forms

Icon.ToBitmap converteert pictogrammen met PNG-frames naar Bitmapobjecten

DETAILS

Vanaf de apps die gericht zijn op .NET Framework 4.6, converteert de Icon.ToBitmap methode pictogrammen met PNG-frames naar Bitmapobjecten.

In apps die zijn gericht op .NET Framework 4.5.2 en eerdere versies, genereert de Icon.ToBitmap methode een ArgumentOutOfRangeException uitzondering als het pictogramobject PNG-frames bevat.

Deze wijziging is van invloed op apps die opnieuw worden gecompileerd om te worden gericht op .NET Framework 4.6 en die speciale verwerking implementeren voor de ArgumentOutOfRangeException bewerking die wordt gegenereerd wanneer een pictogramobject PNG-frames heeft. Wanneer de conversie onder .NET Framework 4.6 wordt uitgevoerd, wordt de conversie voltooid, wordt er ArgumentOutOfRangeException geen fout meer gegenereerd en wordt de uitzonderingshandler daarom niet meer aangeroepen.

Suggestie

Als dit gedrag ongewenst is, kunt u het vorige gedrag behouden door het volgende element toe te voegen aan de <runtime> sectie van uw app.config-bestand:

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

Als het bestand app.config het AppContextSwitchOverrides element al bevat, moet de nieuwe waarde als volgt worden samengevoegd met het waardekenmerk:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

Windows Presentation Foundation (WPF)

CurrentCulture blijft niet behouden in WPF Dispatcher-bewerkingen

DETAILS

Vanaf .NET Framework 4.6 gaan wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture aangebracht in een System.Windows.Threading.Dispatcher bewerking verloren aan het einde van die dispatcherbewerking. Op dezelfde manier worden wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture gemaakt buiten een dispatcherbewerking mogelijk niet weergegeven wanneer deze bewerking wordt uitgevoerd. Praktisch gesproken betekent dit dat System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture wijzigingen mogelijk niet stromen tussen callbacks van WPF UI en andere code in een WPF-toepassing. Dit wordt veroorzaakt door een wijziging in System.Threading.ExecutionContext die oorzaken System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture wordt opgeslagen in de uitvoeringscontext, te beginnen met apps die gericht zijn op .NET Framework 4.6. WPF-dispatcherbewerkingen slaan de uitvoeringscontext op die wordt gebruikt om de bewerking te starten en de vorige context te herstellen wanneer de bewerking is voltooid. Omdat System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture nu deel uitmaken van die context, worden wijzigingen in deze context niet behouden binnen een dispatcherbewerking buiten de bewerking.

Suggestie

Apps die door deze wijziging worden beïnvloed, kunnen er omheen werken door het gewenste System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture in een veld op te slaan en alle dispatcher-bewerkingsteksten (inclusief callback-handlers voor ui-gebeurtenissen) in te checken die de juiste System.Globalization.CultureInfo.CurrentCulture zijn en System.Globalization.CultureInfo.CurrentUICulture zijn ingesteld. Als alternatief, omdat de ExecutionContext-wijziging die onder deze WPF-wijziging valt, alleen van invloed is op apps die gericht zijn op .NET Framework 4.6 of hoger, kan deze onderbreking worden vermeden door de .NET Framework 4.5.2.Apps die gericht zijn op .NET Framework 4.6 of hoger, te omzeilen door de volgende compatibiliteitsswitch in te stellen:

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

Dit probleem is opgelost door WPF in .NET Framework 4.6.2. Het is ook opgelost in .NET Frameworks 4.6, 4.6.1 tot en met KB 3139549. Toepassingen die gericht zijn op .NET Framework 4.6 of hoger, krijgen automatisch het juiste gedrag in WPF-toepassingen - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) blijven behouden voor dispatcherbewerkingen.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

WPF-lay-out afronding van marges is gewijzigd

DETAILS

De manier waarop marges worden afgerond en randen en de achtergrond in de marges zijn gewijzigd. Als gevolg van deze wijziging:

  • De breedte of hoogte van elementen kan met maximaal één pixel worden vergroot of verkleind.
  • De plaatsing van een object kan met maximaal één pixel worden verplaatst.
  • Gecentreerde elementen kunnen maximaal één pixel verticaal of horizontaal van het midden zijn. Deze nieuwe indeling is standaard alleen ingeschakeld voor apps die gericht zijn op .NET Framework 4.6.

Suggestie

Aangezien deze wijziging de neiging heeft om het knippen van de rechter- of onderkant van WPF-besturingselementen bij hoge DPO's te elimineren, kunnen apps die gericht zijn op eerdere versies van .NET Framework, maar worden uitgevoerd op .NET Framework 4.6, kiezen voor dit nieuwe gedrag door de volgende regel toe te voegen aan de <runtime> sectie van het bestand app.config:

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

Apps die gericht zijn op .NET Framework 4.6, maar WPF-besturingselementen willen weergeven met behulp van het vorige indelingsalgoritmen, kunnen dit doen door de volgende regel toe te voegen aan de <runtime> sectie van het bestand app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

XML, XSLT

XmlWriter genereert ongeldige surrogaatparen

DETAILS

Voor apps die gericht zijn op .NET Framework 4.5.2 of eerdere versies, genereert het schrijven van een ongeldig surrogaatpaar met uitzonderingsterugvalafhandeling niet altijd een uitzondering. Voor apps die gericht zijn op .NET Framework 4.6, wordt een ongeldig surrogaatpaar gegooid System.ArgumentException.

Suggestie

Indien nodig kan deze onderbreking worden vermeden door het .NET Framework 4.5.2 of eerder te richten. U kunt ook ongeldige surrogaatparen vooraf verwerken in geldige XML voordat ze worden geschreven.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Betrokken API's

Validatie van XSD-schema detecteert nu correct schendingen van unieke beperkingen als samengestelde sleutels worden gebruikt en één sleutel leeg is

DETAILS

Versies van .NET Framework vóór 4.6 hadden een fout waardoor XSD-validatie geen unieke beperkingen voor samengestelde sleutels detecteerde als een van de sleutels leeg was. In .NET Framework 4.6 wordt dit probleem opgelost. Dit resulteert in een correctere validatie, maar dit kan er ook toe leiden dat bepaalde XML-bewerkingen niet worden gevalideerd.

Suggestie

Als er meer .NET Framework 4.0-validatie nodig is, kan de validerende toepassing gebruikmaken van versie 4.5 (of eerder) van .NET Framework. Bij het opnieuw kopiëren naar .NET Framework 4.6 moet codebeoordeling echter worden uitgevoerd om ervoor te zorgen dat dubbele samengestelde sleutels (zoals beschreven in de beschrijving van dit probleem) niet worden gevalideerd.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

.NET Framework 4.6.1

Basis

Wijzigen in padscheidingsteken in de eigenschap FullName van ZipArchiveEntry-objecten

DETAILS

Voor apps die zijn gericht op .NET Framework 4.6.1 en nieuwere versies, is het padscheidingsteken gewijzigd van een backslash ("\") in een slash (/) in de FullName eigenschap van ZipArchiveEntry objecten die zijn gemaakt door overbelasting van de CreateFromDirectory methode. De wijziging brengt de .NET-implementatie in overeenstemming met sectie 4.4.17.1 van de specificatie van de .ZIP bestandsindeling en stelt .ZIP archieven in staat om te worden gedecomprimeerd op niet-Windows-systemen.
Het decomprimeren van een zip-bestand dat is gemaakt door een app die is gericht op een eerdere versie van .NET Framework op niet-Windows-besturingssystemen, zoals de Macintosh, kan de mapstructuur niet behouden. Op de Macintosh wordt bijvoorbeeld een set bestanden gemaakt waarvan de bestandsnaam het pad naar de map samenvoegt, samen met eventuele backslashtekens (\) en de bestandsnaam. Hierdoor blijft de mapstructuur van gedecomprimeerde bestanden niet behouden.

Suggestie

De impact van deze wijziging op .ZIP bestanden die zijn gedecomprimeerd op het Windows-besturingssysteem door API's in de .NET Framework-naamruimte System.IO , moet minimaal zijn, omdat deze API's naadloos een slash ("/") of een backslash ("\") kunnen verwerken als het padscheidingsteken.
Als deze wijziging ongewenst is, kunt u zich afmelden door een configuratie-instelling toe te voegen aan de <runtime> sectie van uw toepassingsconfiguratiebestand. In het volgende voorbeeld ziet u zowel de <runtime> sectie als de Switch.System.IO.Compression.ZipFile.UseBackslash schakeloptie voor afmelden:

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

Bovendien kunnen apps die gericht zijn op eerdere versies van .NET Framework, maar worden uitgevoerd op .NET Framework 4.6.1 en latere versies, zich aanmelden voor dit gedrag door een configuratie-instelling toe te voegen aan de <runtime> sectie van het toepassingsconfiguratiebestand. Hieronder ziet u zowel de <runtime> sectie als de Switch.System.IO.Compression.ZipFile.UseBackslash opt-in-switch.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Naam Weergegeven als
Bereik Edge
Versie 4.6.1
Type Opnieuw targeting

Betrokken API's

Windows Communication Foundation (WCF)

WCF-binding met de beveiligingsmodus TransportWithMessageCredential

DETAILS

Vanaf .NET Framework 4.6.1 kan de WCF-binding die gebruikmaakt van de beveiligingsmodus TransportWithMessageCredential worden ingesteld voor het ontvangen van berichten met niet-ondertekende headers 'aan' voor asymmetrische beveiligingssleutels. Standaard worden niet-ondertekende headers 'aan' nog steeds geweigerd in .NET Framework 4.6.1. Ze worden alleen geaccepteerd als een toepassing zich aanmeldt voor deze nieuwe bewerkingsmodus met behulp van de switch Switch.System.ServiceModel.AllowUnsignedToHeader-configuratieswitch.

Suggestie

Omdat dit een opt-in-functie is, moet dit geen invloed hebben op het gedrag van bestaande apps.
Als u wilt bepalen of het nieuwe gedrag wordt gebruikt of niet, gebruikt u de volgende configuratie-instelling:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Naam Weergegeven als
Bereik Transparant
Versie 4.6.1
Type Opnieuw targeting

Betrokken API's

X509CertificateClaimSet.FindClaims houdt rekening met alle claimtypen

DETAILS

In apps die gericht zijn op .NET Framework 4.6.1, als een X509-claimset wordt geïnitialiseerd vanuit een certificaat met meerdere DNS-vermeldingen in het SAN-veld, probeert de System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) methode het argument claimType te koppelen aan alle DNS-vermeldingen. Voor apps die gericht zijn op eerdere versies van .NET Framework, probeert de System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) methode alleen het argument claimType te vinden met de laatste DNS-vermelding.

Suggestie

Deze wijziging is alleen van invloed op toepassingen die zijn gericht op .NET Framework 4.6.1. Deze wijziging kan worden uitgeschakeld (of ingeschakeld als u zich richt op pre-4.6.1) met de compatibiliteitsswitch DisableMultipleDNSEntries .

Naam Weergegeven als
Bereik Secundair
Versie 4.6.1
Type Opnieuw targeting

Betrokken API's

Windows Forms

Application.FilterMessage genereert niet langer voor nieuwe implementaties van IMessageFilter.PreFilterMessage

DETAILS

Voordat .NET Framework 4.6.1 wordt aangeroepen FilterMessage(Message) PreFilterMessage(Message) System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) of (terwijl ook aanroepenDoEvents()) een .System.IndexOutOfRangeException

Vanaf toepassingen die gericht zijn op .NET Framework 4.6.1, wordt deze uitzondering niet meer gegenereerd en kunnen filters die hierboven worden beschreven, opnieuw worden gebruikt.

Suggestie

Houd er rekening mee dat het gedrag van FilterMessage(Message) nieuwe deelnemers PreFilterMessage(Message) dat hierboven wordt beschreven, niet meer zal gooien. Dit is alleen van invloed op toepassingen die zijn gericht op .NET Framework 4.6.1.Apps die gericht zijn op .NET Framework 4.6.1, kunnen zich afmelden voor deze wijziging (of apps die zijn gericht op oudere frameworks kunnen zich aanmelden) met behulp van de compatibiliteitsswitch DontSupportReentrantFilterMessage .

Naam Weergegeven als
Bereik Edge
Versie 4.6.1
Type Opnieuw targeting

Betrokken API's

Windows Presentation Foundation (WPF)

Aanroepen naar System.Windows.Input.PenContext.Disable on touch-enabled systems may throw an ArgumentException

DETAILS

In sommige gevallen kunnen aanroepen naar de interne methode System.Windows.Intput.PenContext.Disable op systemen met aanraakbediening een onhandig T:System.ArgumentException gevolg zijn van reentrancy.

Suggestie

Dit probleem is opgelost in .NET Framework 4.7. Als u de uitzondering wilt voorkomen, voert u een upgrade uit naar een versie van .NET Framework die begint met .NET Framework 4.7.

Naam Weergegeven als
Bereik Edge
Versie 4.6.1
Type Opnieuw targeting

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath genereert een NullReferenceException

DETAILS

In .NET Framework 4.6.2 genereert de runtime een T:System.NullReferenceException waarde die null-tekens bevat. P:System.Web.HttpRuntime.AppDomainAppPath In .NET Framework 4.6.1 en eerdere versies genereert de runtime een T:System.ArgumentNullException.

Suggestie

U kunt een van de volgende handelingen uitvoeren om te reageren op deze wijziging:

  • Afhandelen of T:System.NullReferenceException de toepassing wordt uitgevoerd op .NET Framework 4.6.2.
  • Voer een upgrade uit naar .NET Framework 4.7, waarmee het vorige gedrag wordt hersteld en een T:System.ArgumentNullException.
Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Basis

Decryptor AesCryptoServiceProvider biedt een herbruikbare transformatie

DETAILS

Vanaf apps die gericht zijn op .NET Framework 4.6.2, biedt de AesCryptoServiceProvider ontsleuteling een herbruikbare transformatie. Na een aanroep naar System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), wordt de transformatie opnieuw geïnitialiseerd en kan deze opnieuw worden gebruikt. Voor apps die gericht zijn op eerdere versies van .NET Framework, probeert u de ontsleuteling opnieuw te gebruiken door aan te roepen System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) na een aanroep om een CryptographicException of meer beschadigde gegevens te System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) veroorzaken.

Suggestie

De impact van deze wijziging moet minimaal zijn, omdat dit het verwachte gedrag is. Toepassingen die afhankelijk zijn van het vorige gedrag kunnen zich afmelden voor het gebruik ervan door de volgende configuratie-instelling toe te voegen aan de <runtime> sectie van het configuratiebestand van de toepassing:

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

Bovendien kunnen toepassingen die gericht zijn op een eerdere versie van .NET Framework, maar worden uitgevoerd onder een versie van .NET Framework die begint met .NET Framework 4.6.2, zich hiervoor aanmelden door de volgende configuratie-instelling toe te voegen aan de sectie van het <runtime> configuratiebestand van de toepassing:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Naam Weergegeven als
Bereik Secundair
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Aanroepen naar ClaimsIdentity-constructors

DETAILS

Vanaf .NET Framework 4.6.2 is er een wijziging in de wijze waarop ClaimsIdentity constructors met een System.Security.Principal.IIdentity parameter de System.Security.Claims.ClaimsIdentity.Actor eigenschap instellen. Als het System.Security.Principal.IIdentity argument een ClaimsIdentity object is en de System.Security.Claims.ClaimsIdentity.Actor eigenschap van dat ClaimsIdentity object niet nullis, wordt de System.Security.Claims.ClaimsIdentity.Actor eigenschap gekoppeld met behulp van de Clone() methode. In framework 4.6.1 en eerdere versies wordt de System.Security.Claims.ClaimsIdentity.Actor eigenschap als een bestaande verwijzing gekoppeld. Vanwege deze wijziging, vanaf .NET Framework 4.6.2, is de System.Security.Claims.ClaimsIdentity.Actor eigenschap van het nieuwe ClaimsIdentity object niet gelijk aan de eigenschap van het System.Security.Claims.ClaimsIdentity.Actor argument van de constructor System.Security.Principal.IIdentity . In .NET Framework 4.6.1 en eerdere versies is deze gelijk.

Suggestie

Als dit gedrag ongewenst is, kunt u het vorige gedrag herstellen door de Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity schakeloptie in uw toepassingsconfiguratiebestand in te stellen op true. Hiervoor moet u het volgende toevoegen aan de <runtime> sectie van uw web.config-bestand:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Wijzigingen in padnormalisatie

DETAILS

Vanaf apps die gericht zijn op .NET Framework 4.6.2, is de manier waarop de runtime paden normaliseert, gewijzigd. Het normaliseren van een pad omvat het wijzigen van de tekenreeks waarmee een pad of bestand wordt geïdentificeerd, zodat het overeenkomt met een geldig pad op het doelbesturingssysteem. Normalisatie omvat doorgaans:

  • Onderdeel- en mapscheidingstekens canoniseren.
  • De huidige map toepassen op een relatief pad.
  • Evalueer de relatieve map (.) of de bovenliggende map (..) in een pad.
  • Opgegeven tekens bijsnijden. Vanaf apps die gericht zijn op .NET Framework 4.6.2, zijn de volgende wijzigingen in padnormalisatie standaard ingeschakeld:
  • Normalisatie omvat niet langer het bijsnijden van het einde van mapsegmenten (zoals een spatie aan het einde van een mapnaam).
  • Ondersteuning voor syntaxis van apparaatpaden in volledig vertrouwen, inclusief \\.\ en voor I/O-API's van bestanden in mscorlib.dll, \\?\.
  • De runtime valideert geen paden voor apparaatsyntaxis.
  • Het gebruik van apparaatsyntaxis voor toegang tot alternatieve gegevensstromen wordt ondersteund. Deze wijzigingen verbeteren de prestaties terwijl methoden toegang hebben tot eerder ontoegankelijke paden. Apps die gericht zijn op .NET Framework 4.6.1 en eerdere versies, maar worden uitgevoerd onder .NET Framework 4.6.2 of hoger, worden niet beïnvloed door deze wijziging.

Suggestie

Apps die zijn gericht op .NET Framework 4.6.2 of hoger, kunnen zich afmelden voor deze wijziging en verouderde normalisatie gebruiken door het volgende toe te voegen aan de <runtime> sectie van het toepassingsconfiguratiebestand:

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

Apps die zijn gericht op .NET Framework 4.6.1 of eerder, maar die worden uitgevoerd op .NET Framework 4.6.2 of hoger, kunnen de wijzigingen in padnormalisatie inschakelen door de volgende regel toe te voegen aan de <runtime> sectie van het .configuration-bestand van de toepassing:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Naam Weergegeven als
Bereik Secundair
Versie 4.6.2
Type Opnieuw targeting

CurrentCulture- en CurrentUICulture-stroom tussen taken

DETAILS

Beginnend in .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture worden opgeslagen in de threads System.Threading.ExecutionContext, die stromen over asynchrone bewerkingen. Dit betekent dat wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture worden doorgevoerd in taken die later asynchroon worden uitgevoerd. Dit verschilt van het gedrag van eerdere .NET Framework-versies (die opnieuw zouden worden ingesteld System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture in alle asynchrone taken).

Suggestie

Apps die door deze wijziging worden beïnvloed, kunnen er omheen werken door expliciet de gewenste System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture als eerste bewerking in een asynchrone taak in te stellen. U kunt ook het oude gedrag (van niet stromen System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) kiezen door de volgende compatibiliteitsswitch in te stellen:

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

Dit probleem is opgelost door WPF in .NET Framework 4.6.2. Het is ook opgelost in .NET Frameworks 4.6, 4.6.1 tot en met KB 3139549. Toepassingen die gericht zijn op .NET Framework 4.6 of hoger, krijgen automatisch het juiste gedrag in WPF-toepassingen - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) blijven behouden voor dispatcherbewerkingen.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting

Betrokken API's

ETW-gebeurtenisnamen kunnen niet alleen verschillen met een achtervoegsel 'Starten' of 'Stoppen'.

DETAILS

In .NET Framework 4.6 en 4.6.1 genereert de runtime een ArgumentException wanneer twee ETW-gebeurtenisnamen (Event Tracing for Windows) alleen verschillen met een achtervoegsel 'Starten' of 'Stoppen' (zoals wanneer een gebeurtenis een naam LogUser heeft en een andere naam LogUserStartheeft). In dit geval kan de runtime de gebeurtenisbron niet samenstellen, waardoor er geen logboekregistratie kan worden verzonden.

Suggestie

Om de uitzondering te voorkomen, moet u ervoor zorgen dat er slechts twee gebeurtenisnamen verschillen met het achtervoegsel 'Starten' of 'Stoppen'. Deze vereiste wordt verwijderd vanaf .NET Framework 4.6.2; de runtime kan namen van gebeurtenissen die alleen verschillen door het achtervoegsel 'Start' en 'Stop'.

Naam Weergegeven als
Bereik Edge
Versie 4.6
Type Opnieuw targeting

Ondersteuning voor lang pad

DETAILS

Vanaf apps die gericht zijn op .NET Framework 4.6.2, worden lange paden (van maximaal 32.000 tekens) ondersteund en is de beperking van 260 tekens (of MAX_PATH) voor padlengten verwijderd. Voor apps die opnieuw zijn gecompileerd om te worden gericht op .NET Framework 4.6.2, genereren codepaden die eerder een System.IO.PathTooLongException pad veroorzaakten omdat een pad langer is dan 260 tekens, nu alleen onder de volgende voorwaarden een System.IO.PathTooLongException resultaat krijgen:

  • De lengte van het pad is groter dan MaxValue (32.767) tekens.
  • Het besturingssysteem retourneert COR_E_PATHTOOLONG of het equivalent ervan. Voor apps die gericht zijn op .NET Framework 4.6.1 en eerdere versies, genereert de runtime automatisch een System.IO.PathTooLongException pad dat groter is dan 260 tekens.

Suggestie

Voor apps die zijn gericht op .NET Framework 4.6.2, kunt u zich afmelden voor ondersteuning voor lange paden als dit niet wenselijk is door het volgende toe te voegen aan de <runtime> sectie van uw app.config bestand:

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

Voor apps die gericht zijn op eerdere versies van .NET Framework, maar worden uitgevoerd op .NET Framework 4.6.2 of hoger, kunt u zich aanmelden voor ondersteuning voor lange paden door het volgende toe te voegen aan de <runtime> sectie van uw app.config bestand:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Naam Weergegeven als
Bereik Secundair
Versie 4.6.2
Type Opnieuw targeting

Padkommacontroles zijn strenger

DETAILS

In .NET Framework 4.6.2 zijn een aantal wijzigingen aangebracht ter ondersteuning van eerder niet-ondersteunde paden (zowel in lengte als indeling). Controles op de juiste stationsscheidingstekens (dubbele punt) zijn nauwkeuriger gemaakt, waardoor het neveneffect van het blokkeren van sommige URI-paden in een paar geselecteerde Pad-API's waar ze eerder werden getolereerd.

Suggestie

Als u een URI doorgeeft aan betrokken API's, wijzigt u eerst de tekenreeks als een juridisch pad.

  • Verwijder het schema handmatig uit URL's (bijvoorbeeld verwijderen file:// uit URL's).

  • Geef de URI door aan de Uri klasse en gebruik LocalPath.

U kunt zich ook afmelden voor de nieuwe padnormalisatie door de Switch.System.IO.UseLegacyPathHandling AppContext-switch in te stellen op true.

Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Beveiliging

RSACng laadt nu RSA-sleutels van niet-standaardsleutelgrootte correct

DETAILS

In .NET Framework-versies vóór 4.6.2 hebben klanten met niet-standaardsleutelgrootten voor RSA-certificaten geen toegang tot deze sleutels via de System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) en System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) extensiemethoden. Een System.Security.Cryptography.CryptographicException met het bericht 'De aangevraagde sleutelgrootte wordt niet ondersteund' wordt gegenereerd. In .NET Framework 4.6.2 is dit probleem opgelost. ImportParameters(RSAParameters) ImportParameters(RSAParameters) En nu werken met niet-standaardsleutelgrootten zonder een System.Security.Cryptography.CryptographicException.

Suggestie

Als er uitzonderingsafhandelingslogica is die afhankelijk is van het vorige gedrag waarbij een System.Security.Cryptography.CryptographicException wordt gegenereerd wanneer niet-standaardsleutelgrootten worden gebruikt, kunt u overwegen de logica te verwijderen.

Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

SignedXml.GetPublicKey retourneert RSACng op net462 (of lightup) zonder wijzigingen opnieuw te wijzigen

DETAILS

Vanaf .NET Framework 4.6.2 is het concrete type van het object dat wordt geretourneerd door de SignedXml.GetPublicKey methode gewijzigd (zonder een quirk) van een CryptoServiceProvider-implementatie naar een Cng-implementatie. Dit komt doordat de implementatie is gewijzigd van het gebruik certificate.PublicKey.Key van het gebruik van de interne certificate.GetAnyPublicKey die wordt doorgestuurd naar RSACertificateExtensions.GetRSAPublicKey.

Suggestie

Vanaf apps die worden uitgevoerd op .NET Framework 4.7.1, kunt u de CryptoServiceProvider-implementatie die standaard wordt gebruikt in .NET Framework 4.6.1 en eerdere versies gebruiken door de volgende configuratieswitch toe te voegen aan de runtimesectie van uw app-configuratiebestand:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Windows Communication Foundation (WCF)

Impasse kan optreden bij het gebruik van reentrant-services

DETAILS

Een impasse kan resulteren in een reentrant-service, waardoor exemplaren van de service worden beperkt tot één thread van uitvoering tegelijk. Services die gevoelig zijn voor dit probleem, hebben het volgende ServiceBehaviorAttribute in hun code:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Suggestie

U kunt dit probleem als volgt oplossen:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Installeer de meest recente update naar .NET Framework 4.6.2 of voer een upgrade uit naar een latere versie van .NET Framework. Hierdoor wordt de stroom van de ExecutionContext instroom uitgeschakeld OperationContext.Current. Dit gedrag kan worden geconfigureerd; het is gelijk aan het toevoegen van de volgende app-instelling aan uw configuratiebestand:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

De waarde van Switch.System.ServiceModel.DisableOperationContextAsyncFlow mag nooit worden ingesteld false op reentrant-services.

Naam Weergegeven als
Bereik Secundair
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

OperationContext.Current kan null retourneren wanneer deze wordt aangeroepen in een using-component

DETAILS

OperationContext.Currentnull retourneert en kan een NullReferenceException resultaat opleveren als aan alle volgende voorwaarden wordt voldaan:

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

    // ...
}

Suggestie

U kunt dit probleem als volgt oplossen:

  • Wijzig uw code als volgt om een nieuw niet-object null Current te instantiëren:

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

    // ...
}

  • Installeer de meest recente update naar .NET Framework 4.6.2 of voer een upgrade uit naar een latere versie van .NET Framework. Hiermee schakelt u de stroom van het ExecutionContext in OperationContext.Current en herstelt u het gedrag van WCF-toepassingen in .NET Framework 4.6.1 en eerdere versies. Dit gedrag kan worden geconfigureerd; het is gelijk aan het toevoegen van de volgende app-instelling aan uw configuratiebestand:

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

    Als deze wijziging ongewenst is en uw toepassing afhankelijk is van de uitvoeringscontext tussen bewerkingscontexten, kunt u de stroom als volgt inschakelen:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

WCF-transportbeveiliging ondersteunt certificaten die zijn opgeslagen met CNG

DETAILS

Vanaf apps die gericht zijn op .NET Framework 4.6.2, ondersteunt WCF-transportbeveiliging certificaten die zijn opgeslagen met behulp van de Windows Cryptography Library (CNG). Deze ondersteuning is beperkt tot certificaten met een openbare sleutel met een exponent van maximaal 32 bits. Wanneer een toepassing is gericht op .NET Framework 4.6.2, is deze functie standaard ingeschakeld. In eerdere versies van .NET Framework genereert de poging X509-certificaten te gebruiken met een CSG-sleutelopslagprovider een uitzondering.

Suggestie

Apps die zijn gericht op .NET Framework 4.6.1 en eerder, maar die worden uitgevoerd op .NET Framework 4.6.2, kunnen ondersteuning voor CNG-certificaten inschakelen door de volgende regel toe te voegen aan de <runtime> sectie van het bestand app.config of web.config:

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

Dit kan ook programmatisch worden gedaan met de volgende code:

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

AppContext.SetSwitch(disableCngCertificates, false);

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

Houd er rekening mee dat vanwege deze wijziging alle uitzonderingsafhandelingscode die afhankelijk is van de poging om beveiligde communicatie met een CNG-certificaat te starten, niet meer wordt uitgevoerd.

Naam Weergegeven als
Bereik Secundair
Versie 4.6.2
Type Opnieuw targeting

Windows Forms

Onjuiste implementatie van MemberDescriptor.Equals

DETAILS

De oorspronkelijke implementatie van de MemberDescriptor.Equals methode vergelijkt twee verschillende tekenreekseigenschappen van de objecten die worden vergeleken: de categorienaam en de beschrijvingstekenreeks. De oplossing is het vergelijken van het Category eerste object met de Category tweede en de Description eerste met de Description tweede.

Suggestie

Als uw toepassing soms wordt MemberDescriptor.Equals geretourneerd false wanneer descriptors gelijkwaardig zijn en u zich richt op .NET Framework 4.6.2 of hoger, hebt u verschillende opties:

  • Breng codewijzigingen aan om de Category en Description velden handmatig te vergelijken, naast het aanroepen van de MemberDescriptor.Equals methode.
  • Meld u af voor deze wijziging door de volgende waarde toe te voegen aan het bestand app.config:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Als uw toepassing is gericht op .NET Framework 4.6.1 of eerder en wordt uitgevoerd op .NET Framework 4.6.2 of hoger en u deze wijziging wilt inschakelen, kunt u de compatibiliteitsswitch false instellen door de volgende waarde toe te voegen aan het bestand app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Naam Weergegeven als
Bereik Edge
Versie 4.6.2
Type Opnieuw targeting

Betrokken API's

Windows Presentation Foundation (WPF)

CurrentCulture blijft niet behouden in WPF Dispatcher-bewerkingen

DETAILS

Vanaf .NET Framework 4.6 gaan wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture aangebracht in een System.Windows.Threading.Dispatcher bewerking verloren aan het einde van die dispatcherbewerking. Op dezelfde manier worden wijzigingen in System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture gemaakt buiten een dispatcherbewerking mogelijk niet weergegeven wanneer deze bewerking wordt uitgevoerd. Praktisch gesproken betekent dit dat System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture wijzigingen mogelijk niet stromen tussen callbacks van WPF UI en andere code in een WPF-toepassing. Dit wordt veroorzaakt door een wijziging in System.Threading.ExecutionContext die oorzaken System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture wordt opgeslagen in de uitvoeringscontext, te beginnen met apps die gericht zijn op .NET Framework 4.6. WPF-dispatcherbewerkingen slaan de uitvoeringscontext op die wordt gebruikt om de bewerking te starten en de vorige context te herstellen wanneer de bewerking is voltooid. Omdat System.Globalization.CultureInfo.CurrentCulture en System.Globalization.CultureInfo.CurrentUICulture nu deel uitmaken van die context, worden wijzigingen in deze context niet behouden binnen een dispatcherbewerking buiten de bewerking.

Suggestie

Apps die door deze wijziging worden beïnvloed, kunnen er omheen werken door het gewenste System.Globalization.CultureInfo.CurrentCulture of System.Globalization.CultureInfo.CurrentUICulture in een veld op te slaan en alle dispatcher-bewerkingsteksten (inclusief callback-handlers voor ui-gebeurtenissen) in te checken die de juiste System.Globalization.CultureInfo.CurrentCulture zijn en System.Globalization.CultureInfo.CurrentUICulture zijn ingesteld. Als alternatief, omdat de ExecutionContext-wijziging die onder deze WPF-wijziging valt, alleen van invloed is op apps die gericht zijn op .NET Framework 4.6 of hoger, kan deze onderbreking worden vermeden door de .NET Framework 4.5.2.Apps die gericht zijn op .NET Framework 4.6 of hoger, te omzeilen door de volgende compatibiliteitsswitch in te stellen:

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

Dit probleem is opgelost door WPF in .NET Framework 4.6.2. Het is ook opgelost in .NET Frameworks 4.6, 4.6.1 tot en met KB 3139549. Toepassingen die gericht zijn op .NET Framework 4.6 of hoger, krijgen automatisch het juiste gedrag in WPF-toepassingen - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) blijven behouden voor dispatcherbewerkingen.

Naam Weergegeven als
Bereik Secundair
Versie 4.6
Type Opnieuw targeting