Delen via

Core .NET-bibliotheken die wijzigingen veroorzaken in .NET Core 1.0-3.0

  • Artikel

De .NET-kernbibliotheken bieden de primitieven en andere algemene typen die worden gebruikt door .NET Core.

De volgende belangrijke wijzigingen worden op deze pagina beschreven:

Wijziging die fouten veroorzaken Versie geïntroduceerd
Het doorgeven van GroupCollection aan extensiemethoden die IEnumerable<T> gebruiken, vereist ondubbelzinnigheid .NET Core 3.0
API's die rapportversie nu rapporteren, rapporteren product en geen bestandsversie .NET Core 3.0
Custom EncoderFallbackBuffer-exemplaren kunnen niet recursief terugvallen .NET Core 3.0
Wijzigingen in drijvendekommaopmaak en parseringsgedrag .NET Core 3.0
Drijvendekommaparseerbewerkingen mislukken niet meer of gooien een OverflowException .NET Core 3.0
InvalidAsynchronousStateException is verplaatst naar een andere assembly .NET Core 3.0
Het vervangen van slecht gevormde UTF-8 bytereeksen volgt Unicode-richtlijnen .NET Core 3.0
TypeDescriptionProviderAttribute is verplaatst naar een andere assembly .NET Core 3.0
ZipArchiveEntry verwerkt geen archieven meer met inconsistente invoergrootten .NET Core 3.0
FieldInfo.SetValue genereert uitzondering voor statische, alleen-init-velden .NET Core 3.0
Pad-API's genereren geen uitzondering voor ongeldige tekens .NET Core 2.1
Privévelden toegevoegd aan ingebouwde structtypen .NET Core 2.1
De standaardwaarde van UseShellExecute wijzigen .NET Core 2.1
OpenSSL-versies in macOS .NET Core 2.1
UnauthorizedAccessException gegenereerd door FileSystemInfo.Attributes .NET Core 1.0
Het verwerken van beschadigde processtatus-uitzonderingen wordt niet ondersteund .NET Core 1.0
UriBuilder-eigenschappen bevatten geen voorlooptekens meer .NET Core 1.0
Process.StartInfo genereert InvalidOperationException voor processen die u niet hebt gestart .NET Core 1.0

.NET Core 3.0

Het doorgeven van GroupCollection aan extensiemethoden die IEnumerable<T> gebruiken, vereist ondubbelzinnigheid

Wanneer u een extensiemethode aanroept die een IEnumerable<T> op een GroupCollectionaanneemt, moet u het type ondubbelzinnig maken met behulp van een cast.

Wijzigingsbeschrijving

Vanaf .NET Core 3.0 worden System.Text.RegularExpressions.GroupCollection IEnumerable<KeyValuePair<String,Group>> naast de andere typen geïmplementeerd, waaronder IEnumerable<Group>. Dit resulteert in dubbelzinnigheid bij het aanroepen van een extensiemethode die een IEnumerable<T>. Als u een dergelijke extensiemethode op een GroupCollection exemplaar aanroept, Enumerable.Countziet u bijvoorbeeld de volgende compilerfout:

CS1061: 'GroupCollection' bevat geen definitie voor 'Count' en geen toegankelijke uitbreidingsmethode 'Count' die een eerste argument van het type GroupCollection accepteert (ontbreekt er een using-instructie of een assemblyverwijzing?)

In eerdere versies van .NET was er geen dubbelzinnigheid en geen compilerfout.

Versie geïntroduceerd

3,0

Reden voor wijziging

Dit was een onbedoelde wijziging die fouten veroorzaken. Omdat het al een tijdje zo is, zijn we niet van plan om het terug te keren. Bovendien zou een dergelijke wijziging zelf breken.

Zo GroupCollection kunt u aanroepen naar extensiemethoden die een IEnumerable<T> met een cast accepteren, niet eenduidig maken.

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

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

Categorie

Core .NET-bibliotheken

Betrokken API's

Elke extensiemethode die een IEnumerable<T> accepteert, wordt beïnvloed. Voorbeeld:

API's die rapportversie nu rapporteren, rapporteren product en geen bestandsversie

Veel van de API's die versies retourneren in .NET Core retourneren, retourneren nu de productversie in plaats van de bestandsversie.

Wijzigingsbeschrijving

In .NET Core 2.2 en vorige versies geven methoden zoals Environment.Version, RuntimeInformation.FrameworkDescriptionen het dialoogvenster bestandseigenschappen voor .NET Core-assembly's de bestandsversie weer. Vanaf .NET Core 3.0 weerspiegelen ze de productversie.

In de volgende afbeelding ziet u het verschil in versie-informatie voor de System.Runtime.dll assembly voor .NET Core 2.2 (aan de linkerkant) en .NET Core 3.0 (aan de rechterkant) zoals weergegeven in het dialoogvenster bestandseigenschappen van Windows Verkenner.

Difference in product version information

Versie geïntroduceerd

3,0

Geen. Deze wijziging moet versiedetectie intuïtief maken in plaats van obtuse.

Categorie

Core .NET-bibliotheken

Betrokken API's

Custom EncoderFallbackBuffer-exemplaren kunnen niet recursief terugvallen

Aangepaste EncoderFallbackBuffer exemplaren kunnen niet recursief terugvallen. De implementatie van EncoderFallbackBuffer.GetNextChar() moet resulteren in een tekenreeks die converteert naar de doelcodering. Anders treedt er een uitzondering op.

Wijzigingsbeschrijving

Tijdens een transcoderingsbewerking voor teken-naar-byte detecteert de runtime ongeldige of niet-converteerbare UTF-16-reeksen en geeft deze tekens aan de EncoderFallbackBuffer.Fallback methode. De Fallback methode bepaalt welke tekens moeten worden vervangen door de oorspronkelijke niet-converteerbare gegevens en deze tekens worden leeggezogen door een lus aan te roepen EncoderFallbackBuffer.GetNextChar .

De runtime probeert deze vervangende tekens vervolgens te transcoderen naar de doelcodering. Als deze bewerking slaagt, gaat de runtime door met transcodering vanaf waar deze is gebleven in de oorspronkelijke invoertekenreeks.

Voorheen kunnen aangepaste implementaties van EncoderFallbackBuffer.GetNextChar() tekenreeksen die niet converteerbaar zijn naar de doelcodering, retourneren. Als de vervangen tekens niet kunnen worden getranscodeerd naar de doelcodering, roept de runtime de EncoderFallbackBuffer.Fallback methode opnieuw aan met de vervangingstekens, waarbij wordt verwacht dat de EncoderFallbackBuffer.GetNextChar() methode een nieuwe vervangingsreeks retourneert. Dit proces gaat door totdat de runtime uiteindelijk een goed gevormde, converteerbare vervanging ziet of totdat een maximumaantal recursies is bereikt.

Vanaf .NET Core 3.0 moeten aangepaste implementaties van EncoderFallbackBuffer.GetNextChar() tekensreeksen retourneren die converteerbaar zijn naar de doelcodering. Als de vervangen tekens niet kunnen worden getranscodeerd naar de doelcodering, wordt er een ArgumentException gegenereerd. De runtime maakt geen recursieve aanroepen meer naar het EncoderFallbackBuffer exemplaar.

Dit gedrag is alleen van toepassing wanneer aan alle drie de volgende voorwaarden wordt voldaan:

  • De runtime detecteert een ongeldige UTF-16-reeks of een UTF-16-reeks die niet kan worden geconverteerd naar de doelcodering.
  • Er is een aangepaste waarde EncoderFallback opgegeven.
  • De aangepaste pogingen om een nieuwe niet-gevormde of niet-onvertibele EncoderFallback UTF-16-reeks te vervangen.

Versie geïntroduceerd

3,0

De meeste ontwikkelaars hoeven geen actie te ondernemen.

Als een toepassing gebruikmaakt van een aangepaste EncoderFallback klasse EncoderFallbackBuffer , moet u ervoor zorgen dat de implementatie van EncoderFallbackBuffer.Fallback de terugvalbuffer wordt gevuld met goed gevormde UTF-16-gegevens die rechtstreeks worden omgezet in de doelcodering wanneer de methode voor het Fallback eerst wordt aangeroepen door de runtime.

