Sdílet prostřednictvím


Základní knihovny .NET způsobující změny v .NET Core 1.0-3.0

Základní knihovny .NET poskytují primitiva a další obecné typy používané rozhraním .NET Core.

Na této stránce jsou popsané následující zásadní změny:

Změna způsobující chybu Zavedená verze
Předání GroupCollection rozšiřujícím metodám, které přebírají IEnumerable<T> , vyžaduje nejednoznačnost .NET Core 3.0
Rozhraní API, která ohlašují verzi sestavy, teď hlásí produkt a ne verzi souboru. .NET Core 3.0
Instance Custom EncoderFallbackBuffer se nedají rekurzivně vrátit zpět .NET Core 3.0
Změny formátování s plovoucí desetinou čárkou a analýza chování .NET Core 3.0
Operace analýzy s plovoucí desetinou čárkou už selžou nebo vyvolá výjimku OverflowException .NET Core 3.0
InvalidAsynchronousStateException přesunuto do jiného sestavení .NET Core 3.0
Nahrazení špatně vytvořených sekvencí UTF-8 bajtů se řídí pokyny unicode. .NET Core 3.0
TypeDescriptionProviderAttribute přesunuto do jiného sestavení .NET Core 3.0
ZipArchiveEntry už nezpracuje archivy s nekonzistentními velikostmi položek. .NET Core 3.0
FieldInfo.SetValue vyvolá výjimku pro statická pole, pouze inicializační pole .NET Core 3.0
Rozhraní API cest nevyvolají výjimku pro neplatné znaky. .NET Core 2.1
Soukromá pole přidaná do předdefinovaných typů struktur .NET Core 2.1
Změna výchozí hodnoty UseShellExecute .NET Core 2.1
Verze OpenSSL v macOS .NET Core 2.1
UnauthorizedAccessException vyvolán FileSystemInfo.Attributes .NET Core 1.0
Zpracování výjimek poškozeného stavu procesu není podporováno. .NET Core 1.0
Vlastnosti nástroje UriBuilder už nemají předem připravené počáteční znaky. .NET Core 1.0
Process.StartInfo vyvolá výjimku InvalidOperationException pro procesy, které jste nespusili. .NET Core 1.0

.NET Core 3.0

Předání GroupCollection rozšiřujícím metodám, které přebírají IEnumerable<T> , vyžaduje nejednoznačnost

Při volání rozšiřující metody, která přebírá IEnumerable<T> na , GroupCollectionmusíte nejednoznačit typ pomocí přetypování.

Změna popisu

Počínaje .NET Core 3.0 System.Text.RegularExpressions.GroupCollection implementuje IEnumerable<KeyValuePair<String,Group>> kromě dalších typů, které implementuje, včetně IEnumerable<Group>. Výsledkem je nejednoznačnost při volání rozšiřující metody, která přebírá IEnumerable<T>. Pokud takovou metodu GroupCollection rozšíření voláte například Enumerable.Countv instanci, zobrazí se následující chyba kompilátoru:

CS1061: GroupCollection neobsahuje definici pro Count a nelze najít žádnou přístupnou metodu rozšíření Count, která přijímá první argument typu GroupCollection (chybí direktiva using nebo odkaz na sestavení?)

V předchozích verzích rozhraní .NET nebyla žádná nejednoznačnost a chyba kompilátoru.

Zavedená verze

3,0

Důvod změny

To byla neúmyslná změna způsobující chybu. Protože to bylo už nějakou dobu podobné, neplánujeme ho vrátit. Kromě toho by se taková změna sama o sobě rozbila.

Například GroupCollection nejednoznačné volání rozšiřujících metod, které přijímají přetypování IEnumerable<T> .

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

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Všechna rozšiřující metoda, která přijímá, je ovlivněna IEnumerable<T> . Příklad:


Rozhraní API, která ohlašují verzi sestavy, teď hlásí produkt a ne verzi souboru.

Mnoho rozhraní API, která vrací verze v .NET Core, teď vrací verzi produktu, nikoli verzi souboru.

Změna popisu

