Ommåla ändringar för migrering till .NET Framework 4.7.x
I den här artikeln visas de problem med appkompatibilitet som introducerades i .NET Framework 4.7, 4.7.1 och 4.7.2.
.NET Framework 4.7
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
Begränsa samtidiga begäranden per session
Details
I .NET Framework 4.6.2 och tidigare kör ASP.NET begäranden med samma Sessionid sekventiellt och ASP.NET alltid utfärdar Sessionid via cookies som standard. Om en sida tar lång tid att svara försämras serverns prestanda avsevärt bara genom att trycka på F5 i webbläsaren. I korrigeringen lade vi till en räknare för att spåra köade begäranden och avsluta begäranden när de överskrider en angiven gräns. Standardvärdet är 50. Om gränsen nås loggas en varning i händelseloggen och ett HTTP 500-svar kan registreras i IIS-loggen.
Förslag
Om du vill återställa det gamla beteendet kan du lägga till följande inställning i web.config-filen för att välja bort det nya beteendet.
<appSettings>
<add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Nätverk
Standardvärdet för ServicePointManager.SecurityProtocol är SecurityProtocolType.System.Default
Details
Från och med appar som riktar sig mot .NET Framework 4.7 är SecurityProtocolType.SystemDefaultstandardvärdet för ServicePointManager.SecurityProtocol egenskapen . Med den här ändringen kan .NET Framework-nätverks-API:er baserade på SslStream (till exempel FTP, HTTPS och SMTP) ärva standardsäkerhetsprotokollen från operativsystemet i stället för att använda hårdkodade värden som definierats av .NET Framework. Standardinställningen varierar beroende på operativsystem och alla anpassade konfigurationer som utförs av systemadministratören. Information om standardprotokollet SChannel i varje version av Windows-operativsystemet finns i Protokoll i TLS/SSL (Schannel SSP).
För program som riktar sig mot en tidigare version av .NET Framework beror standardvärdet ServicePointManager.SecurityProtocol för egenskapen på den version av .NET Framework som är mål. Mer information finns i avsnittet Nätverk i Ommåla ändringar för migrering från .NET Framework 4.5.2 till 4.6 .Förslag
Den här ändringen påverkar program som riktar sig till .NET Framework 4.7 eller senare versioner. Om du föredrar att använda ett definierat protokoll i stället för att förlita dig på systemstandarden kan du uttryckligen ange värdet för ServicePointManager.SecurityProtocol egenskapen. Om den här ändringen inte är önskvärd kan du välja bort den genom att lägga till en konfigurationsinställning i körningsavsnittet <> i programkonfigurationsfilen. I följande exempel visas både <runtime>
avsnittet och avaktiveringsväxeln Switch.System.Net.DontEnableSystemDefaultTlsVersions
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
SslStream stöder TLS-aviseringar
Details
Efter ett misslyckat TLS-handslag genereras ett System.IO.IOException med ett inre System.ComponentModel.Win32Exception undantag av den första I/O-läs-/skrivåtgärden. Koden System.ComponentModel.Win32Exception.NativeErrorCode för System.ComponentModel.Win32Exception kan mappas till TLS-aviseringen från fjärrparten med hjälp av Schannel-felkoderna för TLS- och SSL-aviseringar. Mer information finns i RFC 2246: Avsnitt 7.2.2 Felaviseringar.
Beteendet i .NET Framework 4.6.2 och tidigare är att transportkanalen (vanligtvis TCP-anslutningen) överskrider tidsgränsen under antingen Skriv eller Läs om den andra parten misslyckades med handskakningen och omedelbart därefter avvisade anslutningen.
Förslag
Program som anropar nätverks-I/O-API:er som Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) ska hantera IOException eller .System.TimeoutException
Funktionen TLS-aviseringar är aktiverad som standard från och med .NET Framework 4.7. Program som riktar sig till versioner av .NET Framework från 4.0 till 4.6.2 som körs på ett .NET Framework 4.7- eller högre system har funktionen inaktiverad för att bevara kompatibiliteten.
Följande konfigurations-API är tillgängligt för att aktivera eller inaktivera funktionen för .NET Framework 4.6 och senare program som körs på .NET Framework 4.7 eller senare.
Programmatiskt: Måste vara det allra första programmet gör eftersom ServicePointManager endast initierar en gång:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
Appconfig:
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/> <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. --> </runtime>
Registernyckel (dator globalt): Ange värdet till
false
för att aktivera funktionen i .NET Framework 4.6 –4.6.2.Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts - Type: String - Value: "true"
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Säkerhet
CspParameters.ParentWindowHandle förväntar sig nu HWND-värde
Details
Värdet ParentWindowHandle , som introducerades i .NET Framework 2.0, gör att ett program kan registrera ett överordnat fönsterhandtagsvärde så att alla användargränssnitt som krävs för att komma åt nyckeln (till exempel en PIN-fråga eller en dialogruta för medgivande) öppnas som ett modalt underordnat underordnat till det angivna fönstret. Från och med appar som riktar sig mot .NET Framework 4.7 kan ett Windows Forms-program ange ParentWindowHandle egenskapen med kod som följande:
cspParameters.ParentWindowHandle = form.Handle;
I tidigare versioner av .NET Framework förväntades värdet vara en System.IntPtr plats i minnet där HWND-värdet fanns. Ange egenskapen som formulär. Handle på Windows 7 och tidigare versioner hade ingen effekt, men på Windows 8 och senare versioner resulterar det i "System.Security.Cryptography.CryptographicException: Parametern är felaktig."
Förslag
Program som riktar sig till .NET Framework 4.7 eller senare som vill registrera en överordnad fönsterrelation uppmanas att använda det förenklade formuläret:
cspParameters.ParentWindowHandle = form.Handle;
Användare som hade identifierat att rätt värde att skicka var adressen till en minnesplats som innehöll värdet form.Handle
kan välja bort beteendeändringen genom att ange AppContext-växeln Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle
till true
:
- Genom att programmatiskt ställa in kompatibilitetsväxlar på AppContext, som beskrivs här.
- Genom att lägga till följande rad i
<runtime>
avsnittet i filen app.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>
Däremot kan användare som vill välja det nya beteendet på .NET Framework 4.7-körningen när programmet läses in under äldre .NET Framework-versioner ställa in AppContext-växeln till false
.
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
SslStream stöder TLS-aviseringar
Details
Efter ett misslyckat TLS-handslag genereras ett System.IO.IOException med ett inre System.ComponentModel.Win32Exception undantag av den första I/O-läs-/skrivåtgärden. Koden System.ComponentModel.Win32Exception.NativeErrorCode för System.ComponentModel.Win32Exception kan mappas till TLS-aviseringen från fjärrparten med hjälp av Schannel-felkoderna för TLS- och SSL-aviseringar. Mer information finns i RFC 2246: Avsnitt 7.2.2 Felaviseringar.
Beteendet i .NET Framework 4.6.2 och tidigare är att transportkanalen (vanligtvis TCP-anslutningen) överskrider tidsgränsen under antingen Skriv eller Läs om den andra parten misslyckades med handskakningen och omedelbart därefter avvisade anslutningen.
Förslag
Program som anropar nätverks-I/O-API:er som Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) ska hantera IOException eller .System.TimeoutException
Funktionen TLS-aviseringar är aktiverad som standard från och med .NET Framework 4.7. Program som riktar sig till versioner av .NET Framework från 4.0 till 4.6.2 som körs på ett .NET Framework 4.7- eller högre system har funktionen inaktiverad för att bevara kompatibiliteten.
Följande konfigurations-API är tillgängligt för att aktivera eller inaktivera funktionen för .NET Framework 4.6 och senare program som körs på .NET Framework 4.7 eller senare.
Programmatiskt: Måste vara det allra första programmet gör eftersom ServicePointManager endast initierar en gång:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
Appconfig:
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/> <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. --> </runtime>
Registernyckel (dator globalt): Ange värdet till
false
för att aktivera funktionen i .NET Framework 4.6 –4.6.2.Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts - Type: String - Value: "true"
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Windows Communication Foundation (WCF)
Serialisering av kontrolltecken med DataContractJsonSerializer är nu kompatibel med ECMAScript V6 och V8
Details
I .NET Framework 4.6.2 och tidigare versioner System.Runtime.Serialization.Json.DataContractJsonSerializer serialiserar inte vissa specialkontrolltecken, till exempel \b, \f och \t, på ett sätt som var kompatibelt med ECMAScript V6- och V8-standarderna. Från och med .NET Framework 4.7 är serialiseringen av dessa kontrolltecken kompatibel med ECMAScript V6 och V8.
Förslag
För appar som riktar sig till .NET Framework 4.7 är den här funktionen aktiverad som standard. Om det här beteendet inte är önskvärt kan du välja bort den här funktionen genom att lägga till följande rad i <runtime>
avsnittet i filen app.config eller web.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
- DataContractJsonSerializer.WriteObject(Stream, Object)
- DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
- DataContractJsonSerializer.WriteObject(XmlWriter, Object)
WCF-meddelandesäkerhet kan nu använda TLS1.1 och TLS1.2
Details
Från och med .NET Framework 4.7 kan kunder konfigurera TLS1.1 eller TLS1.2 i WCF-meddelandesäkerhet utöver SSL3.0 och TLS1.0 via programkonfigurationsinställningar.
Förslag
I .NET Framework 4.7 är stöd för TLS1.1 och TLS1.2 i WCF-meddelandesäkerhet inaktiverat som standard. Du kan aktivera det genom att lägga till följande rad i <runtime>
avsnittet i filen app.config eller web.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
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 |
NullReferenceException i undantagshanteringskod från ImageSourceConverter.ConvertFrom
Details
Ett fel i undantagshanteringskoden för orsakade att ett felaktigt System.NullReferenceException fel utlöstes i stället för ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) det avsedda undantaget ( System.IO.DirectoryNotFoundException eller System.IO.FileNotFoundException). Den här ändringen korrigerar felet så att metoden nu genererar rätt undantag.
Som standard fortsätter alla program som riktar sig till .NET Framework 4.6.2 och tidigare att utlösas System.NullReferenceException för kompatibilitet. Utvecklare som riktar in sig på .NET Framework 4.7 och senare bör se rätt undantag.
Förslag
Utvecklare som vill återgå till att hämta System.NullReferenceException när de riktar in sig på .NET Framework 4.7 eller senare kan lägga till/sammanfoga följande i programmets App.config-fil:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Berörda API:er
WPF Grid-allokering av utrymme till stjärnkolumner
Details
Från och med .NET Framework 4.7 ersätter WPF algoritmen som Grid använder för att allokera utrymme till *-kolumner. Detta ändrar den faktiska bredden som tilldelats *-kolumner i ett antal fall:
- När en eller flera *-kolumner också har en minsta eller högsta bredd som åsidosätter den proportionella allokeringen för den kolumnen. (Den minsta bredden kan härledas från en explicit MinWidth-deklaration eller från ett implicit minimum som hämtas från kolumnens innehåll. Den maximala bredden kan bara definieras explicit från en MaxWidth-deklaration.)
- När en eller flera *-kolumner deklarerar en extremt stor *-vikt, större än 10^298.
- När *-vikterna är tillräckligt olika för att stöta på instabilitet med flyttal (spill, underflöde, förlust av precision).
- När layoutrundning är aktiverat och den effektiva visnings-DPI:et är tillräckligt hög. I de första två fallen kan bredden som skapas av den nya algoritmen skilja sig avsevärt från de som produceras av den gamla algoritmen. i det sista fallet är skillnaden högst en eller två bildpunkter.
Den nya algoritmen åtgärdar flera buggar som finns i den gamla algoritmen:
Total allokering till kolumner kan överskrida rutnätets bredd. Detta kan inträffa när du allokerar utrymme till en kolumn vars proportionella resurs är mindre än dess minsta storlek. Algoritmen allokerar den minsta storleken, vilket minskar det tillgängliga utrymmet för andra kolumner. Om det inte finns några *-kolumner kvar att allokera blir den totala allokeringen för stor.
Total allokering kan inte vara lika med rutnätets bredd. Det här är det dubbla problemet till #1, som uppstår när du allokerar till en kolumn vars proportionella resurs är större än dess maximala storlek, utan *-kolumner kvar för att ta upp slacket.
Två *-kolumner kan ta emot allokeringar som inte är proportionella mot deras *-vikter. Det här är en mildare version av #1/#2 som uppstår vid allokering till *-kolumnerna A, B och C (i den ordningen), där B:s proportionella resurs bryter mot dess minsta (eller högsta) begränsning. Som ovan ändrar detta det tillgängliga utrymmet för kolumn C, som får mindre (eller mer) proportionell allokering än A gjorde.
Kolumner med extremt stora vikter (> 10^298) behandlas alla som om de hade vikt 10^298. Proportionella skillnader mellan dem (och mellan kolumner med något mindre vikter) uppfylls inte.
Kolumner med oändliga vikter hanteras inte korrekt. (Du kan faktiskt inte ange en vikt till Infinity, men det här är en artificiell begränsning. Allokeringskoden försökte hantera den, men gjorde ett dåligt jobb.)
Flera mindre problem med att undvika spill, underflöde, förlust av precision och liknande problem med flyttal.
Justeringar för layoutrundning är felaktiga vid tillräckligt hög DPI. Den nya algoritmen ger resultat som uppfyller följande kriterier:
- Den faktiska bredden som tilldelats en *-kolumn är aldrig mindre än dess minsta bredd eller större än dess maximala bredd.
- Varje *-kolumn som inte har tilldelats sin minsta eller högsta bredd tilldelas en bredd som är proportionell mot dess *-vikt. För att vara exakt, om två kolumner deklareras med bredd x* respektive y* och om ingen av kolumnerna får sin minsta eller högsta bredd, är de faktiska bredderna v och w tilldelade till kolumnerna i samma proportion: v / w == x / y.
- Den totala bredden som allokeras till "proportionella" *-kolumner är lika med det tillgängliga utrymmet efter allokeringen till de begränsade kolumnerna (fasta, automatiska och *-kolumner som allokeras med minsta eller högsta bredd). Detta kan vara noll, till exempel om summan av minsta bredd överskrider rutnätets tillgängliga bredd.
- Alla dessa instruktioner ska tolkas med avseende på den "ideala" layouten. När layoutrundning är i kraft kan de faktiska bredderna skilja sig från de ideala bredderna med så mycket som en bildpunkt.
Kommentar
Allt som sägs om kolumner och bredder i den här artikeln gäller även för rader och höjder.
Förslag
Som standard ser appar som är målversioner av .NET Framework från och med .NET Framework 4.7 den nya algoritmen, medan appar som riktar sig mot .NET Framework 4.6.2 eller tidigare versioner ser den gamla algoritmen.
Om du vill åsidosätta standardinställningen använder du följande konfigurationsinställning:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
Värdet true
väljer den gamla algoritmen och false
väljer den nya algoritmen.
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7 |
Typ | Ommåla |
WPF Pekarbaserad pekstack
Details
Den här ändringen lägger till möjligheten att aktivera en valfri WM_POINTER baserad WPF touch/stylus stack. Utvecklare som inte uttryckligen aktiverar detta bör inte se någon ändring i WPF-touch/pennans beteende. Aktuella kända problem med valfri WM_POINTER baserad touch-/pennastack:
- Inget stöd för pennanteckning i realtid.
- Även om pennanteckning och StylusPlugins fortfarande fungerar bearbetas de i användargränssnittstråden, vilket kan leda till dåliga prestanda.
- Beteendeändringar på grund av ändringar i befordran från touch-/penna-händelser till mushändelser
- Manipulering kan bete sig annorlunda
- Dra/släpp visar inte lämplig feedback för pekindata
- Detta påverkar inte pennans indata
- Dra/släpp kan inte längre initieras vid touch-/penna-händelser
- Detta kan göra att programmet slutar svara tills musindata har identifierats.
- I stället bör utvecklare initiera dra och släppa från mushändelser.
Förslag
Utvecklare som vill aktivera den här stacken kan lägga till/sammanfoga följande i programmets App.config-fil:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>
Om du tar bort detta eller anger värdet till false inaktiveras den här valfria stacken. Observera att den här stacken endast är tillgänglig på Windows 10 Creators Update och senare.
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7 |
Typ | Ommåla |
Windows Workflow Foundation (WF)
Kontrollsummor för arbetsflöde har ändrats från MD5 till SHA1
Details
För att stödja felsökning med Visual Studio genererar arbetsflödeskörningen en kontrollsumma för en arbetsflödesinstans med hjälp av en hashalgoritm. I .NET Framework 4.6.2 och tidigare versioner använde hashning av arbetsflödeskontrollsummor MD5-algoritmen, vilket orsakade problem i FIPS-aktiverade system. Från och med .NET Framework 4.7 är algoritmen SHA1. Om koden har sparat dessa kontrollsummor är de inkompatibla.
Förslag
Om koden inte kan läsa in arbetsflödesinstanser på grund av ett kontrollsummafel kan du prova att ange växeln AppContext
"Switch.System.Activities.UseMD5ForWFDebugger" till true. I kod:
System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);
Eller i konfiguration:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7 |
Typ | Ommåla |
.NET Framework 4.7.1
ASP.NET
ASP.NET hjälpmedelsförbättringar i .NET Framework 4.7.1
Details
Från och med .NET Framework 4.7.1 har ASP.NET förbättrat hur ASP.NET Web Controls fungerar med hjälpmedelsteknik i Visual Studio för att bättre stödja ASP.NET kunder. Dessa inkluderar följande ändringar:
- Ändringar för att implementera hjälpmedelsmönster för användargränssnittet som saknas i kontroller, till exempel dialogrutan Lägg till fält i guiden Informationsvy eller dialogrutan Konfigurera ListView i ListView-guiden.
- Ändringar för att förbättra visningen i högkontrastläge, till exempel Redigeraren för datasidesfält.
- Ändringar för att förbättra tangentbordsnavigeringsfunktionerna för kontroller, till exempel dialogrutan Fält i guiden Redigera sidfält i DataPager-kontrollen, dialogrutan Konfigurera ObjectContext eller dialogrutan Konfigurera dataval i guiden Konfigurera datakälla.
Förslag
Så här väljer du in eller ut dessa ändringar För att Visual Studio Designer ska kunna dra nytta av dessa ändringar måste den köras på .NET Framework 4.7.1 eller senare. Webbprogrammet kan dra nytta av dessa ändringar på något av följande sätt:
- Installera Visual Studio 2017 15.3 eller senare, som stöder de nya hjälpmedelsfunktionerna med följande AppContext Switch som standard.
- Avregistrera dig från äldre hjälpmedelsbeteenden genom att lägga till
Switch.UseLegacyAccessibilityFeatures
AppContext-växeln<runtime>
i avsnittet i filen devenv.exe.config och ställa in den påfalse
, som i följande exempel visas.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false' -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
Program som är inriktade på .NET Framework 4.7.1 eller senare och vill bevara det äldre hjälpmedelsbeteendet kan välja att använda äldre hjälpmedelsfunktioner genom att uttryckligen ange den här AppContext-växeln till true
.
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Kärna
SerialPort-bakgrundstrådsund undantag
Details
Bakgrundstrådar som skapats med SerialPort strömmar avslutar inte längre processen när OS-undantag utlöses.
I program som riktar sig mot .NET Framework 4.7 och tidigare versioner avslutas en process när ett operativsystemundatag utlöses på en bakgrundstråd som skapats med en SerialPort dataström.
I program som riktar sig mot .NET Framework 4.7.1 eller en senare version väntar bakgrundstrådar på OS-händelser relaterade till den aktiva serieporten och kan krascha i vissa fall, till exempel plötslig borttagning av serieporten.
Förslag
För appar som riktar sig till .NET Framework 4.7.1 kan du välja bort undantagshanteringen 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.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>
För appar som riktar in sig på tidigare versioner av .NET Framework men körs på .NET Framework 4.7.1 eller senare kan du välja undantagshantering genom att lägga till <runtime>
följande i avsnittet i app.config
filen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
ServiceBase sprider inte OnStart-undantag
Details
I .NET Framework 4.7 och tidigare versioner sprids inte undantag som genereras vid tjänststart till anroparen av ServiceBase.Run.
Från och med program som riktar sig mot .NET Framework 4.7.1, sprids undantag till ServiceBase.Run för tjänster som inte kan startas.
Förslag
Vid tjänststart, om det finns ett undantag, sprids undantaget. Detta bör hjälpa dig att diagnostisera fall där tjänster inte kan startas.
Om det här beteendet är oönskat kan du välja bort det genom att lägga till följande AppContextSwitchOverrides
element i avsnittet i runtime
programkonfigurationsfilen:
<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />
Om programmet är avsett för en tidigare version än 4.7.1 men du vill ha det här beteendet lägger du till följande AppContextSwitchOverrides
element i avsnittet i runtime
programkonfigurationsfilen:
<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
Säkerhet
Standardalgoritmerna SignedXML och SignedXMS har ändrats till SHA256
Details
I .NET Framework 4.7 och tidigare är SignedXML och SignedCMS som standard SHA1 för vissa åtgärder. Från och med .NET Framework 4.7.1 är SHA256 aktiverat som standard för dessa åtgärder. Den här ändringen är nödvändig eftersom SHA1 inte längre anses vara säker.
Förslag
Det finns två nya kontextväxlingsvärden för att kontrollera om SHA1 (osäker) eller SHA256 används som standard:
- Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
- Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms För program som riktar sig mot .NET Framework 4.7.1 och senare versioner, om användningen av SHA256 är oönskad, kan du återställa standardvärdet till SHA1 genom att lägga till följande konfigurationsväxel i körningsavsnittet i appkonfigurationsfilen:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />
För program som är inriktade på .NET Framework 4.7 och tidigare versioner kan du välja den här ändringen genom att lägga till följande konfigurationsväxel i körningsavsnittet i appkonfigurationsfilen:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
- System.Security.Cryptography.Pkcs.CmsSigner
- System.Security.Cryptography.Xml.SignedXml
- System.Security.Cryptography.Xml.Reference
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)
Förbättrad tillgänglighet för vissa .NET SDK-verktyg
Details
I .NET Framework SDK 4.7.1 har verktygen SvcConfigEditor.exe och SvcTraceViewer.exe förbättrats genom att åtgärda olika tillgänglighetsproblem. De flesta av dessa var små problem som att ett namn inte definierades eller att vissa gränssnittsautomatiseringsmönster inte implementerades korrekt. Även om många användare inte skulle känna till dessa felaktiga värden, kommer kunder som använder hjälpmedelstekniker som skärmläsare att finna dessa SDK-verktyg mer tillgängliga. Visst, dessa korrigeringar ändrar vissa tidigare beteenden, till exempel tangentbord fokusordning. För att få alla hjälpmedelskorrigeringar i dessa verktyg kan du följa app.config-filen:
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.1 |
Typ | Ommåla |
Windows Forms
Hjälpmedelsförbättringar i Windows Forms-kontroller
Details
Windows Forms förbättrar hur det fungerar med hjälpmedelstekniker för att bättre stödja Windows Forms-kunder. Dessa inkluderar följande ändringar som börjar med .NET Framework 4.7.1:
- Ändringar för att förbättra visningen under högkontrastläge.
- Ändringar för att förbättra egenskapens webbläsarupplevelse. Förbättringar av egenskapswebbläsaren omfattar:
- Bättre tangentbordsnavigering genom de olika nedrullningsbara markeringsfönstren.
- Minskade onödiga tabbstopp.
- Bättre rapportering av kontrolltyper.
- Förbättrat skärmläsarebeteende.
- Ändringar för att implementera hjälpmedelsmönster för användargränssnittet som saknas i kontroller.
Förslag
Så här väljer du in eller ut dessa ändringar För att programmet ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.1 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
- Den kompileras om för att rikta in sig på .NET Framework 4.7.1. Dessa hjälpmedelsändringar aktiveras som standard i Windows Forms-program som riktar sig mot .NET Framework 4.7.1 eller senare.
- Den avregistrerar sig från äldre hjälpmedelsbeteenden genom att lägga till följande AppContext-växel i
<runtime>
avsnittet i filen app.config och ställa in den påfalse
, som i följande exempel visas.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
Program som är inriktade på .NET Framework 4.7.1 eller senare och vill bevara det äldre hjälpmedelsbeteendet kan välja att använda äldre hjälpmedelsfunktioner genom att uttryckligen ange den här AppContext-växeln till true
.
En översikt över automatisering av användargränssnittet finns i översikten över UI Automation.
Stöd har lagts till för UI Automation-mönster och egenskaper
Hjälpmedelsklienter kan dra nytta av nya WinForms-hjälpmedelsfunktioner med hjälp av vanliga, offentligt beskrivna anropsmönster. Dessa mönster är inte WinForms-specifika. Hjälpmedelsklienter kan till exempel anropa metoden QueryInterface i IAccessible-gränssnittet (MAAS) för att hämta ett IServiceProvider-gränssnitt. Om det här gränssnittet är tillgängligt kan klienterna använda sin QueryService-metod för att begära ett IAccessibleEx-gränssnitt. Mer information finns i Använda IAccessibleEx från en klient. Från och med .NET Framework 4.7.1 är IServiceProvider och IAccessibleEx (om tillämpligt) tillgängliga för Hjälpmedelsobjekt för WinForms.
.NET Framework 4.7.1 lägger till stöd för följande gränssnittsautomatiseringsmönster och egenskaper:
Kontrollerna ToolStripSplitButton och ComboBox stöder mönstret Expandera/dölj.
Kontrollen ToolStripMenuItem har egenskapsvärdet ControlType.MenuItemControlType .
Kontrollen ToolStripItem stöder NameProperty egenskapen ochmönstret Expandera/dölj.
Kontrollen ToolStripDropDownItem stöder AccessibleEvents indikerar StateChange och NameChange när listrutan expanderas eller döljs.
Kontrollen ToolStripDropDownButton har egenskapsvärdet ControlType på ControlType.MenuItem.
Kontrollen DataGridViewCheckBoxCell stöder TogglePattern.
Kontrollerna NumericUpDown och DomainUpDown stöder NameProperty egenskapen och har en ControlType av ControlType.Spinner.
Förbättringar av PropertyGrid-kontrollen .NET Framework 4.7.1 lägger till följande förbättringar i PropertyBrowser-kontrollen:Knappen Information i den feldialogruta som visas när användaren anger ett felaktigt värde i PropertyGrid kontrollen stöder meddelanden om att expandera/dölj mönster, tillstånd och namnändring samt en ControlType-egenskap med värdet ControlType.MenuItem.
Meddelandefönstret som visas när knappen Information i feldialogrutan expanderas är nu tangentbordstillgänglig och tillåter Skärmläsaren att meddela innehållet i felmeddelandet.
Raderna AccessibleRole i PropertyGrid kontrollen har ändrats från "Rad" till "Cell". Cellen mappar till UIA ControlType "DataItem", vilket gör att den kan stödja lämpliga kortkommandon och Skärmläsarens meddelanden.
Kontrollraderna PropertyGrid som representerar rubrikobjekt när PropertyGrid kontrollen har en PropertySort egenskap inställd på PropertySort.Categorized har värdet ControlType-egenskapenControlType.Button.
De PropertyGrid kontrollrader som representerar rubrikobjekt när PropertyGrid kontrollen har en PropertySort egenskap inställd för att PropertySort.Categorized stödja mönstret Expandera/dölj.
Förbättrad tangentbordsnavigering mellan rutnätet och verktygsfältet ovanför det. Om du trycker på Skift-Tabb väljer du nu den första knapprutan i stället för hela verktygsfältet.
PropertyGrid kontroller som visas i läget Högkontrast ritar nu en fokusrektangel runt knapprutan som motsvarar det aktuella PropertySort egenskapsvärdet.
PropertyGrid kontroller som visas i högkontrastläge och med en PropertySort egenskap inställd på PropertySort.Categorized visar nu bakgrunden för kategorirubriker i en mycket kontrasterande färg.
PropertyGrid kontroller skiljer bättre mellan Verktygslistobjekt med fokus och verktygslistobjekt som anger egenskapens PropertySort aktuella värde. Den här korrigeringen består av en högkontraständring och en ändring för scenarier som inte är högkontrast.
PropertyGrid control ToolBar items which indicates the current value of the PropertySort property support the TogglePattern.
Förbättrat skärmläsarestöd för att särskilja den valda justeringen i justeringsväljaren.
När en tom PropertyGrid kontroll visas i ett formulär får den nu fokus där den tidigare inte skulle göra det.
Användning av OS-definierade färger i högkontrastteman
- Och-kontrollerna ButtonCheckBox med egenskapen FlatStyle inställd på FlatStyle.System, vilket är standardformatet, använder nu OS-definierade färger i högkontrasttema när de väljs. Tidigare var text- och bakgrundsfärger inte kontrasterande och svåra att läsa.
- Kontrollerna Button, CheckBox, RadioButton, Label, LinkLabeloch GroupBox med deras Enabled egenskap inställd på false använde en skuggad färg för att återge text i högkontrasttteman, vilket resulterade i låg kontrast mot bakgrunden. Nu använder dessa kontroller färgen "Inaktiverad text" som definierats av operativsystemet. Den här korrigeringen gäller för kontroller med egenskapen inställd på
FlatStyle
ett annat värde än FlatStyle.System. De senare kontrollerna återges av operativsystemet. - DataGridView återger nu en synlig rektangel runt innehållet i cellen som har det aktuella fokuset. Tidigare var detta inte synligt i vissa högkontrasteman.
- ToolStripMenuItem kontroller med deras Enabled egenskap inställd på false använder nu färgen "Inaktiverad text" som definierats av operativsystemet.
- ToolStripMenuItem kontroller med deras Checked egenskap inställd på true återger nu den associerade bockmarkeringen i en kontrasterande systemfärg. Tidigare var bockmarkeringsfärgen inte tillräckligt kontrasterande och inte synlig i högkontrastteman. Obs! Windows 10 har ändrat värden för vissa högkontrastsystemfärger. Windows Forms Framework baseras på Win32-ramverket. För bästa möjliga upplevelse kan du köra den senaste versionen av Windows och välja de senaste os-ändringarna genom att lägga till en app.manifest-fil i ett testprogram och ta bort kommentaren från följande kod:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Förbättrad tangentbordsnavigering
- När en ComboBox kontroll har sin DropDownStyle egenskap inställd ComboBoxStyle.DropDownList på och är den första kontrollen i flikordningen i formuläret visas nu en fokusrektangel när det överordnade formuläret öppnas med tangentbordet. Före den här ändringen låg tangentbordsfokus på den här kontrollen, men ingen fokusindikator renderades.
Förbättrat stöd för Skärmläsaren
Kontrollen MonthCalendar har lagt till stöd för hjälpmedelstekniker för åtkomst till kontrollen, inklusive möjligheten för Skärmläsaren att läsa värdet för kontrollen när den tidigare inte kunde det.
Kontrollen CheckedListBox meddelar nu Skärmläsaren när en CheckBox.CheckState egenskap har ändrats. Tidigare fick Skärmläsaren inget meddelande och därför skulle användarna inte informeras om att CheckState egenskapen hade uppdaterats.
Kontrollen LinkLabel har ändrat hur den meddelar Skärmläsaren om texten i kontrollen. Tidigare meddelade Skärmläsaren den här texten två gånger och läste "&" symboler som verklig text även om de inte är synliga för en användare. Den duplicerade texten togs bort från Skärmläsarens meddelanden samt onödiga "&" symboler.
Kontrolltyperna DataGridViewCell rapporterar nu korrekt skrivskyddad status till Skärmläsaren och andra hjälpmedelstekniker.
Skärmläsaren kan nu läsa systemmenyn för underordnade fönster i [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md) program.
Skärmläsaren kan nu läsa ToolStripMenuItem kontroller med en ToolStripItem.Enabled egenskap inställd på false. Tidigare kunde Skärmläsaren inte fokusera på inaktiverade menyalternativ för att läsa innehållet.
Name | Värde |
---|---|
Omfång | Huvudversion |
Version | 4.8 |
Typ | Ommåla |
Berörda API:er
- ToolStripDropDownButton.CreateAccessibilityInstance()
- DomainUpDown.DomainUpDownAccessibleObject.Name
- MonthCalendar.AccessibilityObject
Windows Presentation Foundation (WPF)
Hjälpmedelsförbättringar i WPF
Details
Förbättringar av högkontrast
- Kontrollens Expander fokus är nu synligt. I tidigare versioner av .NET Framework var det inte det.
- Texten i CheckBox och RadioButton kontrollerna när de väljs är nu lättare att se än i tidigare .NET Framework-versioner.
- Kantlinjen för en inaktiverad ComboBox är nu samma färg som den inaktiverade texten. I tidigare versioner av .NET Framework var det inte det.
- Inaktiverade och fokuserade knappar använder nu rätt temafärg. I tidigare versioner av .NET Framework gjorde de inte det.
- Listruteknappen visas nu när en ComboBox kontrolls format är inställt på ToolBar.ComboBoxStyleKey. I tidigare versioner av .NET Framework var det inte det.
- Sorteringsindikatorpilen i en DataGrid kontroll använder nu temafärger. I tidigare versioner av .NET Framework gjorde det inte det.
- Standardformatet för hyperlänkar ändras nu till rätt temafärg vid muspekaren. I tidigare versioner av .NET Framework gjorde det inte det.
- Tangentbordsfokus på alternativknappar är nu synligt. I tidigare versioner av .NET Framework var det inte det.
- Kontrollens DataGrid kryssruta använder nu de förväntade färgerna för feedback om tangentbordsfokus. I tidigare versioner av .NET Framework gjorde det inte det.
- De visuella objekten för tangentbordsfokus är nu synliga på ComboBox och ListBox kontroller. I tidigare versioner av .NET Framework var det inte det.
Förbättringar av interaktion med skärmläsare
- Expander kontroller meddelas nu korrekt som grupper (expandera/dölj) av skärmläsare.
- DataGridCell kontroller meddelas nu korrekt som datarutnätcell (lokaliserad) av skärmläsare.
- Skärmläsare meddelar nu namnet på en redigerbar ComboBox.
- PasswordBox kontroller inte längre visas som "inget objekt i vyn" av skärmläsare.
Stöd för LiveRegion
Skärmläsare, till exempel Skärmläsaren, hjälper människor att förstå användargränssnittet (UI) för ett program, vanligtvis genom att beskriva användargränssnittselementet som för närvarande har fokus. Men om ett gränssnittselement ändras någonstans på skärmen och det inte har fokus kanske användaren inte informeras och missar viktig information. LiveRegions är avsedda att lösa det här problemet. En utvecklare kan använda dem för att informera skärmläsaren eller någon annan UI Automation-klient om att en viktig ändring har gjorts i ett användargränssnittselement. Skärmläsaren kan sedan bestämma hur och när användaren ska informeras om ändringen. Egenskapen LiveSetting låter också skärmläsaren veta hur viktigt det är att informera användaren om ändringen i användargränssnittet.
Förslag
Så här väljer du in eller ut från dessa ändringar
För att programmet ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.1 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
Mål för .NET Framework 4.7.1. Detta är den rekommenderade metoden. Dessa hjälpmedelsändringar aktiveras som standard i WPF-program som är avsedda för .NET Framework 4.7.1 eller senare.
Den avregistrerar sig från äldre hjälpmedelsbeteenden genom att lägga till följande AppContext-växel i avsnittet i
<runtime>
appkonfigurationsfilen och ställa in den påfalse
, som i följande exempel visas.<?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/> </startup> <runtime> <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false' --> <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" /> </runtime> </configuration>
Program som riktar in sig på .NET Framework 4.7.1 eller senare och vill bevara det äldre hjälpmedelsbeteendet kan välja att använda äldre hjälpmedelsfunktioner genom att uttryckligen ange den här AppContext-växeln till true
.
En översikt över automatisering av användargränssnittet finns i Översikt över användargränssnittsautomation.
Name | Värde |
---|---|
Omfång | Huvudversion |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
- AutomationElementIdentifiers.LiveSettingProperty
- AutomationElementIdentifiers.LiveRegionChangedEvent
- System.Windows.Automation.AutomationLiveSetting
- AutomationProperties.LiveSettingProperty
- AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
- AutomationProperties.GetLiveSetting(DependencyObject)
- AutomationPeer.GetLiveSettingCore()
Selector SelectionChanged-händelse och selectedValue-egenskap
Details
Från och med .NET Framework 4.7.1 uppdaterar alltid Selector värdet för dess SelectedValue egenskap innan händelsen höjs SelectionChanged när dess val ändras. Detta gör egenskapen SelectedValue konsekvent med de andra urvalsegenskaperna (SelectedItem och SelectedIndex), som uppdateras innan händelsen höjs.
I .NET Framework 4.7 och tidigare versioner skedde uppdateringen av SelectedValue före händelsen i de flesta fall, men det inträffade efter händelsen om markeringsändringen orsakades av att egenskapen ändrades SelectedValue .
Förslag
Appar som riktar sig mot .NET Framework 4.7.1 eller senare kan välja bort den här ändringen och använda äldre beteende genom att lägga till följande i <runtime>
avsnittet i programkonfigurationsfilen:
<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>
Appar som riktar sig mot .NET Framework 4.7 eller tidigare men som körs på .NET Framework 4.7.1 eller senare kan aktivera det nya beteendet genom att lägga till följande rad i <runtime>
avsnittet i programmets .configuration-fil:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
TabControl SelectionChanged-händelse och egenskapen SelectedContent
Details
Från och med .NET Framework 4.7.1 uppdaterar ett TabControl värde för dess SelectedContent egenskap innan händelsen höjs SelectionChanged när dess val ändras. I .NET Framework 4.7 och tidigare versioner skedde uppdateringen av SelectedContent efter händelsen.
Förslag
Appar som riktar sig mot .NET Framework 4.7.1 eller senare kan välja bort den här ändringen och använda äldre beteende genom att lägga till följande i <runtime>
avsnittet i programkonfigurationsfilen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>
Appar som riktar sig mot .NET Framework 4.7 eller tidigare men som körs på .NET Framework 4.7.1 eller senare kan aktivera det nya beteendet genom att lägga till följande rad i <runtime>
avsnittet i programmets .configuration-fil:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
Standardhashalgoritmen för WPF PackageDigitalSignatureManager är nu SHA256
Details
Tillhandahåller System.IO.Packaging.PackageDigitalSignatureManager
funktioner för digitala signaturer i förhållande till WPF-paket. I .NET Framework 4.7 och tidigare versioner var standardalgoritmen (PackageDigitalSignatureManager.DefaultHashAlgorithm) som användes för signering av delar av ett paket SHA1. På grund av den senaste tidens säkerhetsproblem med SHA1 har det här standardvärdet ändrats till SHA256 från och med .NET Framework 4.7.1. Den här ändringen påverkar all paketsignering, inklusive XPS-dokument.
Förslag
En utvecklare som vill använda den här ändringen när han eller hon riktar in sig på en ramverksversion under .NET Framework 4.7.1 eller en utvecklare som kräver den tidigare funktionen när den riktar in sig på .NET Framework 4.7.1 eller senare kan ange följande AppContext-flagga på lämpligt sätt. Värdet true resulterar i att SHA1 används som standardalgoritm. falskt resultat i SHA256.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.1 |
Typ | Ommåla |
Berörda API:er
Windows Workflow Foundation (WF)
Hjälpmedelsförbättringar i WF-arbetsflödesdesignern (Windows Workflow Foundation)
Details
Arbetsflödesdesignern för Windows Workflow Foundation (WF) förbättrar hur den fungerar med hjälpmedelstekniker. Dessa förbättringar omfattar följande ändringar:
- Tabbordningen ändras till vänster till höger och uppifrån och ned i vissa kontroller:
- Initiera korrelationsfönstret för att ange korrelationsdata för InitializeCorrelation aktiviteten
- Fönstret innehållsdefinition för aktiviteterna Receive, Send, SendReplyoch ReceiveReply
- Fler funktioner är tillgängliga via tangentbordet:
- När du redigerar egenskaperna för en aktivitet kan egenskapsgrupper minimeras av tangentbordet första gången de fokuserar.
- Varningsikoner är nu tillgängliga via tangentbord.
- Knappen Fler egenskaper i Fönstret Egenskaper är nu tillgänglig via tangentbord.
- Tangentbordsanvändare kan nu komma åt rubrikobjekten i fönstret Argument och variabler i arbetsflödesdesignern.
- Förbättrad synlighet för objekt med fokus, till exempel när:
- Lägga till rader i datarutnät som används av arbetsflödesdesignern och aktivitetsdesigners.
- Tabbing genom fält i aktiviteterna ReceiveReply och SendReply .
- Ange standardvärden för variabler eller argument
- Skärmläsare kan nu känna igen:
- Brytpunkter som angetts i arbetsflödesdesignern.
- Aktiviteterna FlowSwitch<T>, FlowDecisionoch CorrelationScope .
- Innehållet i Receive aktiviteten.
- Måltypen för InvokeMethod aktiviteten.
- Kombinationsrutan Undantag och avsnittet Slutligen i TryCatch aktiviteten.
- Kombinationsrutan Meddelandetyp, splittern i fönstret Lägg till korrelationsinitierare, fönstret Innehållsdefinition och fönstret KorrelatesOn Defintion i meddelandeaktiviteterna (Receive, Send, SendReplyoch ReceiveReply).
- Tillståndsdatorövergångar och övergångsmål.
- Anteckningar och anslutningsappar för FlowDecision aktiviteter.
- Kontextmenyerna (högerklicka) för aktiviteter.
- Egenskapsvärderedigerarna, knappen Rensa sökning, knapparna Efter kategori och alfabetisk sortering och dialogrutan Uttrycksredigeraren i egenskapsrutnätet.
- Zoomprocenten i arbetsflödesdesignern.
- Avgränsaren i Parallel och Pick aktiviteter.
- Aktiviteten InvokeDelegate .
- Fönstret Välj typer för ordlisteaktiviteter (
Microsoft.Activities.AddToDictionary<TKey,TValue>
,Microsoft.Activities.RemoveFromDictionary<TKey,TValue>
osv.). - Fönstret Bläddra och välj .NET-typ.
- Sökvägar i arbetsflödesdesignern.
- Användare som väljer högkontrasteman ser många förbättringar i synligheten för arbetsflödesdesignern och dess kontroller, till exempel bättre kontrastförhållande mellan element och mer märkbara markeringsrutor som används för fokuselement.
Förslag
Om du har ett program med en ny värdbaserad arbetsflödesdesigner kan ditt program dra nytta av dessa ändringar genom att utföra någon av följande åtgärder:
- Kompilera om programmet för att rikta in sig på .NET Framework 4.7.1. Dessa hjälpmedelsändringar är aktiverade som standard.
- Om ditt program är avsett för .NET Framework 4.7 eller tidigare men körs på .NET Framework 4.7.1 kan du välja bort dessa äldre hjälpmedelsbeteenden genom att lägga till följande AppContext-växel i
<runtime>
avsnittet i filen app.config och ställa in den påfalse
, som följande exempel visar.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
Program som är inriktade på .NET Framework 4.7.1 eller senare och vill bevara det äldre hjälpmedelsbeteendet kan välja att använda äldre hjälpmedelsfunktioner genom att uttryckligen ange den här AppContext-växeln till true
.
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.1 |
Typ | Ommåla |
.NET Framework 4.7.2
Kärna
Tillåt unicode-dubbelriktade kontrolltecken i URI:er
Details
Unicode anger flera särskilda kontrolltecken som används för att ange textens orientering. I tidigare versioner av .NET Framework togs dessa tecken felaktigt bort från alla URI:er även om de fanns i deras procentkodade formulär. För att bättre kunna följa RFC 3987 tillåter vi nu dessa tecken i URI:er. När de hittas okodade i en URI är de procentkodade. När de hittas procentkodade lämnas de som de är.
Förslag
För program som riktar in sig på versioner av .NET Framework från och med 4.7.2 är stöd för Unicode-dubbelriktade tecken aktiverat som standard. Om den här ändringen inte är önskvärd kan du inaktivera den genom att lägga till följande AppContextSwitchOverrides-växel till <runtime>
avsnittet i programkonfigurationsfilen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=true" />
</runtime>
För program som riktar in sig på tidigare versioner av .NET Framework men körs under versioner som börjar med .NET Framework 4.7.2 inaktiveras stöd för dubbelriktade Unicode-tecken som standard. Du kan aktivera det genom att lägga till följande AppContextSwitchOverrides-växel till <runtime>
avsnittet i programkonfigurationsfilen::
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
DeflateStream använder interna API:er för dekomprimering
Details
Från och med .NET Framework 4.7.2 har implementeringen av dekomprimering i T:System.IO.Compression.DeflateStream
klassen ändrats till att använda interna Windows-API:er som standard. Detta resulterar vanligtvis i en betydande prestandaförbättring. Alla .NET-program som riktar sig till .NET Framework version 4.7.2 eller senare använder den interna implementeringen. Den här ändringen kan leda till vissa skillnader i beteende, bland annat:
- Undantagsmeddelanden kan skilja sig. Den typ av undantag som genereras förblir dock densamma.
- Vissa särskilda situationer, till exempel att inte ha tillräckligt med minne för att slutföra en åtgärd, kan hanteras på olika sätt.
- Det finns kända skillnader för parsning av gzip-huvudet (obs! endast
GZipStream
inställt för dekomprimering påverkas): - Undantag vid parsning av ogiltiga rubriker kan genereras vid olika tidpunkter.
- Den interna implementeringen tillämpar att värden för vissa reserverade flaggor i gzip-huvudet (dvs. FLG) anges enligt specifikationen, vilket kan leda till att det utlöser ett undantag där tidigare ogiltiga värden ignorerades.
Förslag
Om dekomprimering med inbyggda API:er har påverkat appens beteende negativt kan du välja bort den här funktionen genom att lägga till växeln Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression
runtime
i avsnittet i filen app.config och ställa in den på true
:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
Se till att System.Uri använder en konsekvent reserverad teckenuppsättning
Details
I System.Uriär vissa procentkodade tecken som ibland avkodades nu konsekvent kodade. Detta inträffar i de egenskaper och metoder som kommer åt URI:ns komponenter för sökväg, fråga, fragment eller userinfo. Beteendet ändras endast när båda följande är sanna:
- URI:n innehåller den kodade formen av något av följande reserverade tecken:
:
, ,'
(
,)
,!
eller*
. - URI:n innehåller ett Unicode- eller kodat icke-reserverat tecken. Om båda ovanstående är sanna, lämnas de kodade reserverade tecknen kodade. I tidigare versioner av .NET Framework avkodas de.
Förslag
För program som riktar in sig på versioner av .NET Framework från och med 4.7.2 aktiveras det nya avkodningsbeteendet som standard. Om den här ändringen inte är önskvärd kan du inaktivera den genom att lägga till följande AppContextSwitchOverrides-växel till <runtime>
avsnittet i programkonfigurationsfilen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=true" />
</runtime>
För program som riktar in sig på tidigare versioner av .NET Framework men körs under versioner som börjar med .NET Framework 4.7.2 inaktiveras det nya avkodningsbeteendet som standard. Du kan aktivera det genom att lägga till följande AppContextSwitchOverrides-växel till <runtime>
avsnittet i programkonfigurationsfilen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
Resgen vägrar att läsa in innehåll från webben
Details
.resx-filer kan innehålla binära formaterade indata. Om du försöker använda resgen för att läsa in en fil som har laddats ned från en plats som inte är betrodd kan den inte läsa in indata som standard.
Förslag
Resgen-användare som kräver inläsning av binärformaterade indata från ej betrodda platser kan antingen ta bort webbmärket från indatafilen eller tillämpa undantagsfelet. Lägg till följande registerinställning för att tillämpa datorn wide opt-out quirk: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Stackspårningar som hämtas när du använder bärbara PDF-filer innehåller nu källfil och radinformation om det begärs
Details
Från och med .NET Framework 4.7.2 innehåller stackspårningar som hämtas när du använder bärbara PDF-filer källfil och radinformation vid begäran. I versioner före .NET Framework 4.7.2 skulle källfil- och radinformation vara otillgängliga när du använder bärbara PDF-filer även om det uttryckligen begärs.
Förslag
För program som riktar sig mot .NET Framework 4.7.2 kan du välja bort källfilen och radinformationen när du använder bärbara PDF-filer 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.Diagnostics.IgnorePortablePDBsInStackTraces=true" />
</runtime>
För program som riktar in sig på tidigare versioner av .NET Framework men körs på .NET Framework 4.7.2 eller senare kan du välja källfilen och radinformationen när du använder bärbara PDF-filer genom att lägga till <runtime>
följande i avsnittet i app.config
filen:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
Windows Forms
Hjälpmedelsförbättringar i Windows Forms-kontroller för .NET 4.7.2
Details
Windows Forms Framework förbättrar hur det fungerar med hjälpmedelstekniker för att bättre stödja Windows Forms-kunder. Dessa inkluderar följande ändringar:
- Ändringar för att förbättra visningen under högkontrastläge.
- Ändringar för att förbättra tangentbordsnavigering i kontrollerna DataGridView och MenuStrip.
- Ändringar i interaktionen med Skärmläsaren.
Förslag
Så här väljer du in eller ut dessa ändringar För att programmet ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.2 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
- Den kompileras om för att rikta in sig på .NET Framework 4.7.2. Dessa hjälpmedelsändringar aktiveras som standard i Windows Forms-program som riktar sig mot .NET Framework 4.7.2 eller senare.
- Den riktar sig mot .NET Framework 4.7.1 eller tidigare version och avregistrerar sig från äldre hjälpmedelsbeteenden genom att lägga till följande AppContext Switch i
<runtime>
avsnittet i appkonfigurationsfilen och ställa in den påfalse
, som följande exempel visar.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
</runtime>
</configuration>
Observera att om du vill välja hjälpmedelsfunktioner som lagts till i .NET Framework 4.7.2 måste du också välja hjälpmedelsfunktioner i .NET Framework 4.7.1. Program som riktar sig mot .NET Framework 4.7.2 eller senare och vill bevara det äldre hjälpmedelsbeteendet kan välja att använda äldre hjälpmedelsfunktioner genom att uttryckligen ange den här AppContext-växeln till true
.
Användning av OS-definierade färger i högkontrastteman
- Listrutepilen för nu ToolStripDropDownButton använder OS-definierade färger i högkontrasttema.
- Buttonoch RadioButtonCheckBox kontroller med FlatStyle inställd FlatStyle.Flat på eller FlatStyle.Popup använder nu OS-definierade färger i högkontrasttema när du väljer det. Tidigare var text- och bakgrundsfärger inte kontrasterande och svåra att läsa.
- Kontroller som finns i en GroupBox som har dess Enabled egenskap inställd på
false
använder nu OS-definierade färger i högkontrasttema. - Kontrollerna ToolStripButton, ToolStripComboBoxoch ToolStripDropDownButton har ett ökat ljusstyrkakontrastförhållande i högkontrastläge.
- DataGridViewLinkCell använder som standard OS-definierade färger i högkontrastläge för egenskapen DataGridViewLinkCell.LinkColor . Obs! Windows 10 har ändrat värden för vissa högkontrastsystemfärger. Windows Forms Framework baseras på Win32-ramverket. För bästa möjliga upplevelse kan du köra den senaste versionen av Windows och välja de senaste os-ändringarna genom att lägga till en app.manifest-fil i ett testprogram och ta bort kommentaren från följande kod:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Förbättrat stöd för Skärmläsaren
- Skärmläsaren meddelar nu värdet för ToolStripMenuItem.ShortcutKeys egenskapen när du tillkännager texten i en ToolStripMenuItem.
- Skärmläsaren anger nu när en ToolStripMenuItem har sin Enabled egenskap inställd på
false
. - Skärmläsaren ger nu feedback om tillståndet för en kryssruta när ListView.CheckBoxes egenskapen är inställd
true
på . - Fokusordningen för skärmläsarens genomsökningsläge överensstämmer nu med kontrollernas visuella ordning i dialogrutan ClickOnce-nedladdning.
Förbättrat hjälpmedelsstöd för DataGridView
- Rader i en DataGridView kan nu sorteras med hjälp av tangentbordet. Nu kan en användare använda F3-nyckeln för att sortera efter den aktuella kolumnen.
- DataGridView.SelectionMode När är inställt på DataGridViewSelectionMode.FullRowSelectändrar kolumnrubriken färg för att ange den aktuella kolumnen när användaren tar flikarna genom cellerna i den aktuella raden.
- Egenskapen DataGridViewCell.DataGridViewCellAccessibleObject.Parent returnerar nu rätt överordnad kontroll.
Förbättrade visuella tips
- Kontrollerna RadioButton och CheckBox med en tom Text egenskap visar nu en fokusindikator när de får fokus.
Förbättrat stöd för Property Grid
De PropertyGrid underordnade kontrollelementen IsReadOnlyProperty returnerar nu endast en
true
för egenskapen när ett PropertyGrid-element är aktiverat.De PropertyGrid underordnade kontrollelementen IsEnabledProperty returnerar nu endast en
Förbättrad tangentbordsnavigeringfalse
för egenskapen när ett PropertyGrid-element kan ändras av användaren. En översikt över automatisering av användargränssnittet finns i översikten över UI Automation.ToolStripButton tillåter nu fokus när det finns i en ToolStripPanel som har egenskapen TabStop inställd på
true
.
Name | Värde |
---|---|
Omfång | Huvudversion |
Version | 4.7.2 |
Typ | Ommåla |
Egenskapen ContextMenuStrip.SourceControl innehåller en giltig kontroll när det gäller kapslade verktygStripMenuItems
Details
I .NET Framework 4.7.1 och tidigare versioner ContextMenuStrip.SourceControl returnerar egenskapen felaktigt null när användaren öppnar menyn från kapslade ToolStripMenuItem kontroller. I .NET Framework 4.7.2 och senare SourceControl är egenskapen alltid inställd på den faktiska källkontrollen.
Förslag
Så här väljer du in eller ut dessa ändringar För att ett program ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.2 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
- Den riktar sig till .NET Framework 4.7.2. Den här ändringen är aktiverad som standard i Windows Forms-program som är inriktade på .NET Framework 4.7.2 eller senare.
- Den riktar sig till .NET Framework 4.7.1 eller en tidigare version och avregistrerar sig från äldre hjälpmedelsbeteenden genom att lägga till följande AppContext Switch i
<runtime>
avsnittet i filen app.config och ställa in den påfalse
, som följande exempel visar.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>
Program som riktar sig mot .NET Framework 4.7.2 eller senare och vill bevara det äldre beteendet kan välja att använda det äldre källkontrollvärdet genom att uttryckligen ange den här AppContext-växeln till true
.
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
PrivateFontCollection.AddFontFile-metoden släpper teckensnittsresurser
Details
I .NET Framework 4.7.1 och tidigare versioner System.Drawing.Text.PrivateFontCollection släpper klassen inte GDI+-teckensnittsresurserna PrivateFontCollection efter att de har kasserats för Font objekt som har lagts till i den AddFontFile(String) här samlingen med hjälp av metoden . I .NET Framework 4.7.2 och senare Dispose släpps de GDI+-teckensnitt som lades till i samlingen som filer.
Förslag
Så här väljer du in eller ut dessa ändringar För att ett program ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.2 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
- Den kompileras om för att rikta in sig på .NET Framework 4.7.2. Den här ändringen är aktiverad som standard i Windows Forms-program som är inriktade på .NET Framework 4.7.2 eller senare.
- Den riktar sig till .NET Framework 4.7.1 eller en tidigare version och avregistrerar sig från äldre hjälpmedelsbeteenden genom att lägga till följande AppContext Switch i
<runtime>
avsnittet i filen app.config och ställa in den påfalse
, som följande exempel visar.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>
Program som riktar in sig på .NET Framework 4.7.2 eller senare och vill bevara det äldre beteendet kan välja att inte släppa teckensnittsresurser genom att uttryckligen ange den här AppContext-växeln till true
.
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
WinForms upp- och nedknappsåtgärder för domän är synkroniserade nu
Details
I .NET Framework 4.7.1 och tidigare versioner DomainUpDown ignoreras kontrollens DomainUpDown.UpButton() åtgärd när kontrolltexten finns, och utvecklaren måste använda DomainUpDown.DownButton() åtgärden på kontrollen innan åtgärden används DomainUpDown.UpButton() . Från och med .NET Framework 4.7.2 fungerar både DomainUpDown.UpButton() åtgärderna och DomainUpDown.DownButton() separat i det här scenariot och förblir synkroniserade.
Förslag
För att ett program ska kunna dra nytta av dessa ändringar måste det köras på .NET Framework 4.7.2 eller senare. Programmet kan dra nytta av dessa ändringar på något av följande sätt:
- Den kompileras om för att rikta in sig på .NET Framework 4.7.2. Den här ändringen är aktiverad som standard i Windows Forms-program som är inriktade på .NET Framework 4.7.2 eller senare.
- Den avregistrerar sig från det äldre rullningsbeteendet genom att lägga till följande AppContext Switch i
<runtime>
avsnittet i appkonfigurationsfilen och ställa in den påfalse
, som i följande exempel visas.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Berörda API:er
Windows Presentation Foundation (WPF)
Tangentbordsfokus flyttas nu korrekt över flera lager av WinForms/WPF-värdtjänster
Details
Överväg ett WPF-program som är värd för en WinForms-kontroll som i sin tur är värd för WPF-kontroller. Användare kanske inte kan ta en flik från WinForms-lagret om den första eller sista kontrollen i det lagret är WPF System.Windows.Forms.Integration.ElementHost
. Den här ändringen åtgärdar det här problemet och användarna kan nu ta en flik från WinForms-lagret. Automatiserade program som förlitar sig på fokus som aldrig kommer undan WinForms-lagret kanske inte längre fungerar som förväntat.
Förslag
En utvecklare som vill använda den här ändringen när han eller hon riktar in sig på en ramverksversion under .NET 4.7.2 kan ställa in följande uppsättning AppContext-flaggor på false för att ändringen ska aktiveras.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>
WPF-program måste välja alla förbättringar av tidig tillgänglighet för att få de senare förbättringarna. Med andra ord måste både Switch.UseLegacyAccessibilityFeatures
växlarna och Switch.UseLegacyAccessibilityFeatures.2
vara setA-utvecklare som kräver den tidigare funktionen när du riktar in dig på .NET 4.7.2 eller senare kan ställa in följande AppContext-flagga på true för att ändringen ska inaktiveras.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Standardhashalgoritmen för WPF:s markeringskompilerare är nu SHA256
Details
WPF MarkupCompiler tillhandahåller kompileringstjänster för XAML-markeringsfiler. I .NET Framework 4.7.1 och tidigare versioner var standardhashalgoritmen som används för kontrollsummor SHA1. På grund av den senaste tidens säkerhetsproblem med SHA1 har det här standardvärdet ändrats till SHA256 från och med .NET Framework 4.7.2. Den här ändringen påverkar alla generering av kontrollsummor för påläggsfiler under kompileringen.
Förslag
En utvecklare som riktar in sig på .NET Framework 4.7.2 eller senare och vill återgå till SHA1-hashbeteende måste ange följande AppContext-flagga.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>
En utvecklare som vill använda SHA256-hashning när de riktar in sig på en ramverksversion under .NET 4.7.2 måste ange flaggan AppContext nedan. Observera att den installerade versionen av .NET Framework måste vara 4.7.2 eller senare.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Transparent |
Version | 4.7.2 |
Typ | Ommåla |
WPF AppDomain-avstängningshantering kan nu anropa Dispatcher.Invoke i rensning av svaga händelser
Details
I .NET Framework 4.7.1 och tidigare versioner skapar WPF potentiellt en System.Windows.Threading.Dispatcher på .NET-finaliserartråden under AppDomain-avstängning. Detta har åtgärdats i .NET Framework 4.7.2 och senare versioner genom att göra rensningen av svaga händelser trådmedveten. På grund av detta kan WPF anropa Dispatcher.Invoke för att slutföra rensningsprocessen. I vissa program kan den här ändringen av tidpunkten för slutförande orsaka undantag under AppDomain eller processavstängning. Detta visas vanligtvis i program som inte korrekt stänger av avsändare som körs på arbetstrådar före processen eller AppDomain-avstängningen. Sådana program bör vara noga med att hantera livslängden för avsändare på ett korrekt sätt.
Förslag
I .NET Framework 4.7.2 och senare versioner kan utvecklare inaktivera den här korrigeringen för att lindra (men inte eliminera) tidsproblem som kan uppstå på grund av rensningsändringen. Om du vill inaktivera ändringen i rensningen använder du följande AppContext-flagga.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
WPF Ändra en primärnyckel när ADO-data visas i ett huvud-/detaljscenario
Details
Anta att du har en ADO-samling av objekt av typen Order
, med en relation med namnet "OrderDetails" som relaterar den till en samling objekt av typen Detail
via den primära nyckeln "OrderID". I DIN WPF-app kan du binda en listkontroll till informationen för en viss ordning:
<ListBox ItemsSource="{Binding Path=OrderDetails}" >
där DataContext är en Order
. WPF hämtar värdet för OrderDetails
egenskapen – en samling D för alla Detail
objekt vars OrderID
matchar OrderID
huvudobjektets. Beteendeändringen uppstår när du ändrar huvudobjektets primärnyckel OrderID
. ADO ändrar automatiskt var OrderID
och en av de berörda posterna i samlingen Information (det vill säga de som kopieras till samling D). Men vad händer med D?
- Gammalt beteende: Samling D rensas. Huvudobjektet skapar inte ett ändringsmeddelande för egenskapen
OrderDetails
. ListBox fortsätter att använda samling D, som nu är tom. - Nytt beteende: Samling D är oförändrad. Var och en av dess objekt skapar ett ändringsmeddelande för egenskapen
OrderID
. ListBox fortsätter att använda samling D och visar informationen med den nyaOrderID
. WPF implementerar det nya beteendet genom att skapa samling D på ett annat sätt: genom att anropa ADO-metoden DataRowView.CreateChildView(DataRelation, Boolean) medfollowParent
argumentet inställt påtrue
.
Förslag
En app hämtar det nya beteendet med hjälp av följande AppContext-växel.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
</runtime>
</configuration>
Växlingen är som standard (gammalt beteende) för appar som riktar sig mot true
.NET 4.7.1 eller senare och till (nytt beteende) för appar som riktar sig mot false
.NET 4.7.2 eller senare.
Name | Värde |
---|---|
Omfång | Mindre |
Version | 4.7.2 |
Typ | Ommåla |
WPF FocusVisual för RadioButton och kryssrutan visas nu korrekt när kontrollerna inte har något innehåll
Details
I .NET Framework 4.7.1 och tidigare versioner har WPF System.Windows.Controls.CheckBox och System.Windows.Controls.RadioButton inkonsekventa och, i klassiska och högkontrastt teman, felaktiga visuella fokusobjekt. Dessa problem uppstår i fall där kontrollerna inte har någon innehållsuppsättning. Detta kan göra övergången mellan teman förvirrande och det visuella fokusobjektet svårt att se. I .NET Framework 4.7.2 är de här visuella objekten nu mer konsekventa mellan teman och mer synliga i klassiska teman och högkontrastt-teman.
Förslag
En utvecklare som är inriktad på .NET Framework 4.7.2 som vill återgå till beteendet i .NET 4.7.1 måste ange följande AppContext-flagga.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>
En utvecklare som vill använda den här ändringen när den riktar in sig på en ramverksversion under .NET 4.7.2 måste ange följande AppContext-flaggor. Observera att alla flaggor måste anges på rätt sätt och att den installerade versionen av .NET Framework måste vara 4.7.2 eller senare. WPF-program måste välja alla tidigare hjälpmedelsförbättringar för att få de senaste förbättringarna. Det gör du genom att se till att både AppContext-växlarna Switch.UseLegacyAccessibilityFeatures och Switch.UseLegacyAccessibilityFeatures.2 är inställda på false.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Textmarkering för WPF-textruta/lösenordsruta följer inte systemfärger
Details
I .NET Framework 4.7.1 och tidigare versioner kunde WPF System.Windows.Controls.TextBox
och System.Windows.Controls.PasswordBox
endast återge en textmarkering i Adorner-lagret. I vissa systemteman skulle detta occlude text, vilket gör det svårt att läsa. I .NET Framework 4.7.2 och senare har utvecklare möjlighet att aktivera ett icke-Adorner-baserat urvalsrenderingsschema som lindrar problemet.
Förslag
En utvecklare som vill använda den här ändringen måste ange följande AppContext-flagga på rätt sätt. Om du vill använda den här funktionen måste den installerade .NET Framework-versionen vara 4.7.2 eller senare. Om du vill aktivera den icke-utsmyckningsbaserade markeringen använder du följande AppContext-flagga.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |
Windows Workflow Foundation (WF)
Undvika oändlig rekursion för IWorkflowInstanceManagement.TransactedCancel och IWorkflowInstanceManagement.TransactedTerminate
Details
Under vissa omständigheter när du använder IWorkflowInstanceManagement.TransactedCancel eller IWorkflowInstanceManagement.TransactedTerminate API:er för att avbryta eller avsluta en arbetsflödestjänstinstans kan arbetsflödesinstansen stöta på ett stackspill på grund av oändlig rekursion när körningen Workflow
försöker bevara tjänstinstansen som en del av bearbetningen av begäran. Problemet uppstår om arbetsflödesinstansen är i ett tillstånd där den väntar på att någon annan utestående WCF-begäran till en annan tjänst ska slutföras. Åtgärderna TransactedCancel
och TransactedTerminate
skapar arbetsobjekt som köas för arbetsflödestjänstinstansen. Dessa arbetsobjekt körs inte som en del av bearbetningen TransactedCancel/TransactedTerminate
av begäran. Eftersom arbetsflödestjänstinstansen är upptagen och väntar på att den andra utestående WCF-begäran ska slutföras förblir det skapade arbetsobjektet i kö. Åtgärden TransactedCancel/TransactedTerminate
slutförs och kontrollen returneras tillbaka till klienten. När transaktionen som är associerad med TransactedCancel/TransactedTerminate
åtgärden försöker checka in måste den bevara instanstillståndet för arbetsflödestjänsten. Men eftersom det finns en utestående WCF
begäran för instansen kan arbetsflödeskörningen inte bevara arbetsflödestjänstinstansen, och en oändlig rekursionsloop leder till stackens spill. Eftersom TransactedCancel
och TransactedTerminate
bara skapar ett arbetsobjekt i minnet har det faktum att en transaktion finns ingen effekt. En återställning av transaktionen tar inte bort arbetsobjektet. För att lösa det här problemet, med början i .NET Framework 4.7.2, har vi introducerat en AppSetting
som kan läggas till web.config/app.config
i arbetsflödestjänsten som uppmanar den att ignorera transaktioner för TransactedCancel
och TransactedTerminate
. Detta gör att transaktionen kan checka in utan att vänta på att arbetsflödesinstansen ska sparas. AppSetting för den här funktionen heter microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate
. Värdet true
anger att transaktionen ska ignoreras och därmed undvika stackspill. Standardvärdet för den här AppSetting är false
, så befintliga arbetsflödestjänstinstanser påverkas inte.
Förslag
Om du använder AppFabric eller en annan IWorkflowInstanceManagement klient och stöter på ett stackspill i arbetsflödestjänstinstansen när du försöker avbryta eller avsluta en arbetsflödesinstans kan du lägga till följande i <appSettings>
avsnittet i filen web.config/app.config för arbetsflödestjänsten:
<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>
Om du inte stöter på problemet behöver du inte göra det.
Name | Värde |
---|---|
Omfång | Edge |
Version | 4.7.2 |
Typ | Ommåla |