Istotne zmiany bibliotek platformy .NET w programie .NET Core 1.0-3.0

Podstawowe biblioteki platformy .NET udostępniają typy pierwotne i inne typy ogólne używane przez platformę .NET Core.

Na tej stronie udokumentowane są następujące zmiany powodujące niezgodność:

Zmiana powodująca niezgodność Wprowadzona wersja
Przekazywanie elementu GroupCollection do metod rozszerzeń przy użyciu metody IEnumerable<T> wymaga uściślania .NET Core 3.0
Interfejsy API raportu, które teraz zgłaszają wersję produktu, a nie wersję pliku .NET Core 3.0
Wystąpienia custom EncoderFallbackBuffer nie mogą wrócić rekursywnie .NET Core 3.0
Zmiany zachowania formatowania zmiennoprzecinkowego i analizowania .NET Core 3.0
Operacje analizowania zmiennoprzecinkowego nie kończą się już niepowodzeniem ani nie zgłaszają wyjątku OverflowException .NET Core 3.0
InvalidAsynchronousStateException przeniesiono do innego zestawu .NET Core 3.0
Zastępowanie źle sformułowanych sekwencji bajtów UTF-8 jest zgodne z wytycznymi Unicode .NET Core 3.0
TypeDescriptionProviderAttribute przeniesiono do innego zestawu .NET Core 3.0
ZipArchiveEntry nie obsługuje już archiwów z niespójnymi rozmiarami pozycji .NET Core 3.0
FieldInfo.SetValue zgłasza wyjątek dla pól statycznych, tylko do inicjowania .NET Core 3.0
Interfejsy API ścieżki nie zgłaszają wyjątku dla nieprawidłowych znaków .NET Core 2.1
Pola prywatne dodane do wbudowanych typów struktur .NET Core 2.1
Zmień wartość domyślną polecenia UseShellExecute .NET Core 2.1
Wersje protokołu OpenSSL w systemie macOS .NET Core 2.1
Brak autoryzacjiAccessWyrażenie zgłaszane przez fileSystemInfo.Attributes .NET Core 1.0
Obsługa uszkodzonych wyjątków stanu procesu nie jest obsługiwana .NET Core 1.0
Właściwości UriBuilder nie poprzedzają już znaków wiodących .NET Core 1.0
Process.StartInfo zgłasza wyjątek InvalidOperationException dla procesów, których nie uruchomiono .NET Core 1.0

.NET Core 3.0

Przekazywanie elementu GroupCollection do metod rozszerzeń przy użyciu metody IEnumerable<T> wymaga uściślania

Podczas wywoływania metody rozszerzenia, która przyjmuje IEnumerable<T> element na GroupCollectionobiekcie , należy uściślić typ przy użyciu rzutowania.

Opis zmiany

Począwszy od platformy .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementuje oprócz innych typów, które implementuje IEnumerable<KeyValuePair<String,Group>> , w tym IEnumerable<Group>. Powoduje to niejednoznaczność podczas wywoływania metody rozszerzenia, która przyjmuje metodę IEnumerable<T>. Jeśli wywołasz taką metodę rozszerzenia na GroupCollection przykład , Enumerable.Countzobaczysz następujący błąd kompilatora:

CS1061: "GroupCollection" nie zawiera definicji metody "Count" i nie można odnaleźć dostępnej metody rozszerzenia "Count" akceptującej pierwszy argument typu "GroupCollection" (czy brakuje dyrektywy using lub odwołania do zestawu?)

W poprzednich wersjach platformy .NET nie było żadnych niejednoznaczności i nie było błędu kompilatora.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Była to niezamierzona zmiana powodująca niezgodność. Ponieważ to było tak od jakiegoś czasu, nie planujemy go przywrócić. Ponadto taka zmiana sama byłaby łamiąca.

Na GroupCollection przykład uściślanie wywołań metod rozszerzenia, które akceptują metodę IEnumerable<T> rzutowania.

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

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

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Dotyczy to dowolnej metody rozszerzenia, która akceptuje IEnumerable<T> element . Na przykład:


Interfejsy API raportu, które teraz zgłaszają wersję produktu, a nie wersję pliku