V .NET Core 2.2 a předchozích verzích, metody, jako Environment.VersionRuntimeInformation.FrameworkDescriptionje , a dialogové okno vlastností souboru pro sestavení .NET Core odráží verzi souboru. Počínaje .NET Core 3.0 odrážejí verzi produktu.

Následující obrázek znázorňuje rozdíl v informacích o verzi pro sestavení System.Runtime.dll pro .NET Core 2.2 (vlevo) a .NET Core 3.0 (vpravo), jak je znázorněno v dialogovém okně vlastností souboru Průzkumníka Windows.

Difference in product version information

Zavedená verze

3,0

Nezaokrouhlovat. Tato změna by měla intuitivně intuitivně rozpoznávat verze, ne obtěžovat.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Instance Custom EncoderFallbackBuffer se nedají rekurzivně vrátit zpět

Vlastní EncoderFallbackBuffer instance se nedají rekurzivně vrátit. Implementace EncoderFallbackBuffer.GetNextChar() musí mít za následek posloupnost znaků, která se konvertibilní na cílové kódování. V opačném případě dojde k výjimce.

Změna popisu

Během operace převodu znaků na bajt modul runtime zjistí špatně vytvořené nebo nekonvertovatelné sekvence UTF-16 a poskytne těmto znakům metodu EncoderFallbackBuffer.Fallback . Metoda Fallback určuje, které znaky mají být nahrazeny původními nekonvertitelnými daty, a tyto znaky jsou vyprázdněné voláním EncoderFallbackBuffer.GetNextChar smyčky.

Modul runtime se pak pokusí tyto znaky nahrazení překódovat do cílového kódování. Pokud je tato operace úspěšná, modul runtime pokračuje v překódování z místa, kde skončil v původním vstupním řetězci.

Dříve vlastní implementace EncoderFallbackBuffer.GetNextChar() mohou vracet sekvence znaků, které nejsou konvertibilní na cílové kódování. Pokud nahrazené znaky nelze překódovat do cílového kódování, modul runtime vyvolá EncoderFallbackBuffer.Fallback metodu znovu s náhradními znaky a očekává, že EncoderFallbackBuffer.GetNextChar() metoda vrátí novou náhradní sekvenci. Tento proces pokračuje, dokud modul runtime nakonec neuvidí správně formátovanou, konvertibilní náhradu nebo dokud se nedosáhne maximálního počtu rekurzí.

Od verze .NET Core 3.0 musí vlastní implementace EncoderFallbackBuffer.GetNextChar() vracet sekvence znaků, které jsou konvertibilní na cílové kódování. Pokud náhradní znaky nelze překódovat do cílového kódování, vyvolá se chyba ArgumentException . Modul runtime už nebude provádět rekurzivní volání instance EncoderFallbackBuffer .

Toto chování platí pouze v případě, že jsou splněny všechny tři z následujících podmínek:

  • Modul runtime zjistí špatně vytvořenou sekvenci UTF-16 nebo sekvenci UTF-16, která se nedá převést na cílové kódování.
  • Bylo zadáno vlastní EncoderFallback .
  • Vlastní EncoderFallback pokusy o nahrazení nové špatně vytvořené nebo nekonvertovatelné sekvence UTF-16.

Zavedená verze

3,0

Většinavývojářůch

Pokud aplikace používá vlastní EncoderFallback a EncoderFallbackBuffer třídu, ujistěte se, že implementace EncoderFallbackBuffer.Fallback záložní vyrovnávací paměti s dobře vytvořenými daty UTF-16, která jsou přímo konvertibilní na cílové kódování při Fallback prvním vyvolání metody modulem runtime.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Změnilo se chování při formátování s plovoucí desetinou čárkou a parsování

Chování při analýze a formátování s plovoucí desetinou čárkou (podle typů DoubleSingle ) je teď kompatibilní se standardem IEEE. Tím zajistíte, že chování typů s plovoucí desetinou čárkou v rozhraní .NET odpovídá chování jiných jazyků kompatibilních se standardem IEEE. Například by se měl vždy shodovat s tím, double.Parse("SomeLiteral") co jazyk C# vytvoří .double x = SomeLiteral

Změna popisu

