Share via

Körningsändringar för migrering till .NET Framework 4.6.x

  • Artikel

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

.NET framework 4.6

ASP.NET

GridViews med AllowCustomPaging inställt på true kan utlösa PageIndexChanging-händelsen när den sista sidan i vyn lämnas

Details

En bugg i .NET Framework 4.5 gör System.Web.UI.WebControls.GridView.PageIndexChanging att det ibland inte utlöses för System.Web.UI.WebControls.GridViews som har aktiverat System.Web.UI.WebControls.GridView.AllowCustomPaging.

Förslag

Det här problemet har åtgärdats i .NET Framework 4.6 och kan åtgärdas genom uppgradering till den versionen av .NET Framework. Som en work-around kan appen göra ett explicit BindGrid på alla Page_Load som skulle träffa dessa villkor ( System.Web.UI.WebControls.GridView är på den sista sidan och SistaSystem.Web.UI.WebControls.GridView.PageSize skiljer sig från System.Web.UI.WebControls.GridView.PageSize). Du kan också ändra appen så att den tillåter växling (i stället för anpassad växling), eftersom det scenariot inte visar på problemet.

Name Värde
Omfång Mindre
Version 4,5
Typ Körmiljö

Berörda API:er

Kärna

En ConcurrentDictionary-serialiserad i .NET Framework 4.5 med NetDataContractSerializer kan inte deserialiseras av .NET Framework 4.5.1 eller 4.5.2

Details

På grund av interna ändringar av typen ConcurrentDictionary<TKey,TValue> kan objekt som serialiseras med .NET Framework 4.5 med hjälp av System.Runtime.Serialization.NetDataContractSerializer inte deserialiseras i .NET Framework 4.5.1 eller i .NET Framework 4.5.2.Observera att det går i den andra riktningen (serialisering med .NET Framework 4.5.x och deserialisering med .NET Framework 4.5) fungerar. På samma sätt fungerar all serialisering mellan 4.x med .NET Framework 4.6.Serialisering och deserialisering med en enda version av .NET Framework påverkas inte.

Förslag

Om det är nödvändigt att serialisera och deserialisera en System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> mellan .NET Framework 4.5 och .NET Framework 4.5.1/4.5.2 bör en annan serialiserare som den System.Runtime.Serialization.DataContractSerializer användas i stället för System.Runtime.Serialization.NetDataContractSerializer. Eftersom det här problemet åtgärdas i .NET Framework 4.6 kan det också lösas genom att uppgradera till den versionen av .NET Framework.

Name Värde
Omfång Mindre
Version 4.5.1
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

AppDomainSetup.DynamicBase randomiseras inte längre av UseRandomizedStringHashAlgorithm

Details

Före .NET Framework 4.6 skulle värdet DynamicBase för randomiseras mellan programdomäner eller mellan processer om UseRandomizedStringHashAlgorithm aktiverades i appens konfigurationsfil. Från och med .NET Framework 4.6 DynamicBase returneras ett stabilt resultat mellan olika instanser av en app som körs och mellan olika appdomäner. Dynamiska baser skiljer sig fortfarande åt för olika appar. Den här ändringen tar bara bort det slumpmässiga namngivningselementet för olika instanser av samma app.

Förslag

Tänk på att aktivering UseRandomizedStringHashAlgorithm inte leder till DynamicBase att randomiseras. Om en slumpmässig bas behövs måste den skapas i appens kod i stället för via det här API:et.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

Anropar Attribute.GetCustomAttributes på en indexerareegenskap genererar inte längre AmbiguousMatchException om tvetydigheten kan lösas av indextypen

Details

Innan .NET Framework 4.6 anropar GetCustomAttribute(s) du en indexerareegenskap som endast skiljer sig från en annan egenskap beroende på vilken typ av index som skulle resultera i en System.Reflection.AmbiguousMatchException. Från och med .NET Framework 4.6 returneras egenskapens attribut korrekt.

Förslag

Tänk på att GetCustomAttribute(er) fungerar oftare nu. Om en app tidigare förlitade sig på System.Reflection.AmbiguousMatchExceptionbör reflektionen nu användas för att uttryckligen söka efter flera indexerare i stället.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

COR_PRF_GC_ROOT_HANDLEs räknas inte upp av profilerare

Details

I .NET Framework v4.5.1 returneras COR_PRF_GC_ROOT_HANDLE profilerings-APIRootReferences2():et felaktigt aldrig (de returneras som COR_PRF_GC_ROOT_OTHER i stället). Det här problemet har åtgärdats från och med .NET Framework 4.6.

Förslag

Det här problemet har åtgärdats i .NET Framework 4.6 och kan åtgärdas genom uppgradering till den versionen av .NET Framework.

Name Värde
Omfång Mindre
Version 4.5.1
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

ETW EventListeners samlar inte in händelser från leverantörer med explicita nyckelord (t.ex. TPL-providern)

Details

ETW EventListeners med en tom nyckelordsmask samlar inte in händelser från leverantörer med explicita nyckelord korrekt. I .NET Framework 4.5 började TPL-providern tillhandahålla explicita nyckelord och utlöste det här problemet. I .NET Framework 4.6 har EventListeners uppdaterats för att inte längre ha det här problemet.