Wiele interfejsów API, które zwracają wersje na platformie .NET Core, zwraca teraz wersję produktu, a nie wersję pliku.

Opis zmiany

W programie .NET Core 2.2 i poprzednich wersjach metody, takie jak Environment.Version, RuntimeInformation.FrameworkDescriptioni okno dialogowe właściwości pliku dla zestawów platformy .NET Core odzwierciedla wersję pliku. Począwszy od platformy .NET Core 3.0, odzwierciedlają wersję produktu.

Na poniższej ilustracji przedstawiono różnicę w informacjach o wersji zestawu System.Runtime.dll dla platformy .NET Core 2.2 (po lewej stronie) i programu .NET Core 3.0 (po prawej stronie) wyświetlanego przez okno dialogowe właściwości pliku Eksploratora Windows.

Difference in product version information

Wprowadzona wersja

3.0

Brak. Ta zmiana powinna sprawić, że wykrywanie wersji powinno być intuicyjne, a nie zatusze.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Wystąpienia custom EncoderFallbackBuffer nie mogą wrócić rekursywnie

Wystąpienia niestandardowe EncoderFallbackBuffer nie mogą powracać rekursywnie. Implementacja EncoderFallbackBuffer.GetNextChar() musi skutkować sekwencją znaków, która jest konwertowana na kodowanie docelowe. W przeciwnym razie wystąpi wyjątek.

Opis zmiany

Podczas operacji transkodowania znaków do bajtów środowisko uruchomieniowe wykrywa źle sformułowane lub niekonwertowalne sekwencje UTF-16 i udostępnia te znaki metodzie EncoderFallbackBuffer.Fallback . Metoda Fallback określa, które znaki powinny zostać zastąpione oryginalnymi danymi niekonwertowalnymi, a te znaki są opróżniane przez wywołanie EncoderFallbackBuffer.GetNextChar w pętli.

Następnie środowisko uruchomieniowe próbuje transkodować te znaki podstawienia do kodowania docelowego. Jeśli ta operacja powiedzie się, środowisko uruchomieniowe kontynuuje transkodowanie, z którego zostało wyłączone w oryginalnym ciągu wejściowym.

Wcześniej niestandardowe implementacje EncoderFallbackBuffer.GetNextChar() programu mogą zwracać sekwencje znaków, które nie są konwertowane na kodowanie docelowe. Jeśli nie można transkodować znaków zastępczych do kodowania docelowego, środowisko uruchomieniowe ponownie wywołuje EncoderFallbackBuffer.Fallback metodę z znakami podstawienia, oczekując EncoderFallbackBuffer.GetNextChar() , że metoda zwróci nową sekwencję podstawienia. Ten proces będzie kontynuowany do momentu, aż środowisko uruchomieniowe w końcu zobaczy prawidłowo sformułowane, zamieniające się podstawianie lub do momentu osiągnięcia maksymalnej liczby rekursji.

Począwszy od platformy .NET Core 3.0, niestandardowe implementacje EncoderFallbackBuffer.GetNextChar() muszą zwracać sekwencje znaków, które są konwertowane na kodowanie docelowe. Jeśli nie można transkodować znaków zastępczych do kodowania docelowego, ArgumentException zostanie zgłoszony element . Środowisko uruchomieniowe nie będzie już wykonywać cyklicznych wywołań do EncoderFallbackBuffer wystąpienia.

To zachowanie ma zastosowanie tylko wtedy, gdy zostaną spełnione wszystkie trzy z następujących warunków:

  • Środowisko uruchomieniowe wykrywa nieprawidłową sekwencję UTF-16 lub sekwencję UTF-16, której nie można przekonwertować na kodowanie docelowe.
  • Określono niestandardowe EncoderFallback .
  • EncoderFallback Niestandardowe próby zastąpienia nowej źle sformułowanej lub niekonwertowalnej sekwencji UTF-16.

Wprowadzona wersja

3.0

Większość deweloperów nie potrzebuje żadnych działań.