V .NET Core 2.2 a starších verzích formátování pomocí a Single.ToStringparsování pomocí , Double.TryParseSingle.Parsea Single.TryParse nejsou kompatibilní se standardem Double.ToStringDouble.ParseIEEE. V důsledku toho není možné zaručit, že se hodnota zaokrouhlí s jakýmkoli podporovaným standardním nebo vlastním formátovacím řetězcem. U některých vstupů může pokus o parsování formátované hodnoty selhat a u jiných se analyzovaná hodnota nerovná původní hodnotě.

Počínaje .NET Core 3.0 jsou operace analýzy a formátování s plovoucí desetinou čárkou kompatibilní se standardem IEEE 754.

Následující tabulka ukazuje dva fragmenty kódu a způsob změny výstupu mezi .NET Core 2.2 a .NET Core 3.1.

Fragment kódu Výstup v .NET Core 2.2 Výstup v .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0 až
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));
False True

Další informace najdete v blogovém příspěvku .NET Core 3.0 o parsování a formátování s plovoucí desetinou čárkou.

Zavedená verze

3,0

Potenciální dopad na existující část kódu vylepšení parsování a formátování s plovoucí desetinou čárkou v blogovém příspěvku .NET Core 3.0 navrhuje některé změny, které můžete v kódu provést, pokud chcete zachovat předchozí chování.

  • U některých rozdílů ve formátování můžete získat chování ekvivalentní předchozímu chování zadáním jiného řetězce formátu.
  • U rozdílů při analýze neexistuje žádný mechanismus, který by se vrátil k předchozímu chování.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Operace analýzy s plovoucí desetinou čárkou už selžou nebo vyvolá výjimku OverflowException

Metody parsování s plovoucí desetinnou čárkou už při analýze řetězce, jehož číselná hodnota je mimo rozsah typu s Double plovoucí desetinnou čárkou, už nevyvolají OverflowException ani nevrátífalse.Single

Změna popisu

V .NET Core 2.2 a starších verzích Double.Parse můžou OverflowException metody vyvolat Single.Parse hodnoty, které nejsou v rozsahu příslušného typu. Metody Double.TryParse a Single.TryParse návraty false pro řetězcové reprezentace číselných hodnot mimo rozsah.

Počínaje rozhraním .NET Core 3.0 Double.ParseDouble.TryParseSingle.Parseuž selžou metody a Single.TryParse metody při analýze číselných řetězců mimo rozsah. Double Místo toho metody analýzy vrátí Double.PositiveInfinity hodnoty, které překračují Double.MaxValue, a vrátí Double.NegativeInfinity hodnoty, které jsou menší než Double.MinValue. Single Podobně metody analýzy vrací Single.PositiveInfinity hodnoty, které překračují Single.MaxValue, a vrátí Single.NegativeInfinity hodnoty, které jsou menší než Single.MinValue.

Tato změna byla provedena pro lepší dodržování předpisů IEEE 754:2008.

Zavedená verze

3,0

Tato změna může ovlivnit váš kód dvěma způsoby:

  • Váš kód závisí na obslužné rutině OverflowException , která se má provést, když dojde k přetečení. V tomto případě byste měli příkaz odebrat catch a umístit veškerý potřebný kód do If příkazu, který testuje, zda Double.IsInfinity nebo Single.IsInfinity je true.

  • Váš kód předpokládá, že hodnoty s plovoucí desetinou čárkou nejsou Infinity. V tomto případě byste měli přidat potřebný kód pro kontrolu hodnot s plovoucí desetinou čárkou PositiveInfinity a NegativeInfinity.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


InvalidAsynchronousStateException přesunuto do jiného sestavení

Třída InvalidAsynchronousStateException byla přesunuta.

Změna popisu

V .NET Core 2.2 a starších verzích InvalidAsynchronousStateException se třída nachází v sestavení System.ComponentModel.TypeConverter .

Počínaje .NET Core 3.0 se nachází v sestavení System.ComponentModel.Primitives .

Zavedená verze

3,0

Tato změna má vliv pouze na aplikace, které používají reflexi k načtení InvalidAsynchronousStateException volání metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě aktualizujte sestavení odkazované ve volání metody tak, aby odráželo nové umístění sestavení typu.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Nezaokrouhlovat.