Förslag

Du kan undvika det här problemet genom att ersätta anrop till EnableEvents(EventSource, EventLevel) med anrop till EnableEvents-överlagringen som uttryckligen anger vilken "nyckelordsmask" som ska användas: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Alternativt har det här problemet åtgärdats i .NET Framework 4.6 och kan åtgärdas genom att uppgradera till den versionen av .NET Framework.

Name Värde
Omfång Edge
Version 4,5
Typ Körmiljö

Berörda API:er

Persisk kalender använder nu Hijri-solalgoritmen

Details

Från och med .NET Framework 4.6 System.Globalization.PersianCalendar använder klassen Hijri-solalgoritmen. Konvertering av System.Globalization.PersianCalendar datum mellan och andra kalendrar kan ge ett något annorlunda resultat som börjar med .NET Framework 4.6 för datum tidigare än 1800 eller senare än 2023 (gregoriansk). PersianCalendar.MinSupportedDateTime Är också nu March 22, 0622 i stället March 21, 0622för .

Förslag

Tänk på att vissa tidiga eller sena datum kan skilja sig något när du använder PersianCalendar i .NET Framework 4.6. När du serialiserar datum mellan processer som kan köras på olika .NET Framework-versioner ska du inte heller lagra dem som persiskaCalendar-datumsträngar (eftersom dessa värden kan vara olika).

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Reflektionsobjekt kan inte längre skickas från hanterad kod till OPROCESS DCOM-klienter

Details

Reflektionsobjekt kan inte längre skickas från hanterad kod till OPROCESS DCOM-klienter. Följande typer påverkas:

Anrop till IMarshal för objektet returnerar E_NOINTERFACE.

Förslag

Uppdatera kod för marskalkering så att den fungerar med objekt som inte är reflektionsobjekt.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

TargetFrameworkName för standardappdomänen är inte längre null om den inte har angetts

Details

Var System.AppDomainSetup.TargetFrameworkName tidigare null i standardappdomänen, såvida den inte uttryckligen angavs. Från och med 4.6 System.AppDomainSetup.TargetFrameworkName har egenskapen för standardappdomänen ett standardvärde som härleds från TargetFrameworkAttribute (om en finns). Appdomäner som inte är standard fortsätter att ärva sina System.AppDomainSetup.TargetFrameworkName från standardappdomänen (som inte är null i 4.6) om den inte uttryckligen åsidosätts.

Förslag

Koden bör uppdateras så att den inte är beroende av TargetFrameworkName att standardvärdet är null. Om det krävs att den här egenskapen fortsätter att utvärderas till null kan den uttryckligen anges till det värdet.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

X509Certificate2.ToString(booleskt) genererar inte nu när .NET inte kan hantera certifikatet

Details

I .NET Framework 4.5.2 och tidigare versioner skulle den här metoden utlösa om true den skickades för den utförliga parametern och det fanns certifikat installerade som inte stöddes av .NET Framework. Nu kommer metoden att lyckas och returnera en giltig sträng som utelämnar de otillgängliga delarna av certifikatet.

Förslag

All kod som är beroende av X509Certificate2.ToString(Boolean) bör uppdateras för att förvänta sig att den returnerade strängen kan undanta vissa certifikatdata (till exempel offentlig nyckel, privat nyckel och tillägg) i vissa fall där API:et tidigare skulle ha genererats.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

Data

Försök att upprätta en TCP/IP-anslutning till en SQL Server-databas som löser localhost fel

Details

I .NET Framework 4.6 och 4.6.1 inträffade ett localhost nätverksrelaterat eller instansspecifikt fel när en anslutning till SQL Server upprättades. Servern hittades inte eller var inte tillgänglig. Verifiera att instansnamnet är korrekt och att SQL Server är konfigurerat att tillåta fjärranslutningar. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)"

Förslag

Det här problemet har åtgärdats och det tidigare beteendet återställdes i .NET Framework 4.6.2. Om du vill ansluta till en SQL Server-databas som matchar till localhostuppgraderar du till .NET Framework 4.6.2.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

Felsökare

Null coalescer-värden visas inte i felsökningsprogrammet förrän ett steg senare

Details

En bugg i .NET Framework 4.5 gör att värden som anges via en null-sammankopplingsåtgärd inte visas i felsökningsprogrammet direkt efter att tilldelningsåtgärden körs när den körs på 64-bitarsversionen av Framework.

Förslag

Om du stegar ytterligare en gång i felsökningsprogrammet kommer värdet för det lokala fältet att uppdateras korrekt. Det här problemet har också åtgärdats i .NET Framework 4.6; uppgradering till den versionen av ramverket bör lösa problemet.

Name Värde
Omfång Edge
Version 4,5
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

Nätverk

ContentDisposition DateTimes returnerar något annorlunda sträng

Details