Jeśli aplikacja używa niestandardowego EncoderFallback i EncoderFallbackBuffer klasy, upewnij się, że implementacja buforu EncoderFallbackBuffer.Fallback rezerwowego jest wypełniana dobrze sformułowanymi danymi UTF-16, które są bezpośrednio konwertowane na kodowanie docelowe, gdy Fallback metoda jest wywoływana po raz pierwszy przez środowisko uruchomieniowe.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Zachowanie formatowania zmiennoprzecinkowego i analizowania zostało zmienione

Zachowanie analizowania i formatowania zmiennoprzecinkowego (według Double typów i Single ) jest teraz zgodne ze standardem IEEE. Dzięki temu zachowanie typów zmiennoprzecinkowych na platformie .NET jest zgodne z innymi językami zgodnymi ze standardem IEEE. Na przykład double.Parse("SomeLiteral") należy zawsze odpowiadać wartościom generowanym przez język C# dla elementu double x = SomeLiteral.

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach formatowanie za pomocą Double.ToString poleceń i Single.ToStringoraz analizowanie za pomocą poleceń , Double.TryParse, Single.Parsei Single.TryParse nie jest zgodne ze standardem Double.ParseIEEE. W związku z tym nie można zagwarantować, że wartość zostanie zaokrąglona z dowolnym obsługiwanym ciągiem formatu standardowego lub niestandardowego. W przypadku niektórych danych wejściowych próba przeanalizowania sformatowanej wartości może zakończyć się niepowodzeniem, a dla innych przeanalizowana wartość nie jest równa oryginalnej wartości.

Począwszy od platformy .NET Core 3.0, operacje analizowania i formatowania zmiennoprzecinkowego są zgodne ze standardem IEEE 754.

W poniższej tabeli przedstawiono dwa fragmenty kodu i sposób zmiany danych wyjściowych między platformą .NET Core 2.2 i platformą .NET Core 3.1.

Fragment kodu Dane wyjściowe na platformie .NET Core 2.2 Dane wyjściowe na platformie .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0–
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));
False True

Aby uzyskać więcej informacji, zobacz ulepszenia analizowania i formatowania zmiennoprzecinkowe w wpisie w blogu platformy .NET Core 3.0 .

Wprowadzona wersja

3.0

Potencjalny wpływ na istniejącą sekcję kodu ulepszenia analizowania i formatowania zmiennoprzecinkowego w wpisie w blogu platformy .NET Core 3.0 sugeruje pewne zmiany, które można wprowadzić w kodzie, jeśli chcesz zachować poprzednie zachowanie.

  • W przypadku niektórych różnic w formatowaniu można uzyskać zachowanie równoważne poprzedniemu zachowaniu, określając inny ciąg formatu.
  • W przypadku różnic w analizowaniu nie ma mechanizmu powrotu do poprzedniego zachowania.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Operacje analizowania zmiennoprzecinkowego nie kończą się już niepowodzeniem ani nie zgłaszają wyjątku OverflowException

Metody analizowania zmiennoprzecinkowego nie zgłaszają OverflowException już wartości lub zwracają false , gdy analizują ciąg, którego wartość liczbowa znajduje się poza zakresem Single typu zmiennoprzecinkowego lub Double zmiennoprzecinkowego.

Opis zmiany

W przypadku platformy .NET Core 2.2 i starszych wersji Double.Parse metody i Single.Parse zgłaszają OverflowException wartości spoza zakresu odpowiedniego typu. Metody Double.TryParse i Single.TryParse zwracają false reprezentacje ciągów poza zakresem wartości liczbowych.

Począwszy od platformy .NET Core 3.0, Double.Parsemetody , Double.TryParse, Single.Parsei Single.TryParse nie kończą się już niepowodzeniem podczas analizowania ciągów liczbowych poza zakresem. Double Zamiast tego metody analizowania zwracają Double.PositiveInfinity wartości, które przekraczają Double.MaxValuewartość , i zwracają Double.NegativeInfinity wartości, które są mniejsze niż Double.MinValue. Single Podobnie metody analizowania zwracają Single.PositiveInfinity wartości, które przekraczają Single.MaxValuewartość , i zwracają Single.NegativeInfinity wartości, które są mniejsze niż Single.MinValue.

Ta zmiana została wprowadzona w celu poprawy zgodności IEEE 754:2008.

Wprowadzona wersja

3.0

