Dela via

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

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

Detaljer

En bugg i .NET Framework 4.5 gör att System.Web.UI.WebControls.GridView.PageIndexChanging 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 lösning kan appen göra ett explicit BindGrid på alla Page_Load som uppfyller 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). Alternativt kan appen modifieras för att tillåta paginering (i stället för anpassad paginering), eftersom detta scenario inte visar på problemet.

Namn Värde
Omfång Underårig
Utgåva 4,5
Typ Körningstid

Berörda API:er

Kärna

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

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4.5.1
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

AppDomainSetup.DynamicBase randomiseras inte längre av UseRandomizedStringHashAlgorithm

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

Anropa Attribute.GetCustomAttributes på en indexeregenskap genererar inte längre AmbiguousMatchException om tvetydigheten kan lösas med hjälp av indexens typ.

Detaljer

Innan .NET Framework 4.6 skulle att anropa GetCustomAttribute(s) på en indexerareegenskap, som skiljer sig från en annan egenskap endast genom typen av index, 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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

COR_PRF_GC_ROOT_HANDLEs uppräknas inte av profilerare

Detaljer

I .NET Framework v4.5.1 returnerar profilerings-APIRootReferences2() felaktigt aldrig COR_PRF_GC_ROOT_HANDLE (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.

Namn Värde
Omfång Underårig
Utgåva 4.5.1
Typ Körningstid

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)

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,5
Typ Körningstid

Berörda API:er

Persisk kalender använder nu Hijri-solalgoritmen

Detaljer

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

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).

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Reflektionsobjekt kan inte längre skickas från hanterad kod till DCOM-klienter utanför process

Detaljer

Reflektionsobjekten kan inte längre skickas från hanterad kod till DCOM-klienter utanför process. 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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

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

Detaljer

System.AppDomainSetup.TargetFrameworkName var tidigare null i standardappen domänen, såvida det 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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

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

Detaljer

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 exkludera vissa certifikatdata (till exempel publik nyckel, privat nyckel och tillägg) i vissa fall där API:et tidigare skulle ha kastat ett undantag.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

Uppgifter

Försöket att upprätta en TCP/IP-anslutning till en SQL Server-databas som leder till localhost misslyckas

Detaljer

När man i .NET Framework 4.6 och 4.6.1 försöker skapa en TCP/IP-anslutning till en SQL Server-databas som resolvar till localhost, misslyckas det med felet "Ett nätverksrelaterat eller instansspecifikt fel inträffade när en anslutning till SQL Server upprättades. Servern hittades inte eller var inte tillgänglig. Kontrollera att instansnamnet är korrekt och att SQL Server har konfigurerats för att tillåta fjärranslutningar. (provider: SQL Network Interfaces, error: 26 - Fel när server/instans inte hittas)

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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

Debuggverktyg

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,5
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

Nätverkande

ContentDisposition DateTimes returnerar något annorlunda sträng

Detaljer

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 att ToString() returnerar en något annorlunda sträng i 4.6 i scenarier där ett av dispositionens 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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Serialisering

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

Installation och distribution

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

Detaljer

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.
  • För att hämta CLR-versionen, anropa RuntimeEnvironment.GetSystemVersion()-metoden. 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.
Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

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

Detaljer

.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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

Windows Presentation Foundation (WPF)

Åtkomst till valda objekt i en WPF DataGrid från en hanterare för DataGrids UnloadingRow-händelse kan leda till ett NullReferenceException.

Detaljer

På grund av en bugg i .NET Framework 4.5 kan händelsehanterare för DataGrid-händelser som involverar borttagandet av en rad orsaka att en System.NullReferenceException kastas när de har åtkomst till DataGrid's System.Windows.Controls.Primitives.Selector.SelectedItem eller System.Windows.Controls.Primitives.MultiSelector.SelectedItems-egenskaper.

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.

Namn Värde
Omfång Underårig
Utgåva 4,5
Typ Körningstid

Berörda API:er

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

Detaljer

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
Omfattning Underårig
Version: 4,5
Typ Körningstid

Berörda API:er

TvingaÄrMarkeringBoxMarkerad

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

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

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4,5
Typ Körningstid

Berörda API:er

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,5
Typ Körningstid

Berörda API:er

WPF skapar en wisptis.exe process som kan frysa musen

Detaljer

Ett problem introducerades i 4.5.2 som orsakar att wisptis.exe skapas, vilket kan göra att musens indata fryser.

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

Namn Värde
Omfång Huvudsaklig
Utgåva 4.5.2
Typ Körningstid

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4,6
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

WPF-fönster visas utan beskärning när de sträcker sig bort från en enskild bildskärm.

Detaljer

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 beskära WPF-fönster som sträckta sig över flera skärmar.

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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

.NET Framework 4.6.1

Arbetsredskap

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

Detaljer

För appar som riktar sig mot .NET Framework 4.6.1, om det invarianta kontraktet för Contract.Invariant eller förhandsvillkorskontraktet för Requires anropar metoden String.IsNullOrEmpty, genererar rewriter en kompilatorvarning 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.

Namn Värde
Omfång Underårig
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

Windows Presentation Foundation (WPF)

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

Detaljer

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 vid pixelrullning (ScrollUnit=Pixel) när ett objekt med annan pixelhöjd påträffas, och vid objektrullning av hierarkiska data, till exempel en System.Windows.Controls.TreeView eller en System.Windows.Controls.ItemsControl med aktiverad gruppering, när ett objekt med ett annat antal underordnade objekt än dess grannar visas. För fall med objektrullning och olika 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äga att om System.Windows.Controls.ItemsControl-objektet scrollar en enkel 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.
Namn Värde
Omfång Underårig
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