Strängrepresentationer av System.Net.Mime.ContentDisposition's har uppdaterats, från och med 4.6, för att alltid representera timkomponenten i en System.DateTime med två siffror. Detta är att följa RFC822 och RFC2822. Detta gör ToString() att en något annorlunda sträng returneras i 4.6 i scenarier där ett av borttagningens tidselement var före 10:00. Observera att ContentDispositions ibland serialiseras genom att konvertera dem till strängar, så alla ToString() åtgärder, serialiseringar eller GetHashCode-anrop bör granskas.

Förslag

Förvänta dig inte att strängrepresentationer av ContentDispositions från olika .NET Framework-versioner kommer att jämföras korrekt med varandra. Konvertera strängarna tillbaka till ContentDispositions, om möjligt, innan du utför en jämförelse.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Serialization

Undantagsmeddelandet har ändrats för misslyckad DataContract-serialisering i händelse av en okänd typ

Details

Från och med .NET Framework 4.6 har det undantagsmeddelande som ges om en System.Runtime.Serialization.DataContractSerializer eller System.Runtime.Serialization.Json.DataContractJsonSerializer misslyckas med att serialisera eller deserialisera på grund av saknade "kända typer" förtydligats.

Förslag

Appar bör inte vara beroende av specifika undantagsmeddelanden. Om en app är beroende av det här meddelandet uppdaterar du det för att förvänta dig det nya meddelandet eller (helst) ändra det så att det bara beror på undantagstypen.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

Installation och distribution

Ändringar i produktversioner i .NET Framework 4.6 och senare versioner

Details

Produktversioner har ändrats från tidigare versioner av .NET Framework, särskilt från .NET Framework 4, 4.5, 4.5.1 och 4.5.2. Följande är de detaljerade ändringarna:

  • Värdet för Version posten i HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full nyckeln har ändrats till 4.6.xxxxx för .NET Framework 4.6 och dess punktutgåvor och till 4.7.xxxxx för .NET Framework 4.7 och 4.7.1. I .NET Framework 4.5, 4.5.1 och 4.5.2 hade det formatet 4.5.xxxxx.
  • Fil- och produktversionsversionen för .NET Framework-filer har ändrats från det tidigare versionsschemat 4.0.30319.x till 4.6.X.0 för .NET Framework 4.6 och dess punktutgåvor och till 4.7.X.0 för .NET Framework 4.7 och 4.7.1. Du kan se dessa nya värden när du visar filens egenskaper efter att ha högerklickat på en fil.
  • Attributen AssemblyFileVersionAttribute och AssemblyInformationalVersionAttribute för hanterade sammansättningar har versionsvärden i formatet 4.6.X.0 för .NET Framework 4.6 och dess punktversioner och 4.7.X.0 för .NET Framework 4.7 och 4.7.1.
  • I .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 och 4.7.1 returnerar egenskapen strängen Environment.Version för fast version 4.0.30319.42000. I .NET Framework 4, 4.5, 4.5.1 och 4.5.2 returneras versionssträngar i formatet 4.0.30319.xxxxx (till exempel "4.0.30319.18010"). Observera att vi inte rekommenderar att programkoden tar något nytt beroende av egenskapen Environment.Version.

Mer information finns i Så här avgör du vilka .NET Framework-versioner som är installerade.

Förslag

I allmänhet bör program vara beroende av de rekommenderade teknikerna för att identifiera sådant som körningsversionen av .NET Framework och installationskatalogen:

Viktigt!

Undernyckelnamnet är NET Framework Setup, inte .NET Framework Setup.

  • Om du vill fastställa katalogsökvägen till .NET Framework common language runtime anropar du RuntimeEnvironment.GetRuntimeDirectory() metoden.
  • Anropa metoden för att hämta CLR-versionen RuntimeEnvironment.GetSystemVersion() . För .NET Framework 4 och dess punktversioner (.NET Framework 4.5, 4.5.1, 4.5.2 och .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 och 4.7.1) returneras strängen v4.0.30319.
Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

.NET Framework 4.6 använder inte en 4.5.x.x-version när du registrerar sig i registret

Details

Som man kan förvänta sig börjar versionsnyckeln i registret (på HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) för .NET Framework 4.6 med "4.6", inte "4.5". Appar som är beroende av dessa registernycklar för att veta vilka .NET Framework-versioner som är installerade på en dator bör uppdateras för att förstå att 4.6 är en ny möjlig version och en version som är kompatibel med tidigare 4.5.x-versioner.

Förslag

Uppdatera appsökning för en .NET Framework 4.5-installation genom att leta efter 4.5-registernycklar för att även acceptera 4.6.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

Windows Communication Foundation (WCF)

WCF-tjänster som använder NETTCP med SSL-säkerhet och MD5-certifikatautentisering

Details

.NET Framework 4.6 lägger till TLS 1.1 och TLS 1.2 i standardprotokolllistan för WCF SSL. När både klient- och serverdatorerna har .NET Framework 4.6 eller senare installerat används TLS 1.2 för förhandling. TLS 1.2 stöder inte MD5-certifikatautentisering. Om en kund använder ett MD5-certifikat kan WCF-klienten därför inte ansluta till WCF-tjänsten.

Förslag