Categorie

Core .NET-bibliotheken

Betrokken API's

Drijvende-kommaopmaak en parseringsgedrag gewijzigd

Drijvendekommaparsering en opmaakgedrag (door de Double en Single typen) zijn nu compatibel met IEEE. Dit zorgt ervoor dat het gedrag van typen drijvende komma's in .NET overeenkomt met die van andere IEEE-compatibele talen. Moet bijvoorbeeld double.Parse("SomeLiteral") altijd overeenkomen met waarvoor C# produceert double x = SomeLiteral.

Wijzigingsbeschrijving

In .NET Core 2.2 en eerdere versies zijn opmaak met Double.ToString en , en Single.ToStringparseren met Double.Parse, Double.TryParseen Single.ParseSingle.TryParse niet compatibel met IEEE. Als gevolg hiervan is het onmogelijk om te garanderen dat een waarde retourneert met een ondersteunde tekenreeks met een standaard- of aangepaste notatie. Voor sommige invoer kan de poging om een opgemaakte waarde te parseren mislukken. Voor andere invoer is de geparseerde waarde niet gelijk aan de oorspronkelijke waarde.

Vanaf .NET Core 3.0 zijn parserings- en opmaakbewerkingen met IEEE 754 compatibel.

In de volgende tabel ziet u twee codefragmenten en hoe de uitvoer verandert tussen .NET Core 2.2 en .NET Core 3.1.

Codefragment Uitvoer op .NET Core 2.2 Uitvoer op .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Zie de verbeteringen voor drijvende komma parseren en opmaken in het blogbericht .NET Core 3.0 voor meer informatie.

Versie geïntroduceerd

3,0

De mogelijke impact op de bestaande codesectie van de drijvendekommaparsering en opmaakverbeteringen in het blogbericht .NET Core 3.0 stelt enkele wijzigingen voor die u in uw code kunt aanbrengen als u het vorige gedrag wilt behouden.

  • Voor sommige verschillen in opmaak kunt u gedrag krijgen dat gelijk is aan het vorige gedrag door een andere notatietekenreeks op te geven.
  • Voor verschillen in parseren is er geen mechanisme om terug te vallen op het vorige gedrag.

Categorie

Core .NET-bibliotheken

Betrokken API's

Drijvendekommaparseerbewerkingen mislukken niet meer of gooien een OverflowException

De drijvendekommaparseermethoden genereren of OverflowException retourneren false niet langer wanneer ze een tekenreeks parseren waarvan de numerieke waarde buiten het bereik van het Single type Double drijvende komma valt.

Wijzigingsbeschrijving

In .NET Core 2.2 en eerdere versies gooien de Double.Parse en Single.Parse methoden een OverflowException waarde op voor waarden die buiten het bereik van hun respectieve type liggen. De Double.TryParse en Single.TryParse methoden retourneren de false tekenreeksweergaven van numerieke waarden buiten het bereik.

Vanaf .NET Core 3.0 mislukken de Double.Parse, Double.TryParseen Single.ParseSingle.TryParse methoden niet meer bij het parseren van numerieke tekenreeksen buiten het bereik. In plaats daarvan retourneren de Double parseringsmethoden voor waarden die groter zijn Double.MaxValuedan , en ze retourneren voor Double.NegativeInfinity waarden die kleiner zijn dan Double.MinValue.Double.PositiveInfinity Op dezelfde manier retourneren de Single parseringsmethoden voor waarden die groter zijn dan Single.MaxValueen ze retourneren voor Single.NegativeInfinity waarden die kleiner zijn dan Single.MinValue.Single.PositiveInfinity

Deze wijziging is aangebracht voor verbeterde naleving van IEEE 754:2008.

Versie geïntroduceerd

3,0