Ta zmiana może mieć wpływ na kod na jeden z dwóch sposobów:

  • Kod zależy od programu obsługi, OverflowException który ma zostać wykonany, gdy wystąpi przepełnienie. W takim przypadku należy usunąć instrukcję catch i umieścić dowolny niezbędny kod w If instrukcji, która sprawdza, czy Single.IsInfinityDouble.IsInfinity element ma truewartość .

  • W kodzie przyjęto założenie, że wartości zmiennoprzecinkowe nie Infinitysą . W takim przypadku należy dodać niezbędny kod, aby sprawdzić wartości PositiveInfinity zmiennoprzecinkowe i NegativeInfinity.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


InvalidAsynchronousStateException przeniesiono do innego zestawu

Klasa została przeniesiona InvalidAsynchronousStateException .

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach InvalidAsynchronousStateException klasa znajduje się w zestawie System.ComponentModel.TypeConverter .

Począwszy od platformy .NET Core 3.0, znajduje się on w zestawie System.ComponentModel.Primitives .

Wprowadzona wersja

3.0

Ta zmiana dotyczy tylko aplikacji, które używają odbicia w celu załadowania InvalidAsynchronousStateException obiektu przez wywołanie metody, takiej jak Assembly.GetType lub przeciążenie Activator.CreateInstance , które zakłada, że typ jest w określonym zestawie. W takim przypadku zaktualizuj zestaw, do którego odwołuje się wywołanie metody, aby odzwierciedlić nową lokalizację zestawu typu.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Brak.


Zastępowanie źle sformułowanych sekwencji bajtów UTF-8 jest zgodne z wytycznymi Unicode

UTF8Encoding Gdy klasa napotka nieprawidłowo sformułowaną sekwencję bajtów UTF-8 podczas operacji transkodowania bajt-znak, zastępuje tę sekwencję znakiem " (U+FFFD REPLACE CHARACTER) w ciągu wyjściowym. Program .NET Core 3.0 różni się od poprzednich wersji platformy .NET Core i programu .NET Framework, stosując najlepsze rozwiązanie Unicode do wykonania tego zastąpienia podczas operacji transkodowania.

Jest to część większego nakładu pracy, aby ulepszyć obsługę utF-8 na platformie .NET, w tym przez nowe System.Text.Unicode.Utf8 i System.Text.Rune typy. Typ UTF8Encoding otrzymał ulepszoną mechanikę obsługi błędów, dzięki czemu generuje dane wyjściowe zgodne z nowo wprowadzonymi typami.

Opis zmiany

Począwszy od platformy .NET Core 3.0, gdy transkodowanie bajtów do znaków, UTF8Encoding klasa wykonuje podstawianie znaków na podstawie najlepszych rozwiązań Unicode. Używany mechanizm podstawiania jest opisany przez Standard Unicode w wersji 12.0, s. 3.9 (PDF) w nagłówku zatytułowanym Podstawianie U+FFFD maksymalnie części podrzędnych.

To zachowanie ma zastosowanie tylko wtedy, gdy sekwencja bajtów wejściowych zawiera źle sformułowane dane UTF-8. Ponadto jeśli UTF8Encoding wystąpienie zostało skonstruowane za pomocą throwOnInvalidBytes: truepolecenia , UTF8Encoding wystąpienie będzie nadal zgłaszać nieprawidłowe dane wejściowe, a nie wykonać zamiany U+FFFD. Aby uzyskać więcej informacji na temat konstruktora UTF8Encoding , zobacz UTF8Encoding(Boolean, Boolean).

W poniższej tabeli przedstawiono wpływ tej zmiany z nieprawidłowymi danymi wejściowymi 3-bajtowymi:

Źle sformułowane dane wejściowe 3-bajtowe Dane wyjściowe przed platformą .NET Core 3.0 Dane wyjściowe rozpoczynające się od platformy .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (2-znakowe dane wyjściowe) [ FFFD FFFD FFFD ] (3-znakowe dane wyjściowe)

Dane wyjściowe 3-char są preferowanymi danymi wyjściowymi, zgodnie z tabelą 3-9 wcześniej połączonego standardowego pliku PDF Unicode.

Wprowadzona wersja