Du kan kringgå det här problemet så att en WCF-klient kan ansluta till en WCF-server genom att göra något av följande:

  • Uppdatera certifikatet så att det inte använder MD5-algoritmen. Det här är den rekommenderade lösningen.
  • Om bindningen inte har konfigurerats dynamiskt i källkoden uppdaterar du programmets konfigurationsfil så att TLS 1.1 eller en tidigare version av protokollet används. På så sätt kan du fortsätta att använda ett certifikat med MD5-hashalgoritmen.

Varning

Den här lösningen rekommenderas inte eftersom ett certifikat med MD5-hashalgoritmen anses vara osäkert.

Följande konfigurationsfil gör detta:

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

Varning

Den här lösningen rekommenderas inte eftersom ett certifikat med MD5-hashalgoritmen anses vara osäkert.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

Windows Presentation Foundation (WPF)

Åtkomst till en WPF DataGrids valda objekt från en hanterare av DataGrids UnloadingRow-händelse kan orsaka en NullReferenceException

Details

På grund av en bugg i .NET Framework 4.5 kan händelsehanterare för DataGrid händelser som involverar borttagning av en rad orsaka att en System.NullReferenceException utlöses om de får åtkomst till DataGridegenskaperna eller System.Windows.Controls.Primitives.MultiSelector.SelectedItems .System.Windows.Controls.Primitives.Selector.SelectedItem

Förslag

Det här problemet har åtgärdats i .NET Framework 4.6 och kan åtgärdas genom uppgradering till den versionen av .NET Framework.

Name Värde
Omfång Mindre
Version 4,5
Typ Körmiljö

Berörda API:er

Anropa Items.Refresh på en WPF ListBox, ListView eller DataGrid med markerade objekt kan orsaka att dubbletter visas i elementet

Details

I .NET Framework 4.5 kan anrop av ListBox.Items.Refresh från kod medan objekt är markerade i en System.Windows.Controls.ListBox göra att de markerade objekten dupliceras i listan. Ett liknande problem uppstår med System.Windows.Controls.ListView och System.Windows.Controls.DataGrid. Detta har åtgärdats i .NET Framework 4.6.

Förslag

Det här problemet kan lösas genom att programmatiskt avmarkera objekt innan System.Windows.Data.CollectionView.Refresh() anropas och sedan välja dem igen när anropet har slutförts. Alternativt har det här problemet åtgärdats i .NET Framework 4.6 och kan åtgärdas genom att uppgradera till den versionen av .NET Framework.

Värde
Definitionsområde Mindre
Version: 4,5
Typ Körmiljö

Berörda API:er

CoerceIsSelectionBoxHighlighted

Details

Vissa sekvenser av åtgärder som involverar en System.Windows.Controls.ComboBox och dess datakälla kan resultera i en System.NullReferenceException.

Förslag

Uppgradera om möjligt till .NET Framework 4.6.2.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Problem med ListBoxItem IsSelected-bindning med ObservableCollection<T>. Flytta

Details

Att anropa Move(Int32, Int32) eller MoveItem(Int32, Int32) på en samling som är bunden till en System.Windows.Controls.ListBox med markerade objekt kan leda till oberäkneligt beteende med framtida val eller avmarkering av System.Windows.Controls.ListBox objekt.

Förslag

Att anropa System.Collections.ObjectModel.Collection<T>.Remove(T) och System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) i stället för Move(Int32, Int32) kommer att lösa det här problemet. Alternativt har det här problemet åtgärdats i .NET Framework 4.6 och kan åtgärdas genom att uppgradera till den versionen av .NET Framework.

Name Värde
Omfång Mindre
Version 4,5
Typ Körmiljö

Berörda API:er

Om du högerklickar på en WPF DataGrid-radrubrik ändras DataGrid-markeringen

Details

Om du högerklickar på en markerad System.Windows.Controls.DataGrid radrubrik medan flera rader är markerade resulterar det i att markeringen ändras till endast den System.Windows.Controls.DataGridraden.

Förslag

Det här problemet har åtgärdats i .NET Framework 4.6 och kan åtgärdas genom uppgradering till den versionen av .NET Framework.

Name Värde
Omfång Edge
Version 4,5
Typ Körmiljö

Berörda API:er

WPF skapar en wisptis.exe process som kan frysa musen

Details

Ett problem introducerades i 4.5.2 som gör wisptis.exe att det skapas som kan frysa musindata.

Förslag

En korrigering för det här problemet finns i en serviceversion av .NET Framework 4.5.2 (sammanslagning av snabbkorrigeringar 3026376) eller genom att uppgradera till .NET Framework 4.6

Name Värde
Omfång Huvudversion
Version 4.5.2
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

WPF-stavningskontroll i textaktiverade kontroller fungerar inte i Windows 10 för språk som inte finns i operativsystemets indataspråklista

Details

När du kör på Windows 10 kanske stavningskontroll inte fungerar för WPF-textaktiverade kontroller eftersom plattformsfunktioner för stavningskontroll endast är tillgängliga för språk som finns i listan över indataspråk. I Windows 10, när ett språk läggs till i listan över tillgängliga tangentbord, laddar Windows automatiskt ned och installerar ett motsvarande FOD-paket (Feature on Demand) som tillhandahåller stavningskontrollfunktioner. Genom att lägga till språket i listan över indataspråk stöds stavningskontroll.