Nahrazení špatně vytvořených sekvencí UTF-8 bajtů se řídí pokyny unicode.

Když třída UTF8Encoding během operace převodu bajtů na znak zaznamená špatně vytvořenou sekvenci UTF-8 bajtů, nahradí ji znakem ' (U+FFFD REPLACE CHARACTER) ve výstupním řetězci. .NET Core 3.0 se liší od předchozích verzí .NET Core a rozhraní .NET Framework podle osvědčeného postupu kódování Unicode pro provedení této náhrady během operace překódování.

To je součástí většího úsilí o zlepšení zpracování UTF-8 v rámci .NET, včetně nových System.Text.Unicode.Utf8 a System.Text.Rune typů. Tento UTF8Encoding typ získal vylepšenou mechaniku zpracování chyb, aby vytvořil výstup konzistentní s nově zavedenými typy.

Změna popisu

Počínaje .NET Core 3.0 při překódování bajtů na znaky UTF8Encoding třída provádí nahrazení znaků na základě osvědčených postupů unicode. Použitý mechanismus nahrazení popisuje Standard Unicode verze 12.0, s. 3.9 (PDF) v nadpisu s názvem U+FFFD Subparts.

Toto chování platí pouze v případě, že vstupní bajtová sekvence obsahuje špatně vytvořená data UTF-8. Kromě toho, pokud UTF8Encoding instance byla vytvořena throwOnInvalidBytes: trues , UTF8Encoding instance bude nadále vyvolána na neplatný vstup místo provedení U+FFFD nahrazení. Další informace o konstruktoru UTF8Encoding naleznete v tématu UTF8Encoding(Boolean, Boolean).

Následující tabulka ukazuje dopad této změny s neplatným vstupem o 3 bajty:

3 bajtový vstup s neformulovanou dvěma bajty Výstup před .NET Core 3.0 Výstup začínající na .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (Výstup se 2 znaky) [ FFFD FFFD FFFD ] (Výstup se 3 znaky)

3-char výstup je upřednostňovaný výstup podle tabulky 3-9 dříve propojeného Unicode Standard PDF.

Zavedená verze

3,0

Na straně vývojáře není nutná žádná akce.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


TypeDescriptionProviderAttribute přesunuto do jiného sestavení

Třída TypeDescriptionProviderAttribute byla přesunuta.

Změna popisu

V .NET Core 2.2 a starších verzích se TypeDescriptionProviderAttribute třída nachází v sestavení System.ComponentModel.TypeConverter .

Počínaje rozhraním .NET Core 3.0 se nachází v sestavení System.ObjectModel .

Zavedená verze

3,0

Tato změna má vliv pouze na aplikace, které používají reflexi k načtení TypeDescriptionProviderAttribute typu voláním metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě by se sestavení odkazované ve volání metody mělo aktualizovat tak, aby odráželo nové umístění sestavení typu.

Kategorie

Windows Forms

Ovlivněná rozhraní API

Nezaokrouhlovat.


ZipArchiveEntry už nezpracuje archivy s nekonzistentními velikostmi položek.

Seznam archivů zip komprimované i nekomprimované velikosti v centrálním adresáři a místní hlavičce. Samotná vstupní data také označují svou velikost. V .NET Core 2.2 a starších verzích nebyly tyto hodnoty nikdy zkontrolovány na konzistenci. Počínaje .NET Core 3.0 jsou teď.

Změna popisu

V .NET Core 2.2 a starších verzích je úspěšné, ZipArchiveEntry.Open() i když místní hlavička nesouhlasí s centrální hlavičkou souboru ZIP. Data se dekompresí do dosažení konce komprimovaného datového proudu, i když jeho délka překračuje nekomprimovanou velikost souboru uvedenou v centrální hlavičce adresáře nebo místního adresáře.

Počínaje rozhraním .NET Core 3.0 metoda kontroluje, ZipArchiveEntry.Open() jestli místní hlavička a centrální hlavička souhlasí s komprimovanými a nekomprimovanými velikostmi položky. Pokud tomu tak není, metoda vyvolá InvalidDataException , pokud místní záhlaví archivu nebo seznam popisovačů dat, které nesouhlasí s centrálním adresářem souboru ZIP. Při čtení položky se dekomprimovaná data zkrátí na nekomprimovanou velikost souboru uvedenou v záhlaví.