Deze wijziging kan op twee manieren van invloed zijn op uw code:

  • Uw code is afhankelijk van de handler die moet OverflowException worden uitgevoerd wanneer er een overloop plaatsvindt. In dit geval moet u de catch instructie verwijderen en eventueel benodigde code plaatsen in een If instructie die test of Double.IsInfinity Single.IsInfinity is true.

  • In uw code wordt ervan uitgegaan dat drijvendekommawaarden niet Infinityzijn. In dit geval moet u de benodigde code toevoegen om te controleren op drijvende-kommawaarden van PositiveInfinity en NegativeInfinity.

Categorie

Core .NET-bibliotheken

Betrokken API's

InvalidAsynchronousStateException is verplaatst naar een andere assembly

De InvalidAsynchronousStateException klas is verplaatst.

Wijzigingsbeschrijving

In .NET Core 2.2 en eerdere versies vindt u de InvalidAsynchronousStateException klasse in de assembly System.ComponentModel.TypeConverter .

Vanaf .NET Core 3.0 vindt u deze in de assembly System.ComponentModel.Primitives .

Versie geïntroduceerd

3,0

Deze wijziging is alleen van invloed op toepassingen die gebruikmaken van weerspiegeling om de InvalidAsynchronousStateException belasting aan te brengen door een methode aan te roepen, zoals Assembly.GetType of een overbelasting van Activator.CreateInstance die ervan uitgaat dat het type zich in een bepaalde assembly bevindt. Als dat het geval is, werkt u de assembly bij waarnaar wordt verwezen in de methode-aanroep om de nieuwe assemblylocatie van het type weer te geven.

Categorie

Core .NET-bibliotheken

Betrokken API's

Geen.

Het vervangen van slecht gevormde UTF-8 bytereeksen volgt Unicode-richtlijnen

Wanneer de UTF8Encoding klasse een slecht gevormdE UTF-8-bytereeks tegenkomt tijdens een transcoderingsbewerking van byte-naar-teken, wordt deze reeks vervangen door een '-teken (U+FFFD REPLACEMENT CHARACTER) in de uitvoertekenreeks. .NET Core 3.0 verschilt van eerdere versies van .NET Core en .NET Framework door de Unicode-best practice te volgen voor het uitvoeren van deze vervanging tijdens de transcoderingsbewerking.

Dit maakt deel uit van een grotere inspanning om de verwerking van UTF-8 in .NET te verbeteren, waaronder door de nieuwe System.Text.Unicode.Utf8 typen System.Text.Rune . Het UTF8Encoding type kreeg verbeterde mechanica voor foutafhandeling, zodat deze uitvoer consistent produceert met de nieuw geïntroduceerde typen.

Wijzigingsbeschrijving

Vanaf .NET Core 3.0 voert de UTF8Encoding klasse bij het transcoderingen van bytes naar tekens tekenvervanging uit op basis van de aanbevolen unicode-procedures. Het gebruikte vervangingsmechanisme wordt beschreven door de Unicode-standaard, versie 12.0, sec. 3.9 (PDF) in de kop met de titel U+FFFD Substitute of Maximal Subparts.

Dit gedrag is alleen van toepassing wanneer de invoer bytevolgorde ongeldige UTF-8-gegevens bevat. Als het UTF8Encoding exemplaar is samengesteld, throwOnInvalidBytes: trueblijft het UTF8Encoding exemplaar bovendien ongeldige invoer invoeren in plaats van U+FFFD-vervanging uit te voeren. Zie voor meer informatie over de UTF8Encoding constructor UTF8Encoding(Boolean, Boolean).

In de volgende tabel ziet u de impact van deze wijziging met een ongeldige invoer van 3 bytes:

Ziek gevormde 3-byteinvoer Uitvoer vóór .NET Core 3.0 Uitvoer vanaf .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (uitvoer van twee tekens) [ FFFD FFFD FFFD ] (Uitvoer van 3 tekens)

De uitvoer van 3 tekens is de voorkeursuitvoer, volgens tabel 3-9 van de eerder gekoppelde Unicode Standard PDF.

Versie geïntroduceerd

3,0

Er is geen actie vereist voor het deel van de ontwikkelaar.

Categorie

Core .NET-bibliotheken

Betrokken API's