Förslag

Tänk på att det språk eller den text som ska stavas måste läggas till som indataspråk för att stavningskontroll ska fungera i Windows 10.

Name Värde
Omfång Edge
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

WPF-fönster återges utan urklipp när de utökas utanför en enda bildskärm

Details

I .NET Framework 4.6 som körs i Windows 8 och senare återges hela fönstret utan urklipp när det sträcker sig utanför en enda skärm i ett scenario med flera bildskärmar. Detta skiljer sig från tidigare versioner av .NET Framework som skulle klippa WPF-fönster som utökades utöver en enda skärm.

Förslag

Det här beteendet (om du vill klippa ut eller inte) kan uttryckligen ställas in med elementet <EnableMultiMonitorDisplayClipping> i <appSettings> ett programs konfigurationsfil eller genom att ange EnableMultiMonitorDisplayClipping egenskapen vid appstart.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

.NET Framework 4.6.1

Verktyg

Contract.Invariant eller Contract.Requires<TException> anser inte string.IsNullOrEmpty vara ren

Details

För appar som riktar sig mot .NET Framework 4.6.1, om det invarianta kontraktet för eller förhandsvillkorskontraktet för Contract.InvariantRequires anropar String.IsNullOrEmpty metoden, genererar rewriter kompilatorn varning CC1036: "Identifierade anrop till metoden 'System.String.IsNullOrWhiteSpace(System.String)' utan [Pure] i metoden." Det här är en kompilatorvarning i stället för ett kompilatorfel.

Förslag

Det här beteendet åtgärdades i GitHub-problem nr 339. Om du vill eliminera den här varningen kan du ladda ned och kompilera en uppdaterad version av källkoden för verktyget Kodkontrakt från GitHub. Nedladdningsinformation finns längst ned på sidan.

Name Värde
Omfång Mindre
Version 4.6.1
Typ Körmiljö

Berörda API:er

Windows Presentation Foundation (WPF)

Objektrullning av en platt lista med objekt med olika pixelhöjd

Details

När en System.Windows.Controls.ItemsControl visar en samling med virtualisering (IsVirtualizing=true) och objektrullning (ScrollUnit=Item), och när kontrollen rullar för att visa ett objekt vars höjd i bildpunkter skiljer sig från dess grannar, System.Windows.Controls.VirtualizingStackPanel itererar över alla objekt i samlingen. Användargränssnittet svarar inte under den här iterationen. Iterationen sker under andra omständigheter, även i tidigare .NET Framework-versioner. Det inträffar till exempel när pixelrullning (ScrollUnit=Pixel) påträffar ett objekt med annan pixelhöjd och när objektrullning av hierarkiska data (till exempel en eller en System.Windows.Controls.TreeViewSystem.Windows.Controls.ItemsControl med gruppering aktiverad) när ett objekt med ett annat antal underordnade objekt visas än grannarna. När det gäller objektrullning och annan pixelhöjd introducerades iterationen i .NET Framework 4.6.1 för att åtgärda buggar i layouten för hierarkiska data. Det behövs inte om data är flata (ingen hierarki) och .NET Framework 4.6.2 inte gör det i så fall.

Förslag

Om iterationen inträffar i .NET Framework 4.6.1 men inte i tidigare versioner – det vill säger att om System.Windows.Controls.ItemsControl är-objektet rullar en platt lista med objekt med olika pixelhöjd – finns det två åtgärder:

  • Installera .NET Framework 4.6.2.
  • Installera snabbkorrigeringen HR 1605 för .NET Framework 4.6.1.
Name Värde
Omfång Mindre
Version 4.6.1
Typ Körmiljö

Berörda API:er

ObjectDisposedException genereras av WPF-stavningskontroll

Details

WPF-program kraschar ibland under programavstängningen med en System.ObjectDisposedException utlöses av stavningskontroll. Detta åtgärdas i .NET Framework 4.7 WPF genom att hantera undantaget på ett smidigt sätt och därmed säkerställa att programmen inte längre påverkas negativt. Det bör noteras att tillfälliga undantag från första chansen fortsätter att observeras i program som körs under ett felsökningsprogram.

Förslag

Uppgradera till .NET Framework 4.7

Name Värde
Omfång Edge
Version 4.6.1
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

WPF-stavningskontroll misslyckas på oväntade sätt

Details

Detta omfattar ett antal problem med WPF-stavningskontroll:

Förslag

Problem 1 – Detta har åtgärdats i .NET Framework 4.6.2 Issue #2 – WPF Spell Checker stöds inte längre när program startas med "kör som en annan användare". Från och med .NET Framework 4.6.2 kraschar inte längre program som startas på det här sättet oväntat. Stavningskontroll kommer i stället att inaktiveras tyst. Problem nr 3 – Detta har åtgärdats i .NET Framework 4.6.2.

Name Värde
Omfång Edge
Version 4.6.1
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

.NET Framework 4.6.2

Data

Försök att upprätta en TCP/IP-anslutning till en SQL Server-databas som löser localhost fel

Details