ObjectDisposedException genereras av WPF-stavningskontroll

Detaljer

WPF-programmen kraschar ibland under avstängning med ett System.ObjectDisposedException som kastas av stavningskontrollen. 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

Namn Värde
Omfång Kant
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

.NET Framework 4.6.2

Uppgifter

Försöket att upprätta en TCP/IP-anslutning till en SQL Server-databas som leder till localhost misslyckas

Detaljer

När man i .NET Framework 4.6 och 4.6.1 försöker skapa en TCP/IP-anslutning till en SQL Server-databas som resolvar till localhost, misslyckas det med felet "Ett nätverksrelaterat eller instansspecifikt fel inträffade när en anslutning till SQL Server upprättades. Servern hittades inte eller var inte tillgänglig. Kontrollera att instansnamnet är korrekt och att SQL Server har konfigurerats för att tillåta fjärranslutningar. (provider: SQL Network Interfaces, error: 26 - Fel när server/instans inte hittas)

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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

Blockeringsperioden för anslutningspooler för Azure SQL-databaser tas bort

Detaljer

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 utföras på nytt snabbt, eftersom anslutningspoolen cachelagrar felet och återväxar det i 5 sekunder till 1 minut. Mer information finns i SQL Server-anslutningspool (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 du konfigurera blockeringsperioden för anslutningspoolen 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 System.Data.SqlClient.PoolBlockingPeriod enumerationen som kan ta något av tre värden.

Du kan återställa det tidigare beteendet genom att ange System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod egenskapen till AlwaysBlock.

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Globalisering

Unicode-standardversion 8.0-kategorier stöds nu

Detaljer

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-stavelser och tecken och tonmärken för New Tai Lue-vokaler.

Förslag

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

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Säkerhet

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

Detaljer

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 som inte begär SecurityPermissionFlag.UnmanagedCode-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.

Namn Värde
Omfång Kant
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

RSACng.VerifyHash returnerar nu False för eventuella verifieringsfel

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

SignedXml och EncryptedXml – brytande ändringar

Detaljer

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.
  • Varje program som använder frånkopplade signaturer för externa resurser kan inte använda dem.

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.

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Windows Communication Foundation (WCF)

Ta bort Ssl3 från WCF TransportDefaults

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Windows Presentation Foundation (WPF)

Om du ändrar egenskapen IsEnabled för föräldrakontrollen till en TextBlock-kontroll, påverkas alla underordnade kontroller.

Detaljer

Från och med .NET Framework 4.6.2 innebär att ändra System.Windows.UIElement.IsEnabled egenskapen för den överordnade System.Windows.Controls.TextBlock kontrollen att alla underordnade kontroller (såsom hyperlänkar och knappar) för System.Windows.Controls.TextBlock kontrollen påverkas. 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 hos den System.Windows.Controls.TextBlock överordnade kontrollen.

Förslag

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

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

TvingaÄrMarkeringBoxMarkerad

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4,6
Typ Körningstid

Berörda API:er

DataGridCellsPanel.BringIndexIntoView genererar ArgumentOutOfRangeException

Detaljer

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

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.
Namn Värde
Omfång Kant
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Vågrät rullning och virtualisering

Detaljer

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 förskjutning och anropar SetHorizontalOffset(Double).

Efter att ha rullat till den nya förskjutningen kan betydelsen av "här" eller "höger kant" ha förändrats eftersom det nyligen avvirtualiserade innehållet har ändrat värdet på System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

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 att "studsa" rullningstummen, vilket bäst illustreras med ett exempel. Anta att en System.Windows.Controls.DataGrid har ExtentWidth=1000 och Width=200. En rullning till "högerkant" använder en kandidatförskjutning på 1000 - 200 = 800. När du scrollar till den offseten tas nya kolumner bort virtuellt, och låt oss anta att de är mycket breda, så att System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth ändras till 2000. Rullningen slutar med HorizontalOffset=800, och tummen "studsar" tillbaka till nära mitten av rullningslisten - exakt vid 800/2000 = 40%.

Ändringen innebär att beräkna om en ny kandidatförskjutning när denna situation uppstår, och sedan 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 predikterat värde för System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset bör ändras så att den hämtar det faktiska värdet (och värdet för System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) efter en vågrät rullning som kan påverka System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth på grund av avvirtualisering.

Namn Värde
Omfång Underårig
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Items.Clear tar inte bort dubbletter från SelectedItems

Detaljer

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.

Namn Värde
Omfång Underårig
Utgåva 4,5
Typ Körningstid

Berörda API:er

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

Detaljer

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 vid pixelrullning (ScrollUnit=Pixel) när ett objekt med annan pixelhöjd påträffas, och vid objektrullning av hierarkiska data, till exempel en System.Windows.Controls.TreeView eller en System.Windows.Controls.ItemsControl med aktiverad gruppering, när ett objekt med ett annat antal underordnade objekt än dess grannar visas. För fall med objektrullning och olika 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äga att om System.Windows.Controls.ItemsControl-objektet scrollar en enkel 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.
Namn Värde
Omfång Underårig
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

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

Detaljer

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

Namn Värde
Omfång Kant
Utgåva 4.6.2
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.

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

Detaljer

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.

Namn Värde
Omfång Kant
Utgåva 4.6.1
Typ Körningstid

Berörda API:er

Går inte att identifiera via API-analys.