3.0

Ze strony dewelopera nie jest wymagana żadna akcja.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


TypeDescriptionProviderAttribute przeniesiono do innego zestawu

Klasa została przeniesiona TypeDescriptionProviderAttribute .

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach TypeDescriptionProviderAttribute klasa znajduje się w zestawie System.ComponentModel.TypeConverter .

Począwszy od platformy .NET Core 3.0, znajduje się on w zestawie System.ObjectModel .

Wprowadzona wersja

3.0

Ta zmiana dotyczy tylko aplikacji, które używają odbicia w celu załadowania TypeDescriptionProviderAttribute typu przez wywołanie metody, takiej jak Assembly.GetType lub przeciążenie Activator.CreateInstance , które zakłada, że typ jest w określonym zestawie. W takim przypadku zestaw, do którego odwołuje się wywołanie metody, powinien zostać zaktualizowany w celu odzwierciedlenia nowej lokalizacji zestawu typu.

Kategoria

Windows Forms

Dotyczy interfejsów API

Brak.


ZipArchiveEntry nie obsługuje już archiwów z niespójnymi rozmiarami pozycji

Archiwa zip wyświetlają zarówno skompresowany rozmiar, jak i nieskompresowany rozmiar w centralnym katalogu i nagłówku lokalnym. Dane wejściowe również wskazują jego rozmiar. W programie .NET Core 2.2 i starszych wersjach te wartości nigdy nie były sprawdzane pod kątem spójności. Począwszy od platformy .NET Core 3.0, są teraz.

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach kończy się powodzeniem, ZipArchiveEntry.Open() nawet jeśli nagłówek lokalny nie zgadza się z centralnym nagłówkiem pliku zip. Dane są dekompresowane do końca skompresowanego strumienia, nawet jeśli jego długość przekracza nieskompresowany rozmiar pliku wymieniony w centralnym katalogu/nagłówku lokalnym.

Począwszy od platformy .NET Core 3.0, metoda sprawdza, ZipArchiveEntry.Open() czy lokalny nagłówek i centralny nagłówek zgadzają się na skompresowane i nieskompresowane rozmiary wpisu. Jeśli tak nie jest, metoda zgłasza InvalidDataException , czy lokalny nagłówek archiwum i/lub rozmiary list deskryptora danych, które nie zgadzają się z centralnym katalogiem pliku zip. Podczas odczytywania wpisu zdekompresowane dane są obcinane do nieskompresowanego rozmiaru pliku wymienionego w nagłówku.

Ta zmiana została wprowadzona w celu zapewnienia, że ZipArchiveEntry prawidłowo reprezentuje rozmiar danych i że tylko ta ilość danych jest odczytywana.

Wprowadzona wersja

3.0

Zapakuj ponownie wszelkie archiwum zip, które wykazuje te problemy.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


FieldInfo.SetValue zgłasza wyjątek dla pól statycznych, tylko do inicjowania

Począwszy od platformy .NET Core 3.0, podczas próby ustawienia wartości w statycznym InitOnly polu jest zgłaszany wyjątek, wywołując metodę System.Reflection.FieldInfo.SetValue.

Opis zmiany