I .NET Framework 4.6 och 4.6.1 inträffade ett localhost nätverksrelaterat eller instansspecifikt fel när en anslutning till SQL Server upprättades. Servern hittades inte eller var inte tillgänglig. Verifiera att instansnamnet är korrekt och att SQL Server är konfigurerat att tillåta fjärranslutningar. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)"

Förslag

Det här problemet har åtgärdats och det tidigare beteendet återställdes i .NET Framework 4.6.2. Om du vill ansluta till en SQL Server-databas som matchar till localhostuppgraderar du till .NET Framework 4.6.2.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

blockeringsperioden för Anslut ionspoolen för Azure SQL-databaser tas bort

Details

Från och med .NET Framework 4.6.2, för öppna anslutningsbegäranden till kända Azure SQL-databaser (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), tas blockeringsperioden för anslutningspoolen bort och anslutningsöppningsfel cachelagras inte. Försök att försöka öppna anslutningsbegäranden igen sker nästan omedelbart efter tillfälliga anslutningsfel. Den här ändringen gör att anslutningsöppningsförsöket kan göras om omedelbart för Azure SQL-databaser, vilket förbättrar prestandan för molnaktiverade appar. För alla andra anslutningsförsök fortsätter blockeringsperioden för anslutningspoolen att tillämpas.

I .NET Framework 4.6.1 och tidigare versioner, när en app stöter på ett tillfälligt anslutningsfel vid anslutning till en databas, kan anslutningsförsöket inte göras på nytt snabbt, eftersom anslutningspoolen cachelagrar felet och genererar det igen i 5 sekunder till 1 minut. Mer information finns i SQL Server Anslut ion Pooling (ADO.NET). Det här beteendet är problematiskt för anslutningar till Azure SQL-databaser, som ofta misslyckas med tillfälliga fel som vanligtvis återställs inom några sekunder. Blockeringsfunktionen för anslutningspoolen innebär att appen inte kan ansluta till databasen under en längre period, även om databasen är tillgänglig och appen måste återges inom några sekunder.

Förslag

Om det här beteendet är oönskat kan blockeringsperioden för anslutningspoolen konfigureras genom att ange egenskapen System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod som introducerades i .NET Framework 4.6.2. Värdet för egenskapen är medlem i uppräkningen System.Data.SqlClient.PoolBlockingPeriod som kan ta något av tre värden:

Det tidigare beteendet kan återställas genom att ställa in egenskapen på System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriodAlwaysBlock.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

Globalisering

Unicode-standardversion 8.0-kategorier stöds nu

Details

I .NET Framework 4.6.2 har Unicode-data uppgraderats från Unicode Standard version 6.3 till version 8.0. När du begär Unicode-teckenkategorier i .NET Framework 4.6.2 kanske vissa resultat inte matchar resultaten i tidigare .NET Framework-versioner. Denna ändring påverkar främst Cherokee syllables och New Tai Lue vokaler tecken och tonmärken.

Förslag

Granska kod och ta bort/ändra logik som är beroende av hårdkodade Unicode-teckenkategorier.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

Säkerhet

RSACng och DSACng kan återigen användas i scenarier med partiellt förtroende

Details

CngLightup (används i flera krypto-API:er på högre nivå, till exempel System.Security.Cryptography.Xml.EncryptedXml) och System.Security.Cryptography.RSACng förlitar sig i vissa fall på fullständigt förtroende. Dessa inkluderar P/Invokes utan att SecurityPermissionFlag.UnmanagedCode hävda behörigheter och kodsökvägar där System.Security.Cryptography.CngKey har behörighetskrav för SecurityPermissionFlag.UnmanagedCode. Från och med .NET Framework 4.6.2 användes CngLightup för att växla till System.Security.Cryptography.RSACng där det var möjligt. Därför började delvis betrodda appar som har använts System.Security.Cryptography.Xml.EncryptedXml att misslyckas och utlösa SecurityException undantag. Den här ändringen lägger till nödvändiga kontroller så att alla funktioner som använder CngLightup har de behörigheter som krävs.

Förslag

Om den här ändringen i .NET Framework 4.6.2 har påverkat dina partiella förtroendeappar negativt uppgraderar du till .NET Framework 4.7.1.

Name Värde
Omfång Edge
Version 4.6.2
Typ Körmiljö

Berörda API:er

RSACng.VerifyHash returnerar nu False för eventuella verifieringsfel

Details

Från och med .NET Framework 4.6.2 returnerar den här metoden False om själva signaturen är felaktigt formaterad. Den returnerar nu false för eventuella verifieringsfel. I .NET Framework 4.6 och 4.6.1 genererar metoden en System.Security.Cryptography.CryptographicException om själva signaturen är dåligt formaterad.

Förslag

All kod vars körning är beroende av hantering av System.Security.Cryptography.CryptographicException ska i stället köras om verifieringen misslyckas och metoden returnerar False.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

SignXml och EncryptedXml – icke-bakåtkompatibla ändringar

Details