TypeDescriptionProviderAttribute is verplaatst naar een andere assembly

De TypeDescriptionProviderAttribute klas is verplaatst.

Wijzigingsbeschrijving

In .NET Core 2.2 en eerdere versies vindt u de TypeDescriptionProviderAttribute klasse in de assembly System.ComponentModel.TypeConverter .

Vanaf .NET Core 3.0 vindt u deze in de System.ObjectModel-assembly .

Versie geïntroduceerd

3,0

Deze wijziging is alleen van invloed op toepassingen die gebruikmaken van weerspiegeling om het TypeDescriptionProviderAttribute type te laden door een methode aan te roepen, zoals Assembly.GetType of een overbelasting waarvan Activator.CreateInstance wordt uitgegaan dat het type zich in een bepaalde assembly bevindt. Als dat het geval is, moet de assembly waarnaar wordt verwezen in de methode-aanroep worden bijgewerkt om de nieuwe assemblylocatie van het type weer te geven.

Categorie

Windows Forms

Betrokken API's

Geen.

ZipArchiveEntry verwerkt geen archieven meer met inconsistente invoergrootten

Zip-archieven vermelden zowel gecomprimeerde grootte als niet-gecomprimeerde grootte in de centrale map en lokale header. De invoergegevens zelf geven ook de grootte aan. In .NET Core 2.2 en eerdere versies zijn deze waarden nooit gecontroleerd op consistentie. Vanaf .NET Core 3.0 zijn ze dat nu.

Wijzigingsbeschrijving

In .NET Core 2.2 en eerdere versies slaagt het zelfs ZipArchiveEntry.Open() als de lokale header het niet eens is met de centrale header van het zip-bestand. Gegevens worden gedecomprimeerd totdat het einde van de gecomprimeerde stroom is bereikt, zelfs als de lengte groter is dan de niet-gecomprimeerde bestandsgrootte die wordt vermeld in de centrale map/lokale header.

Vanaf .NET Core 3.0 controleert de methode of de ZipArchiveEntry.Open() lokale header en de centrale header overeenkomen met gecomprimeerde en niet-gecomprimeerde grootten van een vermelding. Als dat niet zo is, genereert de methode een InvalidDataException lijstgrootte van de lokale header en/of gegevensdescriptor van het archief die niet overeenkomen met de centrale map van het zip-bestand. Bij het lezen van een vermelding worden gedecomprimeerde gegevens afgekapt tot de niet-gecomprimeerde bestandsgrootte die wordt vermeld in de koptekst.

Deze wijziging is aangebracht om ervoor te zorgen dat de ZipArchiveEntry grootte van de gegevens correct wordt aangegeven en dat alleen die hoeveelheid gegevens wordt gelezen.

Versie geïntroduceerd

3,0

Pak een zip-archief opnieuw dat deze problemen vertoont.

Categorie

Core .NET-bibliotheken

Betrokken API's

FieldInfo.SetValue genereert uitzondering voor statische, alleen-init-velden

Vanaf .NET Core 3.0 wordt er een uitzondering gegenereerd wanneer u probeert een waarde in te stellen voor een statisch InitOnly veld door aan te roepen System.Reflection.FieldInfo.SetValue.

Wijzigingsbeschrijving