Tato změna byla provedena, aby se zajistilo, že ZipArchiveEntry správně představuje velikost dat a že je přečteno pouze takové množství dat.

Zavedená verze

3,0

Znovu zabalte archiv zip, který vykazuje tyto problémy.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


FieldInfo.SetValue vyvolá výjimku pro statická pole, pouze inicializační pole

Počínaje rozhraním .NET Core 3.0 se vyvolá výjimka při pokusu o nastavení hodnoty na statickém InitOnly poli voláním System.Reflection.FieldInfo.SetValue.

Změna popisu

V rozhraní .NET Framework a verzích .NET Core před verzí 3.0 můžete nastavit hodnotu statického pole, které je po inicializaci (jen pro čtení v jazyce C#) voláním System.Reflection.FieldInfo.SetValue. Nastavení takového pole tímto způsobem však vedlo k nepředvídatelným chováním na základě cílové architektury a nastavení optimalizace.

V .NET Core 3.0 a novějších verzích se při volání SetValue statického InitOnly pole System.FieldAccessException vyvolá výjimka.

Tip

Pole InitOnly je pole, které lze nastavit pouze v době, kdy je deklarována nebo v konstruktoru pro obsahující třídu. Jinými slovy, po inicializaci je konstantní.

Zavedená verze

3,0

Inicializace statických InitOnly polí ve statickém konstruktoru To platí pro dynamické i ne dynamicky.

Případně můžete atribut z pole odebrat FieldAttributes.InitOnly a potom volat FieldInfo.SetValue.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


.NET Core 2.1

Rozhraní API cest nevyvolají výjimku pro neplatné znaky.

Rozhraní API, která zahrnují cesty k souborům, již neověřují znaky cesty nebo vyvolává výjimku, ArgumentException pokud byl nalezen neplatný znak.

Změna popisu

V rozhraní .NET Framework a .NET Core 1.0 – 2.0 vyvolá metody uvedené v části ArgumentException Ovlivněná rozhraní API chybu, pokud argument cesty obsahuje neplatný znak cesty. Od verze .NET Core 2.1 už tyto metody nekontrolují neplatné znaky cesty nebo v případě nalezení neplatného znaku vyvolá výjimku.

Důvod změny

Agresivní ověřování znaků cesty blokuje některé scénáře pro různé platformy. Tato změna byla zavedena tak, aby se rozhraní .NET nepokoušelo replikovat ani předpovědět výsledek volání rozhraní API operačního systému. Další informace najdete v System.IO v blogovém příspěvku .NET Core 2.1 .

Zavedená verze

.NET Core 2.1

Pokud váš kód spoléhal na tato rozhraní API ke kontrole neplatných znaků, můžete přidat volání Path.GetInvalidPathChars.

Ovlivněná rozhraní API

Viz také


Soukromá pole přidaná do předdefinovaných typů struktur

Privátní pole byla přidána do určitých typů struktur v referenčních sestaveních. V jazyce C# proto musí být tyto typy struktur vždy vytvořena pomocí nového operátoru nebo výchozího literálu.

Změna popisu

V .NET Core 2.0 a předchozích verzích můžou být některé zadané typy ConsoleKeyInfostruktur například možné vytvořit instanci bez použití operátoru nebo výchozího new literálu v jazyce C#. Důvodem bylo to, že referenční sestavení používaná kompilátorem jazyka C# neobsahovala privátní pole pro struktury. Všechna privátní pole pro typy struktur .NET se přidají do referenčních sestavení začínajících v .NET Core 2.1.

Například následující kód C# se zkompiluje v .NET Core 2.0, ale ne v .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

V .NET Core 2.1 má předchozí kód za následek následující chybu kompilátoru: CS0165 – Použití nepřiřazené místní proměnné key

Zavedená verze

2.1

Vytvoření instance typů struktury pomocí operátoru nebo výchozího literálu new

Příklad:

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Změna výchozí hodnoty UseShellExecute

ProcessStartInfo.UseShellExecute má výchozí hodnotu false v .NET Core. V rozhraní .NET Framework je truejejí výchozí hodnota .

Změna popisu

Process.Startumožňuje spustit aplikaci přímo, například s kódem, jako Process.Start("mspaint.exe") je spuštění Malování. Umožňuje také nepřímo spustit přidruženou aplikaci, pokud ProcessStartInfo.UseShellExecute je nastavena na true. V rozhraní .NET Framework je výchozí hodnota ProcessStartInfo.UseShellExecutetruepro , což znamená, že kód, jako Process.Start("mytextfile.txt") je spuštění Poznámkový blok, pokud jste přidružili .txt soubory s tímto editorem. Pokud chcete zabránit nepřímému spuštění aplikace v rozhraní .NET Framework, musíte explicitně nastavit ProcessStartInfo.UseShellExecute .false V .NET Core je výchozí hodnota pro ProcessStartInfo.UseShellExecutefalse. To znamená, že přidružené aplikace nejsou ve výchozím nastavení spuštěny při volání Process.Start.

Následující vlastnosti jsou funkční pouze v těchto truepřípadech ProcessStartInfo.UseShellExecuteSystem.Diagnostics.ProcessStartInfo:

Tato změna byla zavedena v .NET Core z důvodů výkonu. Process.Start Obvykle se používá ke spuštění aplikace přímo. Spuštění aplikace přímo nemusí zahrnovat prostředí Windows a vyžadovat související náklady na výkon. Aby bylo toto výchozí případ rychlejší, změní .NET Core výchozí hodnotu ProcessStartInfo.UseShellExecute na false. Pokud ji potřebujete, můžete se přihlásit k pomalejší cestě.

Zavedená verze

2.1

Poznámka:

V dřívějších verzích .NET Core UseShellExecute se pro Windows neimplementoval.

Pokud vaše aplikace spoléhá na staré chování, zavolejte Process.Start(ProcessStartInfo) na objekt nastavený UseShellExecute na trueProcessStartInfo hodnotu.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Verze OpenSSL v macOS

Moduly runtime .NET Core 3.0 a novější v systému macOS teď dávají přednost verzím OpenSSL 1.1.x pro verze OpenSSL 1.0.x pro AesCcmverze , , ECDiffieHellmanOpenSslDSAOpenSslECDsaOpenSslAesGcmRSAOpenSsla SafeEvpPKeyHandle typy.

Modul runtime .NET Core 2.1 teď podporuje verze OpenSSL 1.1.x, ale stále preferuje verze OpenSSL 1.0.x.

Změna popisu

Modul runtime .NET Core dříve používal verze OpenSSL 1.0.x v systému macOS pro typy, které komunikují s OpenSSL. Nejnovější verze OpenSSL 1.0.x, OpenSSL 1.0.2, je teď mimo podporu. Pro zachování typů, které používají OpenSSL v podporovaných verzích OpenSSL, teď .NET Core 3.0 a novější moduly runtime používají novější verze OpenSSL v macOS.

Při této změně je chování modulů runtime .NET Core v systému macOS následující:

  • Moduly runtime .NET Core 3.0 a novější verze používají OpenSSL 1.1.x, pokud jsou k dispozici, a pokud jsou k dispozici, vraťte se k OpenSSL 1.0.x, pouze pokud není k dispozici žádná verze 1.1.x.

    Pro volající, kteří používají typy komunikace OpenSSL s vlastními voláními P/Invokes, postupujte podle pokynů v SafeEvpPKeyHandle.OpenSslVersion poznámkách. Pokud tuto hodnotu nekontrolujete, může dojít k chybovému OpenSslVersion ukončení aplikace.

  • Modul runtime .NET Core 2.1 používá OpenSSL 1.0.x, pokud je k dispozici, a vrátí se zpět na OpenSSL 1.1.x, pokud není k dispozici žádná verze 1.0.x.

    Modul runtime 2.1 dává přednost dřívější verzi OpenSSL, protože SafeEvpPKeyHandle.OpenSslVersion vlastnost v .NET Core 2.1 neexistuje, takže verzi OpenSSL nelze spolehlivě určit za běhu.

Zavedená verze

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


.NET Core 1.0

UnauthorizedAccessException vyvolán FileSystemInfo.Attributes

V .NET Core se vyvolá, UnauthorizedAccessException když se volající pokusí nastavit hodnotu atributu souboru, ale nemá oprávnění k zápisu.

Změna popisu

V rozhraní .NET Framework je vyvolán, ArgumentException když se volající pokusí nastavit hodnotu atributu souboru, FileSystemInfo.Attributes ale nemá oprávnění k zápisu. V .NET Core se místo toho vyvolá chyba UnauthorizedAccessException . (V .NET Core je stále vyvolán, ArgumentException pokud se volající pokusí nastavit neplatný atribut souboru.)

Zavedená verze

1.0

Podle potřeby upravte všechny catch příkazy tak, aby zachytály místo UnauthorizedAccessException nebo kromě něj .ArgumentException

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Zpracování výjimek poškozeného stavu není podporováno.

Zpracování výjimek poškozeného stavu procesu v .NET Core se nepodporuje.

Změna popisu

Dříve bylo možné zachytit a zpracovat poškozené výjimky stavu procesu a zpracovávat obslužnými rutinami výjimek spravovaného kódu, například pomocí příkazu try-catch v jazyce C#.

Počínaje verzí .NET Core 1.0 nelze spravovaného kódu zpracovat poškozené výjimky stavu procesu. Modul CLR (Common Language Runtime) nedoručuje do spravovaného kódu poškozené výjimky stavu procesu.

Zavedená verze

1.0

Vyhněte se nutnosti zpracovávat poškozené výjimky stavu procesu tím, že řešíte situace, které k nim vedou. Pokud je naprosto nezbytné zpracovat výjimky poškozeného stavu procesu, napište obslužnou rutinu výjimky v kódu jazyka C nebo C++.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Vlastnosti nástroje UriBuilder už nemají předem připravené počáteční znaky.

UriBuilder.Fragment už nepředá úvodní # znak a UriBuilder.Query už nepředá úvodní ? znak, pokud už existuje.

Změna popisu

V rozhraní .NET Framework UriBuilder.Fragment a UriBuilder.Query vlastnosti vždy předložily # znak nebo ? znak na hodnotu, která se ukládá. Toto chování může vést k více # znakům ? v uložené hodnotě, pokud řetězec již obsahuje jeden z těchto úvodních znaků. Může se například stát ##mainhodnotou UriBuilder.Fragment .

Počínaje verzí .NET Core 1.0 už tyto vlastnosti nepředpokládají # uloženou hodnotu ani ? znaky, pokud je již na začátku řetězce.

Zavedená verze

1.0

Při nastavování hodnot vlastností už nemusíte explicitně odebírat žádné z těchto úvodních znaků. To je zvlášť užitečné, když připojujete hodnoty, protože už nemusíte odebírat úvodní náběr # ani ? při každém připojení.

Následující fragment kódu například ukazuje rozdíl chování mezi rozhraním .NET Framework a .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);
  • V rozhraní .NET Framework je ????one=1&two=2&three=3&four=4výstup .
  • V .NET Core je ?one=1&two=2&three=3&four=4výstup .

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API


Process.StartInfo vyvolá výjimku InvalidOperationException pro procesy, které jste nespusili.

Process.StartInfo Čtení vlastnosti pro procesy, které váš kód nespustí, vyvolá chybu InvalidOperationException.

Změna popisu

V rozhraní .NET Framework se přístup k Process.StartInfo vlastnosti pro procesy, které váš kód nespustí, vrátí fiktivní ProcessStartInfo objekt. Fiktivní objekt obsahuje výchozí hodnoty pro všechny jeho vlastnosti s výjimkou EnvironmentVariables.

Počínaje .NET Core 1.0, pokud přečtete Process.StartInfo vlastnost procesu, který jste nespusili (tj. voláním Process.Start), InvalidOperationException vyvolá se vyvolání.

Zavedená verze

1.0

Nepřistupujte k Process.StartInfo vlastnosti pro procesy, které váš kód nespusl. Například nečte tuto vlastnost pro procesy vrácené Process.GetProcesses.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API