I .NET Framework 4.6.2 kan säkerhetskorrigeringar i System.Security.Cryptography.Xml.SignedXml och System.Security.Cryptography.Xml.EncryptedXml leda till olika körningsbeteenden. Till exempel:

  • Om ett dokument har flera element med samma id attribut och en signatur riktar sig mot ett av dessa element som roten i signaturen, anses dokumentet nu vara ogiltigt.
  • Dokument som använder icke-kanoniska XPath-transformeringsalgoritmer i referenser anses nu vara ogiltiga.
  • Dokument som använder icke-kanoniska XSLT-transformeringsalgoritmer i referenser anses nu vara ogiltiga.
  • Alla program som använder externa resursens frånkopplade signaturer kommer inte att kunna göra det.

Förslag

Utvecklare kanske vill granska användningen av XmlDsigXsltTransform och XmlDsigXsltTransform, samt typer som härletts från Transform eftersom en dokumentmottagare kanske inte kan bearbeta den.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

Windows Communication Foundation (WCF)

Ta bort Ssl3 från WCF TransportDefaults

Details

När du använder NetTcp med transportsäkerhet och en typ av certifikat för autentiseringsuppgifter är SSL 3-protokollet inte längre ett standardprotokoll som används för att förhandla om en säker anslutning. I de flesta fall bör det inte påverka befintliga appar eftersom TLS 1.0 alltid har inkluderats i protokolllistan för NetTcp. Alla befintliga klienter bör kunna förhandla om en anslutning med minst TLS1.0.

Förslag

Om Ssl3 krävs använder du någon av följande konfigurationsmekanismer för att lägga till Ssl3 i listan över förhandlade protokoll.

Name Värde
Omfång Edge
Version 4.6.2
Typ Körmiljö

Berörda API:er

Windows Presentation Foundation (WPF)

Om du ändrar egenskapen IsEnabled för den överordnade kontrollen för en TextBlock-kontroll påverkas eventuella underordnade kontroller

Details

Från och med .NET Framework 4.6.2 påverkar ändring System.Windows.UIElement.IsEnabled av egenskapen för den överordnade System.Windows.Controls.TextBlock kontrollen eventuella underordnade kontroller (till exempel hyperlänkar och knappar) för System.Windows.Controls.TextBlock kontrollen. I .NET Framework 4.6.1 och tidigare versioner återspeglade kontrollerna i en System.Windows.Controls.TextBlock inte alltid tillståndet för System.Windows.UIElement.IsEnabled egenskapen för den System.Windows.Controls.TextBlock överordnade.

Förslag

Inga. Den här ändringen överensstämmer med det förväntade beteendet för kontroller i en System.Windows.Controls.TextBlock kontroll.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

CoerceIsSelectionBoxHighlighted

Details

Vissa sekvenser av åtgärder som involverar en System.Windows.Controls.ComboBox och dess datakälla kan resultera i en System.NullReferenceException.

Förslag

Uppgradera om möjligt till .NET Framework 4.6.2.

Name Värde
Omfång Mindre
Version 4,6
Typ Körmiljö

Berörda API:er

DataGridCellsPanel.BringIndexIntoView genererar ArgumentOutOfRangeException

Details

ScrollIntoView(Object) fungerar asynkront när kolumnvirtualisering är aktiverat men kolumnbredderna ännu inte har fastställts. Om kolumner tas bort innan det asynkrona arbetet inträffar kan en System.ArgumentOutOfRangeException inträffa.

Förslag

Något av följande:

  • Uppgradera till .NET Framework 4.7.
  • Installera den senaste underhållskorrigeringen för .NET Framework 4.6.2.
  • Undvik att ta bort kolumner tills det asynkrona svaret på ScrollIntoView(Object) har slutförts.
Name Värde
Omfång Edge
Version 4.6.2
Typ Körmiljö

Berörda API:er

Vågrät rullning och virtualisering

Details

Den här ändringen gäller för en System.Windows.Controls.ItemsControl som gör sin egen virtualisering i riktningen ortogonial till huvudrullningsriktningen (huvudexemplet är System.Windows.Controls.DataGrid med EnableColumnVirtualization="True"). Resultatet av vissa horisontella rullningsåtgärder har ändrats för att ge resultat som är mer intuitiva och mer analoga med resultatet av jämförbara vertikala åtgärder.

Åtgärderna inkluderar "Bläddra här" och "Höger kant", för att använda namnen från menyn som hämtas genom att högerklicka på en vågrät rullningslist. Båda dessa beräknar en kandidatförskjutning och anropar SetHorizontalOffset(Double).

När du har rullat till den nya förskjutningen kan begreppet "här" eller "högerkant" ha ändrats eftersom det nyligen avvirtualiserade innehållet har ändrat värdet System.Windows.Controls.Primitives.IScrollInfo.ExtentWidthför .

Före .NET Framework 4.6.2 använder rullningsåtgärden helt enkelt kandidatförskjutningen, även om den kanske inte är "här" eller vid "högerkanten" längre. Detta resulterar i effekter som "studsar" rullningstummen, vilket bäst illustreras av exempel. Anta att en System.Windows.Controls.DataGrid har ExtentWidth=1000 och Width=200. En rullning till "Right Edge" använder kandidatförskjutning 1000–200 = 800. När du bläddrar till den förskjutningen avvirtualiseras nya kolumner. Låt oss anta att de är mycket breda, så att System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth ändringarna till 2000. Rullningslisten slutar med HorizontalOffset=800 och tummen "studsar" tillbaka till nära mitten av rullningslisten – exakt vid 800/2000 = 40 %.

