Dela via

Core .NET-bibliotek som bryter ändringar i .NET Core 1.0-3.0

  • Artikel

Kärnbiblioteken för .NET tillhandahåller primitiver och andra allmänna typer som används av .NET Core.

Följande icke-bakåtkompatibla ändringar dokumenteras på den här sidan:

Icke-bakåtkompatibel ändring Version introducerad
Att skicka GroupCollection till tilläggsmetoder som tar IEnumerable<T> kräver tvetydighet .NET Core 3.0
API:er som rapportversionen nu rapporterar produkt och inte filversion .NET Core 3.0
Anpassade EncoderFallbackBuffer-instanser kan inte rekursivt falla tillbaka .NET Core 3.0
Ändring av flyttalsformatering och parsningsbeteende .NET Core 3.0
Flyttalsparsningsåtgärder misslyckas inte längre eller utlöser en OverflowException .NET Core 3.0
InvalidAsynchronousStateException har flyttats till en annan sammansättning .NET Core 3.0
Ersätta illa utformade UTF-8 byte-sekvenser följer Unicode-riktlinjerna .NET Core 3.0
TypeDescriptionProviderAttribute har flyttats till en annan sammansättning .NET Core 3.0
ZipArchiveEntry hanterar inte längre arkiv med inkonsekventa inmatningsstorlekar .NET Core 3.0
FieldInfo.SetValue genererar undantag för statiska fält med endast init .NET Core 3.0
Sökvägs-API:er utlöser inte ett undantag för ogiltiga tecken .NET Core 2.1
Privata fält har lagts till i inbyggda structtyper .NET Core 2.1
Ändra standardvärdet för UseShellExecute .NET Core 2.1
OpenSSL-versioner på macOS .NET Core 2.1
UnauthorizedAccessException genereras av FileSystemInfo.Attributes .NET Core 1.0
Hantering av undantag för skadat processtillstånd stöds inte .NET Core 1.0
UriBuilder-egenskaper förbereder inte längre inledande tecken .NET Core 1.0
Process.StartInfo genererar InvalidOperationException för processer som du inte startade .NET Core 1.0

.NET Core 3.0

Att skicka GroupCollection till tilläggsmetoder som tar IEnumerable<T> kräver tvetydighet

När du anropar en tilläggsmetod som använder IEnumerable<T> en GroupCollectionmåste du skilja typen från med hjälp av en gjuten fil.

Ändra beskrivning

Från och med .NET Core 3.0 System.Text.RegularExpressions.GroupCollection implementeras IEnumerable<KeyValuePair<String,Group>> utöver de andra typerna som implementeras, inklusive IEnumerable<Group>. Detta resulterar i tvetydighet när du anropar en tilläggsmetod som tar en IEnumerable<T>. Om du till exempel Enumerable.Countanropar en sådan tilläggsmetod på en GroupCollection instans visas följande kompilatorfel:

CS1061: "GroupCollection" innehåller inte någon definition för "Count" och ingen tillgänglig tilläggsmetod "Count" som accepterar ett första argument av typen "GroupCollection" kunde hittas (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

I tidigare versioner av .NET fanns det ingen tvetydighet och inget kompilatorfel.

Version introducerad

3,0

Orsak till ändringen

Detta var en oavsiktlig icke-bakåtkompatibel förändring. Eftersom det har varit så här under en tid planerar vi inte att återställa det. Dessutom skulle en sådan förändring i sig vara banbrytande.

Till GroupCollection exempel, tvetydiga anrop till tilläggsmetoder som accepterar en IEnumerable<T> med en cast.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Kategori

Core .NET-bibliotek

Berörda API:er

Alla tilläggsmetoder som accepterar en IEnumerable<T> påverkas. Till exempel:

API:er som rapportversionen nu rapporterar produkt och inte filversion

Många av de API:er som returnerar versioner i .NET Core returnerar nu produktversionen i stället för filversionen.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner återspeglar metoder som Environment.Version, RuntimeInformation.FrameworkDescriptionoch dialogrutan filegenskaper för .NET Core-sammansättningar filversionen. Från och med .NET Core 3.0 återspeglar de produktversionen.

Följande bild illustrerar skillnaden i versionsinformation för System.Runtime.dll sammansättning för .NET Core 2.2 (till vänster) och .NET Core 3.0 (till höger) som visas i dialogrutan Filegenskaper för Utforskaren i Windows.

Difference in product version information

Version introducerad

3,0

Inga. Den här ändringen bör göra versionsidentifiering intuitiv i stället för obtuse.

Kategori

Core .NET-bibliotek

Berörda API:er

Anpassade EncoderFallbackBuffer-instanser kan inte rekursivt falla tillbaka

Anpassade EncoderFallbackBuffer instanser kan inte falla tillbaka rekursivt. Implementeringen av EncoderFallbackBuffer.GetNextChar() måste resultera i en teckensekvens som kan konverteras till målkodningen. Annars inträffar ett undantag.

Ändra beskrivning

Under en transkodningsåtgärd mellan tecken och byte identifierar körningen felaktiga eller icke-konvertible UTF-16-sekvenser och tillhandahåller dessa tecken till EncoderFallbackBuffer.Fallback metoden. Metoden Fallback avgör vilka tecken som ska ersättas med de ursprungliga icke-konvertible data och dessa tecken töms genom att anropa EncoderFallbackBuffer.GetNextChar i en loop.

Körningen försöker sedan omkoda dessa ersättningstecken till målkodningen. Om den här åtgärden lyckas fortsätter körningen att omkodas från den plats där den slutade i den ursprungliga indatasträngen.

Tidigare kan anpassade implementeringar av EncoderFallbackBuffer.GetNextChar() returnera teckensekvenser som inte kan konverteras till målkodningen. Om de ersatta tecknen inte kan omkodas till målkodningen anropar körningen EncoderFallbackBuffer.Fallback metoden igen med ersättningstecken och förväntar sig EncoderFallbackBuffer.GetNextChar() att metoden returnerar en ny ersättningssekvens. Den här processen fortsätter tills körningen slutligen ser en välformulerad, konvertibel ersättning eller tills ett maximalt antal rekursioner har uppnåtts.

Från och med .NET Core 3.0 måste anpassade implementeringar av EncoderFallbackBuffer.GetNextChar() returnera teckensekvenser som kan konverteras till målkodningen. Om de ersatta tecknen inte kan omkodas till målkodningen genereras en ArgumentException . Körningen gör inte längre rekursiva anrop till instansen EncoderFallbackBuffer .

Det här beteendet gäller endast när alla tre av följande villkor uppfylls:

  • Körningen identifierar en felaktig UTF-16-sekvens eller en UTF-16-sekvens som inte kan konverteras till målkodningen.
  • En anpassad EncoderFallback har angetts.
  • De anpassade EncoderFallback försöken att ersätta en ny felaktig eller icke-konverterbar UTF-16-sekvens.

Version introducerad

3,0

De flesta utvecklare behöver inte vidta några åtgärder.

Om ett program använder en anpassad EncoderFallback och EncoderFallbackBuffer klass kontrollerar du att implementeringen av EncoderFallbackBuffer.Fallback fyller reservbufferten med välformulerade UTF-16-data som är direkt konvertibla till målkodningen när Fallback metoden först anropas av körningen.

Kategori

Core .NET-bibliotek

Berörda API:er

Flyttalsformatering och parsningsbeteende har ändrats

Flyttalsparsning och formateringsbeteende (efter typer) Double Single är nu IEEE-kompatibla. Detta säkerställer att beteendet för flyttalstyper i .NET matchar andra IEEE-kompatibla språk. Ska till exempel double.Parse("SomeLiteral") alltid matcha vad C# producerar för double x = SomeLiteral.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner formaterar du med Double.ToString och Single.ToString, och parsar med Double.Parse, Double.TryParse, Single.Parseoch Single.TryParse är inte IEEE-kompatibla. Därför är det omöjligt att garantera att ett värde tur och retur med någon standard- eller anpassad formatsträng som stöds. För vissa indata kan försöket att parsa ett formaterat värde misslyckas, och för andra är det parsade värdet inte lika med det ursprungliga värdet.

Från och med .NET Core 3.0 är flyttalsparsning och formateringsåtgärder IEEE 754-kompatibla.

I följande tabell visas två kodfragment och hur utdata ändras mellan .NET Core 2.2 och .NET Core 3.1.

Kodstycke Utdata på .NET Core 2.2 Utdata på .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0–
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Mer information finns i förbättringarna av flyttalsparsning och formatering i blogginlägget .NET Core 3.0 .

Version introducerad

3,0

Avsnittet Potentiell påverkan på befintlig kod i förbättringarna av flyttalsparsning och formatering i blogginlägget .NET Core 3.0 föreslår vissa ändringar som du kan göra i koden om du vill behålla det tidigare beteendet.

  • För vissa skillnader i formatering kan du få ett beteende som motsvarar det tidigare beteendet genom att ange en annan formatsträng.
  • För skillnader i parsning finns det ingen mekanism för att återgå till det tidigare beteendet.

Kategori

Core .NET-bibliotek

Berörda API:er

Flyttalsparsningsåtgärder misslyckas inte längre eller utlöser en OverflowException

De flyttalsparsningsmetoderna genererar inte längre en OverflowException eller returnerar false när de parsar en sträng vars numeriska värde ligger utanför intervallet Single för eller Double flyttalstypen.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner Double.Parse genererar metoderna och Single.Parse en OverflowException för värden som ligger utanför intervallet för respektive typ. Metoderna Double.TryParse och Single.TryParse returnerar false för strängrepresentationer av numeriska värden som inte ligger inom intervallet.

Från och med .NET Core 3.0 Double.Parsemisslyckas inte längre metoderna , Double.TryParse, Single.Parseoch Single.TryParse när du parsar numeriska strängar som inte är inom intervallet. Double I stället returnerar Double.PositiveInfinity parsningsmetoderna för värden som överskrider Double.MaxValue, och de returnerar Double.NegativeInfinity för värden som är mindre än Double.MinValue. På samma sätt returnerar parsningsmetoderna Single för värden som överskrider Single.MaxValue, och de returnerar Single.NegativeInfinity för värden som är mindre än Single.MinValue.Single.PositiveInfinity

Den här ändringen gjordes för förbättrad IEEE 754:2008-efterlevnad.

Version introducerad

3,0

Den här ändringen kan påverka koden på något av två sätt:

  • Din kod är beroende av hanteraren för OverflowException att köra när ett spill uppstår. I det här fallet bör du ta bort -instruktionen catch och placera nödvändig kod i en If -instruktion som testar om Double.IsInfinity eller Single.IsInfinity är true.

  • Koden förutsätter att flyttalsvärdena inte Infinityär . I det här fallet bör du lägga till nödvändig kod för att söka efter flyttalsvärden PositiveInfinity för och NegativeInfinity.

Kategori

Core .NET-bibliotek

Berörda API:er

InvalidAsynchronousStateException har flyttats till en annan sammansättning

Klassen InvalidAsynchronousStateException har flyttats.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner InvalidAsynchronousStateException finns klassen i sammansättningen System.ComponentModel.TypeConverter .

Från och med .NET Core 3.0 finns den i sammansättningen System.ComponentModel.Primitives .

Version introducerad

3,0

Den här ändringen påverkar endast program som använder reflektion för att läsa in InvalidAsynchronousStateException genom att anropa en metod, till exempel Assembly.GetType eller en överlagring av Activator.CreateInstance som förutsätter att typen finns i en viss sammansättning. I så fall uppdaterar du sammansättningen som refereras i metodanropet så att den återspeglar typens nya sammansättningsplats.

Kategori

Core .NET-bibliotek

Berörda API:er

Inga.

Ersätta illa utformade UTF-8 byte-sekvenser följer Unicode-riktlinjerna

UTF8Encoding När klassen stöter på en illa utformad UTF-8 byte-sekvens under en byte-till-tecken-transkodningsåtgärd ersätter den sekvensen med tecknet U+FFFD REPLACEMENT CHARACTER i utdatasträngen. .NET Core 3.0 skiljer sig från tidigare versioner av .NET Core och .NET Framework genom att följa unicode-metoden för att utföra den här ersättningen under omkodningsåtgärden.

Detta är en del av ett större arbete för att förbättra UTF-8-hanteringen i hela .NET, inklusive av de nya System.Text.Unicode.Utf8 och System.Text.Rune typerna. Typen UTF8Encoding fick förbättrad felhanteringsmekanik så att den ger utdata som överensstämmer med de nyligen introducerade typerna.

Ändra beskrivning

Från och med .NET Core 3.0, när byte överkodas till tecken, UTF8Encoding utför klassen teckenersättning baserat på Metodtips för Unicode. Ersättningsmekanismen som används beskrivs av Unicode Standard, version 12.0, s. 3.9 (PDF) i rubriken U+FFFD Substitution of Maximal Subparts.

Det här beteendet gäller endast när indatabytesekvensen innehåller oformaterad UTF-8-data. Om instansen UTF8Encoding har konstruerats med throwOnInvalidBytes: truefortsätter instansen UTF8Encoding dessutom att generera ogiltiga indata i stället för att utföra U+FFFD-ersättning. Mer information om konstruktorn finns i UTF8Encoding UTF8Encoding(Boolean, Boolean).

I följande tabell visas effekten av den här ändringen med ogiltiga indata på 3 byte:

Felaktig 3-bytesinmatning Utdata före .NET Core 3.0 Utdata som börjar med .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (utdata med 2 tecken) [ FFFD FFFD FFFD ] (utdata med 3 tecken)

3-teckensutdata är de önskade utdata, enligt tabell 3-9 i den tidigare länkade Unicode Standard PDF.

Version introducerad

3,0

Ingen åtgärd krävs från utvecklarens sida.

Kategori

Core .NET-bibliotek

Berörda API:er

TypeDescriptionProviderAttribute har flyttats till en annan sammansättning

Klassen TypeDescriptionProviderAttribute har flyttats.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner TypeDescriptionProviderAttribute finns klassen i sammansättningen System.ComponentModel.TypeConverter .

Från och med .NET Core 3.0 finns den i sammansättningen System.ObjectModel .

Version introducerad

3,0

Den här ändringen påverkar endast program som använder reflektion för att läsa in TypeDescriptionProviderAttribute typen genom att anropa en metod, till exempel Assembly.GetType eller en överlagring av Activator.CreateInstance som förutsätter att typen finns i en viss sammansättning. I så fall bör sammansättningen som refereras i metodanropet uppdateras för att återspegla typens nya sammansättningsplats.

Kategori

Windows Forms

Berörda API:er

Inga.

ZipArchiveEntry hanterar inte längre arkiv med inkonsekventa inmatningsstorlekar

Zip-arkiv visar både komprimerad storlek och okomprimerad storlek i den centrala katalogen och det lokala huvudet. Själva inmatningsdata anger också dess storlek. I .NET Core 2.2 och tidigare versioner kontrollerades aldrig dessa värden för konsekvens. Från och med .NET Core 3.0 är de nu det.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner ZipArchiveEntry.Open() lyckas även om det lokala huvudet inte håller med det centrala huvudet i zip-filen. Data dekomprimeras tills slutet av den komprimerade dataströmmen har nåtts, även om dess längd överskrider den okomprimerade filstorleken som anges i den centrala katalogen/det lokala huvudet.

Från och med .NET Core 3.0 ZipArchiveEntry.Open() kontrollerar metoden att det lokala huvudet och det centrala huvudet är överens om komprimerade och okomprimerade storlekar på en post. Om de inte gör det genererar metoden en InvalidDataException om-arkivets lokala huvud- och/eller databeskrivningsliststorlekar som inte överensstämmer med zip-filens centrala katalog. När du läser en post trunkeras dekomprimerade data till den okomprimerade filstorlek som anges i rubriken.

Den här ändringen gjordes för att säkerställa att en ZipArchiveEntry korrekt representerar storleken på dess data och att endast den mängden data läss.

Version introducerad

3,0

Packa om alla zip-arkiv som uppvisar dessa problem.

Kategori

Core .NET-bibliotek

Berörda API:er

FieldInfo.SetValue genererar undantag för statiska fält med endast init

Från och med .NET Core 3.0 utlöses ett undantag när du försöker ange ett värde för ett statiskt InitOnly fält genom att anropa System.Reflection.FieldInfo.SetValue.

Ändra beskrivning

I .NET Framework och versioner av .NET Core före 3.0 kan du ange värdet för ett statiskt fält som är konstant när det har initierats (skrivskyddat i C#) genom att anropa System.Reflection.FieldInfo.SetValue. Att ange ett sådant fält på det här sättet resulterade dock i oförutsägbart beteende baserat på målramverket och optimeringsinställningarna.

När du anropar SetValue ett statiskt InitOnly fält i .NET Core 3.0 och senare versioner genereras ett System.FieldAccessException undantag.

Dricks

Ett InitOnly fält är ett fält som bara kan anges när det deklareras eller i konstruktorn för den innehållande klassen. Med andra ord är den konstant när den har initierats.

Version introducerad

3,0

Initiera statiska InitOnly fält i en statisk konstruktor. Detta gäller både dynamiska och icke-dynamiska typer.

Du kan också ta bort FieldAttributes.InitOnly attributet från fältet och sedan anropa FieldInfo.SetValue.

Kategori

Core .NET-bibliotek

Berörda API:er

.NET Core 2.1

Sökvägs-API:er utlöser inte ett undantag för ogiltiga tecken

API:er som omfattar filsökvägar validerar inte längre sökvägstecken eller genererar ett ArgumentException om ett ogiltigt tecken hittas.

Ändra beskrivning

I .NET Framework och .NET Core 1.0–2.0 genererar metoderna i avsnittet Berörda API:er ett ArgumentException om sökvägsargumentet innehåller ett ogiltigt sökvägstecken. Från och med .NET Core 2.1 söker dessa metoder inte längre efter ogiltiga sökvägstecken eller utlöser ett undantag om ett ogiltigt tecken hittas.

Orsak till ändringen

Aggressiv validering av sökvägstecken blockerar vissa plattformsoberoende scenarier. Den här ändringen infördes så att .NET inte försöker replikera eller förutsäga resultatet av operativsystemets API-anrop. Mer information finns i blogginlägget System.IO i .NET Core 2.1.

Version introducerad

.NET Core 2.1

Om koden förlitade sig på dessa API:er för att söka efter ogiltiga tecken kan du lägga till ett anrop till Path.GetInvalidPathChars.

Berörda API:er

Se även

Privata fält har lagts till i inbyggda structtyper

Privata fält lades till i vissa structtyper i referenssammansättningar. Därför måste dessa structtyper i C# alltid instansieras med hjälp av den nya operatorn eller standardliteralen.

Ändra beskrivning

I .NET Core 2.0 och tidigare versioner kan vissa tillhandahållna structtyper, till exempel ConsoleKeyInfo, instansieras utan att använda operatorn new eller standardliteralen i C#. Det berodde på att referenssammansättningarna som användes av C#-kompilatorn inte innehöll de privata fälten för structs. Alla privata fält för .NET-structtyper läggs till i referenssammansättningarna med början i .NET Core 2.1.

Följande C#-kod kompileras till exempel i .NET Core 2.0, men inte i .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

I .NET Core 2.1 resulterar den tidigare koden i följande kompilatorfel: CS0165 – Användning av den otilldelade lokala variabeln "nyckel"

Version introducerad

2.1

Instansiera structtyper med hjälp av operatorn new eller standardliteralen.

Till exempel:

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

Kategori

Core .NET-bibliotek

Berörda API:er

Ändra standardvärdet för UseShellExecute

ProcessStartInfo.UseShellExecute har ett standardvärde false på på .NET Core. På .NET Framework är truestandardvärdet .

Ändra beskrivning

Process.Start låter dig starta ett program direkt, till exempel med kod som den som Process.Start("mspaint.exe") startar Paint. Du kan också indirekt starta ett associerat program om ProcessStartInfo.UseShellExecute det är inställt på true. På .NET Framework är standardvärdet för ProcessStartInfo.UseShellExecute , vilket innebär att kod som Process.Start("mytextfile.txt") startar Anteckningar, om du har associerat .txt filer med redigeraren.true Om du vill förhindra att en app startas indirekt på .NET Framework måste du uttryckligen ange ProcessStartInfo.UseShellExecute till false. På .NET Core är falsestandardvärdet för ProcessStartInfo.UseShellExecute . Det innebär att associerade program som standard inte startas när du anropar Process.Start.

Följande egenskaper på System.Diagnostics.ProcessStartInfo fungerar bara när ProcessStartInfo.UseShellExecute är true:

Den här ändringen introducerades i .NET Core av prestandaskäl. Process.Start Används vanligtvis för att starta ett program direkt. Att starta en app direkt behöver inte omfatta Windows-gränssnittet och medföra den associerade prestandakostnaden. För att göra det här standardfallet snabbare ändrar .NET Core standardvärdet ProcessStartInfo.UseShellExecute till false. Du kan välja den långsammare sökvägen om du behöver den.

Version introducerad

2.1

Kommentar

I tidigare versioner av .NET Core UseShellExecute implementerades inte för Windows.

Om din app förlitar sig på det gamla beteendet anropar Process.Start(ProcessStartInfo) du med UseShellExecute inställt true på på ProcessStartInfo objektet.

Kategori

Core .NET-bibliotek

Berörda API:er

OpenSSL-versioner på macOS

.NET Core 3.0 och senare körningar på macOS föredrar nu OpenSSL 1.1.x-versioner till OpenSSL 1.0.x-versioner för typerna AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSslRSAOpenSsloch SafeEvpPKeyHandle .

.NET Core 2.1-körningen stöder nu OpenSSL 1.1.x-versioner, men föredrar fortfarande OpenSSL 1.0.x-versioner.

Ändra beskrivning

Tidigare använde .NET Core-körningen OpenSSL 1.0.x-versioner på macOS för typer som interagerar med OpenSSL. Den senaste OpenSSL 1.0.x-versionen, OpenSSL 1.0.2, har nu inte stöd. För att behålla typer som använder OpenSSL i versioner av OpenSSL som stöds använder .NET Core 3.0 och senare körningar nu nyare versioner av OpenSSL på macOS.

Med den här ändringen är beteendet för .NET Core-körningen på macOS följande:

  • Versionskörningarna för .NET Core 3.0 och senare använder OpenSSL 1.1.x, om det är tillgängligt, och återgår endast till OpenSSL 1.0.x om det inte finns någon 1.1.x-version tillgänglig.

    För uppringare som använder OpenSSL-interoptyperna med anpassade P/Invokes följer du riktlinjerna i SafeEvpPKeyHandle.OpenSslVersion kommentarerna. Din app kan krascha om du inte kontrollerar värdet OpenSslVersion .

  • .NET Core 2.1-körningen använder OpenSSL 1.0.x, om tillgängligt, och återgår till OpenSSL 1.1.x om det inte finns någon tillgänglig version på 1.0.x.

    2.1-körningen föredrar den tidigare versionen av OpenSSL eftersom SafeEvpPKeyHandle.OpenSslVersion egenskapen inte finns i .NET Core 2.1, så OpenSSL-versionen kan inte fastställas på ett tillförlitligt sätt vid körning.

Version introducerad

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

Kategori

Core .NET-bibliotek

Berörda API:er

.NET Core 1.0

UnauthorizedAccessException genereras av FileSystemInfo.Attributes

I .NET Core utlöses en UnauthorizedAccessException när anroparen försöker ange ett filattributvärde men inte har skrivbehörighet.

Ändra beskrivning

I .NET Framework utlöses en ArgumentException när anroparen försöker ange ett filattributvärde i FileSystemInfo.Attributes men inte har skrivbehörighet. I .NET Core genereras en UnauthorizedAccessException i stället. (I .NET Core utlöses fortfarande en ArgumentException om anroparen försöker ange ett ogiltigt filattribut.)

Version introducerad

1.0

Ändra eventuella catch instruktioner för att fånga en UnauthorizedAccessException i stället för, eller utöver, en ArgumentException, efter behov.

Kategori

Core .NET-bibliotek

Berörda API:er

Hantering av skadade tillståndsfel stöds inte

Det går inte att hantera feltillståndsfel i .NET Core.

Ändra beskrivning

Tidigare kunde undantag för skadat processtillstånd fångas upp och hanteras av hanterade kod undantagshanterare, till exempel med hjälp av en try-catch-instruktion i C#.

Från och med .NET Core 1.0 kan undantag för skadat processtillstånd inte hanteras av hanterad kod. Den vanliga språkkörningen levererar inte undantag för skadat processtillstånd till hanterad kod.

Version introducerad

1.0

Undvik behovet av att hantera undantag för skadade processer genom att ta itu med de situationer som leder till dem i stället. Om det är absolut nödvändigt att hantera undantag för skadat processtillstånd skriver du undantagshanteraren i C- eller C++-kod.

Kategori

Core .NET-bibliotek

Berörda API:er

UriBuilder-egenskaper förbereder inte längre inledande tecken

UriBuilder.Fragment förbereder inte längre ett ledande # tecken och UriBuilder.Query förbereder inte längre ett inledande ? tecken när ett redan finns.

Ändra beskrivning

I .NET Framework UriBuilder.Fragment förbereder egenskaperna och UriBuilder.Query alltid ett # eller ? -tecken till det värde som lagras. Det här beteendet kan resultera i flera # tecken eller ? tecken i det lagrade värdet om strängen redan innehåller något av dessa inledande tecken. Till exempel kan värdet för UriBuilder.Fragment bli ##main.

Från och med .NET Core 1.0 förbereder # dessa egenskaper inte längre tecknen eller ? till det lagrade värdet om det redan finns i början av strängen.

Version introducerad

1.0

Du behöver inte längre uttryckligen ta bort något av dessa inledande tecken när du anger egenskapsvärdena. Detta är särskilt användbart när du lägger till värden, eftersom du inte längre behöver ta bort inledande # eller ? varje gång du lägger till.

Följande kodfragment visar till exempel beteendeskillnaden mellan .NET Framework och .NET Core.

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • I .NET Framework är ????one=1&two=2&three=3&four=4utdata .
  • I .NET Core är ?one=1&two=2&three=3&four=4utdata .

Kategori

Core .NET-bibliotek

Berörda API:er

Process.StartInfo genererar InvalidOperationException för processer som du inte startade

När du Process.StartInfo läser egenskapen för processer som koden inte började genererar en InvalidOperationException.

Ändra beskrivning

I .NET Framework returnerar åtkomst till Process.StartInfo egenskapen för processer som koden inte startade ett dummy-objekt ProcessStartInfo . Dummy-objektet innehåller standardvärden för alla dess egenskaper utom EnvironmentVariables.

Från och med .NET Core 1.0, om du läser Process.StartInfo egenskapen för en process som du inte startade (dvs. genom att anropa Process.Start), genereras en InvalidOperationException .

Version introducerad

1.0

Kom inte åt egenskapen Process.StartInfo för processer som koden inte startade. Läs till exempel inte den här egenskapen för processer som returneras av Process.GetProcesses.

Kategori

Core .NET-bibliotek

Berörda API:er