In .NET Framework en versies van .NET Core vóór 3.0 kunt u de waarde instellen van een statisch veld dat constant is nadat het is geïnitialiseerd (gelezen in C#) door aan te roepen System.Reflection.FieldInfo.SetValue. Het instellen van een dergelijk veld op deze manier resulteerde echter in onvoorspelbaar gedrag op basis van het doelframework en optimalisatie-instellingen.

In .NET Core 3.0 en latere versies wordt er een System.FieldAccessException uitzondering gegenereerd wanneer u een statisch InitOnly veld aanroeptSetValue.

Tip

Een InitOnly veld is een veld dat alleen kan worden ingesteld op het moment dat het wordt gedeclareerd of in de constructor voor de betreffende klasse. Met andere woorden, het is constant nadat deze is geïnitialiseerd.

Versie geïntroduceerd

3,0

Initialiseer statische velden InitOnly in een statische constructor. Dit geldt zowel voor dynamische als niet-dynamische typen.

U kunt het FieldAttributes.InitOnly kenmerk ook verwijderen uit het veld en vervolgens aanroepen FieldInfo.SetValue.

Categorie

Core .NET-bibliotheken

Betrokken API's

.NET Core 2.1

Pad-API's genereren geen uitzondering voor ongeldige tekens

API's waarbij bestandspaden worden gebruikt, valideren geen padtekens meer of genereert een ArgumentException ongeldig teken als er een ongeldig teken wordt gevonden.

Wijzigingsbeschrijving

In .NET Framework en .NET Core 1.0 - 2.0 worden de methoden die worden vermeld in de sectie Betreffende API's , een ArgumentException als het padargument een ongeldig padteken bevat. Vanaf .NET Core 2.1 controleren deze methoden niet langer op ongeldige padtekens of genereert u een uitzondering als er een ongeldig teken wordt gevonden.

Reden voor wijziging

Agressieve validatie van padtekens blokkeert enkele platformoverschrijdende scenario's. Deze wijziging is geïntroduceerd, zodat .NET niet probeert het resultaat van API-aanroepen van het besturingssysteem te repliceren of voorspellen. Zie de System.IO in .NET Core 2.1 sneak peek blogpost voor meer informatie.

Versie geïntroduceerd

.NET Core 2.1

Als uw code afhankelijk is van deze API's om te controleren op ongeldige tekens, kunt u een aanroep toevoegen aan Path.GetInvalidPathChars.

Betrokken API's

Zie ook

Privévelden toegevoegd aan ingebouwde structtypen

Privévelden zijn toegevoegd aan bepaalde structtypen in referentieassembly's. Als gevolg hiervan moeten deze structtypen in C# altijd worden geïnstantieerd met behulp van de nieuwe operator of de standaard letterlijke waarde.

Wijzigingsbeschrijving

In .NET Core 2.0 en vorige versies kunnen sommige structtypen, bijvoorbeeld, ConsoleKeyInfoworden geïnstantieerd zonder de operator of de new standaard letterlijke waarde in C# te gebruiken. Dit komt doordat de referentieassembly's die door de C#-compiler worden gebruikt, de privévelden voor de structs niet bevatten. Alle privévelden voor .NET-structtypen worden toegevoegd aan de referentieassembly's vanaf .NET Core 2.1.

De volgende C#-code compileert bijvoorbeeld in .NET Core 2.0, maar niet in .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

In .NET Core 2.1 resulteert de vorige code in de volgende compilerfout: CS0165 - Gebruik van niet-toegewezen lokale variabele 'sleutel'

Versie geïntroduceerd

2.1

Instantieer structtypen met behulp van de operator of de new standaard letterlijke waarde.

Voorbeeld:

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!");

Categorie

Core .NET-bibliotheken

Betrokken API's

De standaardwaarde van UseShellExecute wijzigen

ProcessStartInfo.UseShellExecute heeft een standaardwaarde van false .NET Core. In .NET Framework is de standaardwaarde .true

Wijzigingsbeschrijving

Process.Start hiermee kunt u een toepassing rechtstreeks starten, bijvoorbeeld met code zoals Process.Start("mspaint.exe") die Paint start. Hiermee kunt u ook indirect een gekoppelde toepassing starten als ProcessStartInfo.UseShellExecute deze is ingesteld op true. In .NET Framework is de standaardwaarde ProcessStartInfo.UseShellExecute voortrue, wat betekent dat code zoals Process.Start("mytextfile.txt") het starten van Kladblok, als u .txt bestanden aan die editor hebt gekoppeld. Als u wilt voorkomen dat een app indirect wordt gestart in .NET Framework, moet u expliciet instellen ProcessStartInfo.UseShellExecute op false. In .NET Core is de standaardwaarde voor ProcessStartInfo.UseShellExecute false. Dit betekent dat standaard gekoppelde toepassingen niet worden gestart wanneer u aanroept Process.Start.

De volgende eigenschappen System.Diagnostics.ProcessStartInfo zijn alleen functioneel wanneerProcessStartInfo.UseShellExecute:true

Deze wijziging is geïntroduceerd in .NET Core om prestatieredenen. Process.Start Normaal gesproken wordt gebruikt om een toepassing rechtstreeks te starten. Het starten van een app hoeft niet rechtstreeks de Windows-shell te omvatten en de bijbehorende prestatiekosten in rekening te brengen. Als u deze standaardcase sneller wilt maken, wijzigt .NET Core de standaardwaarde van ProcessStartInfo.UseShellExecute .false U kunt zich aanmelden voor het langzamere pad als u dit nodig hebt.

Versie geïntroduceerd

2.1

Notitie

In eerdere versies van .NET Core is UseShellExecute niet geïmplementeerd voor Windows.

Als uw app afhankelijk is van het oude gedrag, roept u de aanroep Process.Start(ProcessStartInfo) in op UseShellExecute true het ProcessStartInfo object.

Categorie

Core .NET-bibliotheken

Betrokken API's

OpenSSL-versies in macOS

De .NET Core 3.0- en hoger-runtimes op macOS geven nu de voorkeur aan OpenSSL 1.1.x-versies voor OpenSSL 1.0.x-versies voor de AesCcmtypen , , AesGcm, DSAOpenSslECDiffieHellmanOpenSsl, ECDsaOpenSslRSAOpenSslen SafeEvpPKeyHandle typen.

De .NET Core 2.1-runtime ondersteunt nu OpenSSL 1.1.x-versies, maar geeft nog steeds de voorkeur aan OpenSSL 1.0.x-versies.

Wijzigingsbeschrijving

Voorheen gebruikte de .NET Core-runtime OpenSSL 1.0.x-versies op macOS voor typen die communiceren met OpenSSL. De meest recente Versie van OpenSSL 1.0.x, OpenSSL 1.0.2, is nu niet meer ondersteund. Als u typen wilt behouden die Gebruikmaken van OpenSSL voor ondersteunde versies van OpenSSL, gebruiken de .NET Core 3.0- en latere runtimes nu nieuwere versies van OpenSSL op macOS.

Met deze wijziging is het gedrag voor de .NET Core-runtimes in macOS als volgt:

  • De runtimes van .NET Core 3.0 en hoger gebruiken OpenSSL 1.1.x, indien beschikbaar, en vallen alleen terug op OpenSSL 1.0.x als er geen 1.1.x-versie beschikbaar is.

    Voor bellers die gebruikmaken van de OpenSSL-interoptypen met aangepaste P/Invokes, volgt u de richtlijnen in de SafeEvpPKeyHandle.OpenSslVersion opmerkingen. Uw app loopt mogelijk vast als u de OpenSslVersion waarde niet controleert.

  • De .NET Core 2.1-runtime maakt gebruik van OpenSSL 1.0.x, indien beschikbaar, en valt terug op OpenSSL 1.1.x als er geen 1.0.x-versie beschikbaar is.

    De runtime 2.1 geeft de voorkeur aan de eerdere versie van OpenSSL, omdat de SafeEvpPKeyHandle.OpenSslVersion eigenschap niet bestaat in .NET Core 2.1, dus de OpenSSL-versie kan niet betrouwbaar worden bepaald tijdens runtime.

Versie geïntroduceerd

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

Categorie

Core .NET-bibliotheken

Betrokken API's

.NET Core 1.0

UnauthorizedAccessException gegenereerd door FileSystemInfo.Attributes

In .NET Core wordt er een UnauthorizedAccessException gegenereerd wanneer de aanroeper probeert een waarde voor het bestandskenmerk in te stellen, maar geen schrijfmachtiging heeft.

Wijzigingsbeschrijving

In .NET Framework wordt er een ArgumentException gegenereerd wanneer de aanroeper probeert een waarde voor het bestandskenmerk in FileSystemInfo.Attributes te stellen, maar geen schrijfmachtiging heeft. In .NET Core wordt er in plaats daarvan een UnauthorizedAccessException gegenereerd. (In .NET Core wordt er nog steeds een ArgumentException gegenereerd als de beller probeert een ongeldig bestandskenmerk in te stellen.)

Versie geïntroduceerd

1.0

Wijzig eventuele catch instructies om een UnauthorizedAccessException in plaats van, of naast, een ArgumentException, indien nodig, te ondervangen.

Categorie

Core .NET-bibliotheken

Betrokken API's

Het verwerken van beschadigde status-uitzonderingen wordt niet ondersteund

Het verwerken van beschadigde processtatus-uitzonderingen in .NET Core wordt niet ondersteund.

Wijzigingsbeschrijving

Voorheen konden beschadigde processtatusuitzonderingen worden opgevangen en verwerkt door handlers van beheerde codeuitzonderingen, bijvoorbeeld met behulp van een try-catch-instructie in C#.

Vanaf .NET Core 1.0 kunnen beschadigde processtatusuitzondering niet worden verwerkt door beheerde code. De algemene taalruntime levert geen beschadigde processtatus-uitzonderingen op beheerde code.

Versie geïntroduceerd

1.0

Vermijd de noodzaak om beschadigde processtatusuitzondering af te handelen door in plaats daarvan de situaties aan te pakken die ertoe leiden. Als het absoluut noodzakelijk is om beschadigde processtatusuitzondering af te handelen, schrijft u de uitzonderingshandler in C- of C++-code.

Categorie

Core .NET-bibliotheken

Betrokken API's

UriBuilder-eigenschappen bevatten geen voorlooptekens meer

UriBuilder.Fragment een voorloopteken # niet langer voorafgaat en UriBuilder.Query een voorloopteken ? niet langer prependeert wanneer er al een teken aanwezig is.

Wijzigingsbeschrijving

In .NET Framework worden de UriBuilder.Fragment en UriBuilder.Query eigenschappen altijd voorafgegaan door respectievelijk een # of ? meer tekens voor de waarde die wordt opgeslagen. Dit gedrag kan leiden tot meerdere # tekens of ? tekens in de opgeslagen waarde als de tekenreeks al een van deze voorlooptekens bevat. De waarde van UriBuilder.Fragment kan bijvoorbeeld worden ##main.

Vanaf .NET Core 1.0 worden de # of ? tekens niet langer voorafgegaan door deze eigenschappen aan de opgeslagen waarde als deze al aanwezig is aan het begin van de tekenreeks.

Versie geïntroduceerd

1.0

U hoeft deze voorlooptekens niet langer expliciet te verwijderen bij het instellen van de eigenschapswaarden. Dit is vooral handig wanneer u waarden toevoegt, omdat u de voorloop # - of ? elke keer dat u toevoegt niet meer hoeft te verwijderen.

In het volgende codefragment ziet u bijvoorbeeld het gedragsverschil tussen .NET Framework en .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);
  • In .NET Framework is ????one=1&two=2&three=3&four=4de uitvoer .
  • In .NET Core is ?one=1&two=2&three=3&four=4de uitvoer .

Categorie

Core .NET-bibliotheken

Betrokken API's

Process.StartInfo genereert InvalidOperationException voor processen die u niet hebt gestart

Het lezen van de Process.StartInfo eigenschap voor processen die uw code niet heeft gestart, genereert een InvalidOperationException.

Wijzigingsbeschrijving

In .NET Framework opent u de Process.StartInfo eigenschap voor processen die uw code niet heeft gestart, retourneert een dummy-object ProcessStartInfo . Het dummy-object bevat standaardwaarden voor alle eigenschappen, behalve EnvironmentVariables.

Als u vanaf .NET Core 1.0 de Process.StartInfo eigenschap leest voor een proces dat u niet hebt gestart (door aan te roepen Process.Start), wordt er een InvalidOperationException gegenereerd.

Versie geïntroduceerd

1.0

Open de Process.StartInfo eigenschap niet voor processen die uw code niet heeft gestart. Lees deze eigenschap bijvoorbeeld niet voor processen die worden geretourneerd door Process.GetProcesses.

Categorie

Core .NET-bibliotheken

Betrokken API's