Ändringen är att räkna om en ny kandidatförskjutning när den här situationen inträffar och försöka igen. (Så här fungerar lodrät rullning redan.)

Ändringen ger slutanvändaren en mer förutsägbar och intuitiv upplevelse, men den kan också påverka alla appar som är beroende av System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset det exakta värdet för efter en vågrät rullning, oavsett om den anropas av slutanvändaren eller av ett explicit anrop till SetHorizontalOffset(Double).

Förslag

En app som använder ett förutsagt värde för bör ändras för System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset att hämta det faktiska värdet (och värdet för System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) efter en vågrät rullning som kan ändras System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth på grund av avvirtualisering.

Name Värde
Omfång Mindre
Version 4.6.2
Typ Körmiljö

Berörda API:er

Items.Clear tar inte bort dubbletter från SelectedItems

Details

Anta att en väljare (med flera val aktiverat) har dubbletter i samlingen System.Windows.Controls.Primitives.MultiSelector.SelectedItems – samma objekt visas mer än en gång. Det går inte att ta bort objekten från datakällan (t.ex. genom att anropa Items.Clear) från System.Windows.Controls.Primitives.MultiSelector.SelectedItems. Endast den första instansen tas bort. Dessutom kan efterföljande användning av System.Windows.Controls.Primitives.MultiSelector.SelectedItems (t.ex. SelectedItems.Clear()) stöta på problem som System.ArgumentException, eftersom System.Windows.Controls.Primitives.MultiSelector.SelectedItems innehåller objekt som inte längre finns i datakällan.

Förslag

Uppgradera om möjligt till .NET Framework 4.6.2.

Name Värde
Omfång Mindre
Version 4,5
Typ Körmiljö

Berörda API:er

Objektrullning av en platt lista med objekt med olika pixelhöjd

Details

När en System.Windows.Controls.ItemsControl visar en samling med virtualisering (IsVirtualizing=true) och objektrullning (ScrollUnit=Item), och när kontrollen rullar för att visa ett objekt vars höjd i bildpunkter skiljer sig från dess grannar, System.Windows.Controls.VirtualizingStackPanel itererar över alla objekt i samlingen. Användargränssnittet svarar inte under den här iterationen. Iterationen sker under andra omständigheter, även i tidigare .NET Framework-versioner. Det inträffar till exempel när pixelrullning (ScrollUnit=Pixel) påträffar ett objekt med annan pixelhöjd och när objektrullning av hierarkiska data (till exempel en eller en System.Windows.Controls.TreeViewSystem.Windows.Controls.ItemsControl med gruppering aktiverad) när ett objekt med ett annat antal underordnade objekt visas än grannarna. När det gäller objektrullning och annan pixelhöjd introducerades iterationen i .NET Framework 4.6.1 för att åtgärda buggar i layouten för hierarkiska data. Det behövs inte om data är flata (ingen hierarki) och .NET Framework 4.6.2 inte gör det i så fall.

Förslag

Om iterationen inträffar i .NET Framework 4.6.1 men inte i tidigare versioner – det vill säger att om System.Windows.Controls.ItemsControl är-objektet rullar en platt lista med objekt med olika pixelhöjd – finns det två åtgärder:

  • Installera .NET Framework 4.6.2.
  • Installera snabbkorrigeringen HR 1605 för .NET Framework 4.6.1.
Name Värde
Omfång Mindre
Version 4.6.1
Typ Körmiljö

Berörda API:er

RibbonGroup-bakgrunden är inställd på transparent i lokaliserade versioner

Details

System.Windows.Controls.Ribbon.RibbonGroup bakgrund på lokaliserade byggen målades alltid med transparent borste, vilket resulterade i dålig användargränssnittsupplevelse. Detta åtgärdas i .NET Framework 4.7 WPF-korrigering genom att uppdatera de lokaliserade resurserna för System.Windows.Controls.Ribbon.RibbonGroup, vilket i sin tur säkerställer att rätt pensel har valts.

Förslag

Uppgradera till .NET Framework 4.7

Name Värde
Omfång Edge
Version 4.6.2
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.

WPF-stavningskontroll misslyckas på oväntade sätt

Details

Detta omfattar ett antal problem med WPF-stavningskontroll:

Förslag

Problem 1 – Detta har åtgärdats i .NET Framework 4.6.2 Issue #2 – WPF Spell Checker stöds inte längre när program startas med "kör som en annan användare". Från och med .NET Framework 4.6.2 kraschar inte längre program som startas på det här sättet oväntat. Stavningskontroll kommer i stället att inaktiveras tyst. Problem nr 3 – Detta har åtgärdats i .NET Framework 4.6.2.

Name Värde
Omfång Edge
Version 4.6.1
Typ Körmiljö

Berörda API:er

Går inte att identifiera via API-analys.