W programie .NET Framework i wersjach platformy .NET Core wcześniejszych niż 3.0 można ustawić wartość pola statycznego, które jest stałe po zainicjowaniu (tylko do odczytu w języku C#), wywołując metodę System.Reflection.FieldInfo.SetValue. Jednak ustawienie takiego pola w ten sposób spowodowało nieprzewidywalne zachowanie w oparciu o platformę docelową i ustawienia optymalizacji.

W programie .NET Core 3.0 lub nowszym podczas wywoływania SetValue statycznego InitOnly pola zgłaszany System.FieldAccessException jest wyjątek.

Napiwek

Pole InitOnly to pole, które można ustawić tylko wtedy, gdy jest zadeklarowane lub w konstruktorze dla zawierającej klasy. Innymi słowy, jest stała po zainicjowaniu.

Wprowadzona wersja

3.0

Inicjowanie statycznych InitOnly pól w konstruktorze statycznym. Dotyczy to zarówno typów dynamicznych, jak i niedynamicznych.

Alternatywnie możesz usunąć FieldAttributes.InitOnly atrybut z pola, a następnie wywołać metodę FieldInfo.SetValue.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


.NET Core 2.1

Interfejsy API ścieżki nie zgłaszają wyjątku dla nieprawidłowych znaków

Interfejsy API, które obejmują ścieżki plików, nie weryfikują już znaków ścieżki ani nie zgłaszają ArgumentException nieprawidłowego znaku.

Opis zmiany

W programach .NET Framework i .NET Core 1.0 – 2.0 metody wymienione w sekcji Objęte interfejsy API zgłaszają błąd ArgumentException , jeśli argument ścieżki zawiera nieprawidłowy znak ścieżki. Począwszy od platformy .NET Core 2.1, te metody nie sprawdzają już nieprawidłowych znaków ścieżki lub zgłaszają wyjątek w przypadku znalezienia nieprawidłowego znaku.

Przyczyna wprowadzenia zmiany

Agresywna walidacja znaków ścieżki blokuje niektóre scenariusze międzyplatformowe. Ta zmiana została wprowadzona tak, aby platforma .NET nie próbowała replikować ani przewidywać wyniku wywołań interfejsu API systemu operacyjnego. Aby uzyskać więcej informacji, zobacz wpis w blogu System.IO w programie .NET Core 2.1 sneak peek .

Wprowadzona wersja

.NET Core 2.1

Jeśli kod polegał na tych interfejsach API w celu sprawdzania nieprawidłowych znaków, możesz dodać wywołanie metody .Path.GetInvalidPathChars

Dotyczy interfejsów API

Zobacz też


Pola prywatne dodane do wbudowanych typów struktur

Pola prywatne zostały dodane do niektórych typów struktur w zestawach referencyjnych. W związku z tym w języku C# te typy struktur muszą być zawsze tworzone przy użyciu nowego operatora lub literału domyślnego.

Opis zmiany

W programie .NET Core 2.0 i poprzednich wersjach niektóre podane typy struktur, na przykład , ConsoleKeyInfomożna utworzyć wystąpienie bez użycia operatora lub domyślnego new literału w języku C#. Wynikało to z faktu, że zestawy odwołań używane przez kompilator języka C# nie zawierały pól prywatnych dla struktur. Wszystkie pola prywatne dla typów struktur platformy .NET są dodawane do zestawów referencyjnych, począwszy od platformy .NET Core 2.1.

Na przykład następujący kod języka C# kompiluje się na platformie .NET Core 2.0, ale nie na platformie .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

W programie .NET Core 2.1 poprzedni kod powoduje następujący błąd kompilatora: CS0165 — Użycie nieprzypisanej zmiennej lokalnej "key"

Wprowadzona wersja

2.1

Utwórz wystąpienie typów struktur przy użyciu operatora lub literału domyślnegonew.

Na przykład:

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

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Zmień wartość domyślną polecenia UseShellExecute

ProcessStartInfo.UseShellExecute ma wartość false domyślną na platformie .NET Core. W programie .NET Framework jego wartością domyślną jest true.

Opis zmiany

Process.Start umożliwia uruchamianie aplikacji bezpośrednio, na przykład za pomocą kodu, takiego jak Process.Start("mspaint.exe") uruchomienie programu Paint. Umożliwia również pośrednio uruchomienie skojarzonej aplikacji, jeśli ProcessStartInfo.UseShellExecute jest ustawiona na truewartość . W programie .NET Framework wartość domyślna to ProcessStartInfo.UseShellExecutetrue, co oznacza, że kod, taki jak Process.Start("mytextfile.txt") Notatnik, jeśli skojarzysz .txt pliki z tym edytorem. Aby zapobiec pośrednio uruchamianiu aplikacji na platformie .NET Framework, należy jawnie ustawić wartość ProcessStartInfo.UseShellExecutefalse. Na platformie .NET Core domyślną wartością parametru ProcessStartInfo.UseShellExecute jest false. Oznacza to, że domyślnie skojarzone aplikacje nie są uruchamiane podczas wywoływania metody Process.Start.

Następujące właściwości w systemie System.Diagnostics.ProcessStartInfo działają tylko wtedy, gdy ProcessStartInfo.UseShellExecute to true:

Ta zmiana została wprowadzona na platformie .NET Core ze względu na wydajność. Process.Start Zazwyczaj służy do bezpośredniego uruchamiania aplikacji. Bezpośrednie uruchamianie aplikacji nie wymaga zaangażowania powłoki systemu Windows i ponoszenia powiązanych kosztów wydajności. Aby przyspieszyć ten domyślny przypadek, platforma .NET Core zmienia wartość domyślną na ProcessStartInfo.UseShellExecutefalse. Jeśli jest to potrzebne, możesz wyrazić zgodę na wolniejsze ścieżki.

Wprowadzona wersja

2.1

Uwaga

We wcześniejszych wersjach platformy .NET Core UseShellExecute nie zaimplementowano dla systemu Windows.

Jeśli aplikacja opiera się na starym zachowaniu, wywołaj metodę Process.Start(ProcessStartInfo) z ustawioną wartością UseShellExecutetrueProcessStartInfo na obiekt .

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Wersje protokołu OpenSSL w systemie macOS

Środowiska uruchomieniowe platformy .NET Core 3.0 i nowsze w systemie macOS preferują teraz wersje openSSL 1.1.x dla wersji OpenSSL 1.0.x dla AesCcmtypów , , AesGcm, DSAOpenSslECDiffieHellmanOpenSslECDsaOpenSsl, RSAOpenSsl, i SafeEvpPKeyHandle .

Środowisko uruchomieniowe platformy .NET Core 2.1 obsługuje teraz wersje openSSL 1.1.x, ale nadal preferuje wersje openSSL 1.0.x.

Opis zmiany

Wcześniej środowisko uruchomieniowe platformy .NET Core używało wersji OpenSSL 1.0.x w systemie macOS dla typów korzystających z biblioteki OpenSSL. Najnowsza wersja openSSL 1.0.x, OpenSSL 1.0.2, jest obecnie niedostępna. Aby zachować typy używające biblioteki OpenSSL w obsługiwanych wersjach biblioteki OpenSSL, środowiska uruchomieniowe platformy .NET Core 3.0 i nowszych używają teraz nowszych wersji biblioteki OpenSSL w systemie macOS.

Dzięki tej zmianie zachowanie środowisk uruchomieniowych platformy .NET Core w systemie macOS jest następujące:

  • Środowiska uruchomieniowe platformy .NET Core 3.0 lub nowszej używają biblioteki OpenSSL 1.1.x, jeśli są dostępne, i wracają do biblioteki OpenSSL 1.0.x tylko wtedy, gdy nie ma dostępnej wersji 1.1.x.

    W przypadku osób wywołujących korzystających z typów międzyoperacyjności OpenSSL z niestandardowymi wywołaniami P/Invoke postępuj zgodnie ze wskazówkami w SafeEvpPKeyHandle.OpenSslVersion uwagach. Aplikacja może ulec awarii, jeśli nie sprawdzisz OpenSslVersion wartości.

  • Środowisko uruchomieniowe platformy .NET Core 2.1 używa biblioteki OpenSSL 1.0.x, jeśli jest dostępne, i wraca do biblioteki OpenSSL 1.1.x, jeśli nie ma dostępnej wersji 1.0.x.

    Środowisko uruchomieniowe 2.1 preferuje starszą wersję biblioteki OpenSSL, ponieważ SafeEvpPKeyHandle.OpenSslVersion właściwość nie istnieje na platformie .NET Core 2.1, więc wersja openSSL nie może być niezawodnie określona w czasie wykonywania.

Wprowadzona wersja

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

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


.NET Core 1.0

Brak autoryzacjiAccessWyrażenie zgłaszane przez fileSystemInfo.Attributes

W programie .NET Core obiekt jest zgłaszany, gdy obiekt wywołujący próbuje ustawić wartość atrybutu pliku, UnauthorizedAccessException ale nie ma uprawnień do zapisu.

Opis zmiany

W programie .NET Framework obiekt jest zgłaszany, ArgumentException gdy obiekt wywołujący próbuje ustawić wartość atrybutu pliku, FileSystemInfo.Attributes ale nie ma uprawnień do zapisu. W programie .NET Core zamiast tego jest zgłaszany element UnauthorizedAccessException . (W programie .NET Core obiekt jest nadal zgłaszany, ArgumentException jeśli obiekt wywołujący próbuje ustawić nieprawidłowy atrybut pliku).

Wprowadzona wersja

1.0

Zmodyfikuj dowolne catch instrukcje, aby przechwycić UnauthorizedAccessException zamiast lub oprócz ArgumentExceptionelementu , w razie potrzeby.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Obsługa uszkodzonych wyjątków stanu nie jest obsługiwana

Obsługa uszkodzonych wyjątków stanu procesu na platformie .NET Core nie jest obsługiwana.

Opis zmiany

Wcześniej wyjątki uszkodzonego stanu procesu mogą być przechwytywane i obsługiwane przez programy obsługi wyjątków kodu zarządzanego, na przykład przy użyciu instrukcji try-catch w języku C#.

Począwszy od programu .NET Core 1.0, wyjątki stanu uszkodzonego procesu nie mogą być obsługiwane przez kod zarządzany. Środowisko uruchomieniowe języka wspólnego nie dostarcza uszkodzonych wyjątków stanu procesu do kodu zarządzanego.

Wprowadzona wersja

1.0

Unikaj konieczności obsługi uszkodzonych wyjątków stanu procesu, zwracając się do sytuacji, które zamiast tego prowadzą do nich. Jeśli jest to absolutnie konieczne do obsługi wyjątków uszkodzonego stanu procesu, napisz procedurę obsługi wyjątków w kodzie C lub C++.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Właściwości UriBuilder nie poprzedzają już znaków wiodących

UriBuilder.Fragmentnie poprzedza już znaku wiodącego #? i UriBuilder.Query nie poprzedza już wiodącego znaku, gdy jest już obecny.

Opis zmiany

W programie .NET Framework UriBuilder.Fragment właściwości i UriBuilder.Query zawsze poprzedzają # odpowiednio znak lub ? do przechowywanej wartości. To zachowanie może spowodować powstanie wielu # znaków lub ? znaków w przechowywanej wartości, jeśli ciąg zawiera już jeden z tych znaków wiodących. Na przykład wartość może stać się wartością UriBuilder.Fragment##main.

Począwszy od platformy .NET Core 1.0, te właściwości nie poprzedzają # już wartości przechowywanej ani ? znaków, jeśli są one już obecne na początku ciągu.

Wprowadzona wersja

1.0

Nie trzeba już jawnie usuwać żadnego z tych znaków wiodących podczas ustawiania wartości właściwości. Jest to szczególnie przydatne w przypadku dołączania wartości, ponieważ nie trzeba już usuwać elementów wiodących # lub ? za każdym razem, gdy dołączasz.

Na przykład poniższy fragment kodu przedstawia różnicę zachowania między programem .NET Framework i platformą .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);
  • W programie .NET Framework dane wyjściowe to ????one=1&two=2&three=3&four=4.
  • W programie .NET Core dane wyjściowe to ?one=1&two=2&three=3&four=4.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API


Process.StartInfo zgłasza wyjątek InvalidOperationException dla procesów, których nie uruchomiono

Odczytywanie Process.StartInfo właściwości dla procesów, których kod nie rozpoczął, zgłasza błąd InvalidOperationException.

Opis zmiany

W programie .NET Framework uzyskiwanie Process.StartInfo dostępu do właściwości procesów, których kod nie rozpoczął, zwraca fikcyjny ProcessStartInfo obiekt. Fikcyjny obiekt zawiera wartości domyślne dla wszystkich jego właściwości z wyjątkiem EnvironmentVariables.

Począwszy od platformy .NET Core 1.0, jeśli odczytujesz Process.StartInfo właściwość dla procesu, który nie został uruchomiony (czyli przez wywołanie metody Process.Start), InvalidOperationException jest zgłaszany.

Wprowadzona wersja

1.0

Nie należy uzyskiwać Process.StartInfo dostępu do właściwości dla procesów, których kod nie został uruchomiony. Na przykład nie odczytuj tej właściwości dla procesów zwracanych przez Process.GetProcesses.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API