Поделиться через


Критические изменения в основных библиотеках .NET Core версий 1.0–3.0.

Основные библиотеки .NET предоставляет примитивы и другие общие типы, используемые в .NET Core.

На этой странице описаны следующие критические изменения:

Критическое изменение Представленные версии
Передача GroupCollection в методы расширения, принимающие IEnumerable<T> , требует диамбигуации .NET Core 3.0
Интерфейсы API, сообщающие версию, теперь сообщают версию продукта, а не файла .NET Core 3.0
Пользовательские экземпляры EncoderFallbackBuffer не поддерживают рекурсивный откат .NET Core 3.0
Изменено поведение форматирования и анализа при наличии плавающей запятой .NET Core 3.0
Операции синтаксического анализа с плавающей запятой больше не завершаются ошибкой и не вызывают исключение OverflowException .NET Core 3.0
Исключение InvalidAsynchronousStateException перенесено в другую сборку .NET Core 3.0
Замена неправильно сформированных последовательностей байтов в кодировке UTF-8 в соответствии с правилами Юникода .NET Core 3.0
Класс TypeDescriptionProviderAttribute перенесен в другую сборку .NET Core 3.0
ZipArchiveEntry больше не обрабатывает архивы с несогласованными размерами записей .NET Core 3.0
FieldInfo.SetValue вызывает исключение для статических полей и полей только для инициализации .NET Core 3.0
API-интерфейсы пути не выдают исключение для недопустимых символов .NET Core 2.1
Во встроенные типы структур добавлены частные поля .NET Core 2.1
Изменено значение по умолчанию для UseShellExecute .NET Core 2.1
Версии OpenSSL в macOS .NET Core 2.1
Исключение UnauthorizedAccessException, вызванное FileSystemInfo.Attributes .NET Core 1.0
Обработка исключений с поврежденным состоянием процесса не поддерживается .NET Core 1.0
Для свойств UriBuilder больше не добавляются начальные символы .NET Core 1.0
Process.StartInfo выдает исключение InvalidOperationException для процессов, которые не были запущены .NET Core 1.0

.NET Core 3.0

Передача GroupCollection в методы расширения, принимающие IEnumerable<T> , требует диамбигуации

При вызове метода расширения, который принимает IEnumerable<T> в GroupCollection, необходимо устранить неоднозначность типа с помощью приведения.

Описание изменения

Начиная с .NET Core 3.0 System.Text.RegularExpressions.GroupCollection реализует IEnumerable<KeyValuePair<String,Group>> в дополнение к другим реализуемым типам, включая IEnumerable<Group>. Это приводит к неоднозначности при вызове метода расширения, который принимает IEnumerable<T>. При вызове такого метода расширения в экземпляре GroupCollection, например Enumerable.Count, вы увидите следующую ошибку компилятора:

CS1061: GroupCollection не содержит определения для Count и нет метода расширения Count, принимающий первый аргумент типа GroupCollection (отсутствует директива using или ссылка на сборку?)

В предыдущих версиях .NET не существовало неоднозначности и не было таких ошибок компилятора.

Представленные версии

3.0

Причина изменения

Это было непреднамеренное критическое изменение. Так как все это уже существовало некоторое время, мы не планируем отменять его. Кроме того, такое изменение само по себе будет критическим.

Для экземпляров GroupCollection устраните неоднозначность вызовов методов расширения, которые принимают IEnumerable<T>, путем приведения.

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

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

Категория

Основные библиотеки .NET

Затронутые API

Затрагиваются все методы расширения, принимающие IEnumerable<T>. Например:


Интерфейсы API, сообщающие версию, теперь сообщают версию продукта, а не файла

Многие интерфейсы API, которые возвращают версию в .NET Core, теперь возвращают версию продукта, а не файла.

Описание изменения

В .NET Core 2.2 и предыдущих версиях такие методы, как Environment.Version, RuntimeInformation.FrameworkDescription и диалоговое окно свойств файла для сборок .NET Core, сообщают версию файла. Начиная с версии .NET Core 3.0, они сообщают версию продукта.

На приведенном ниже рисунке показана разница в сведениях о версии для сборки System.Runtime.dll для .NET Core 2.2 (слева) и .NET Core 3.0 (справа), отображаемых в диалоговом окне свойств файла в проводнике.

Difference in product version information

Представленные версии

3.0

Нет. Это изменение должно сделать определение версии интуитивно понятным.

Категория

Основные библиотеки .NET

Затронутые API


Пользовательские экземпляры EncoderFallbackBuffer не поддерживают рекурсивный откат

Пользовательские экземпляры EncoderFallbackBuffer не поддерживают рекурсивный откат. В результате реализации EncoderFallbackBuffer.GetNextChar() должна быть создана последовательность символов, которая преобразуется в целевую кодировку. В противном случае возникает исключение.

Описание изменения

При перекодировании символов в байты среда выполнения обнаруживает некорректные или непреобразуемые последовательности UTF-16 и передает эти символы методу EncoderFallbackBuffer.Fallback. Метод Fallback определяет, какие символы следует заменить в исходных непреобразуемых данных, и эти символы удаляются путем вызова EncoderFallbackBuffer.GetNextChar в цикле.

Затем среда выполнения пытается перекодировать эти символы подстановки в целевую кодировку. Если это удалось выполнить, среда выполнения продолжит перекодировку с того места, где она остановилась на исходной входной строке.

Ранее пользовательские реализации EncoderFallbackBuffer.GetNextChar() могли возвращать последовательности символов, которые нельзя преобразовать в целевую кодировку. Если подставляемые символы не поддерживают такое преобразование, среда выполнения снова вызовет метод EncoderFallbackBuffer.Fallback с символами подстановки, ожидая, что метод EncoderFallbackBuffer.GetNextChar() вернет новую последовательность символов подстановки. Этот процесс продолжится до тех пор, пока среда выполнения не увидит правильно сформированную и преобразуемую последовательность символов подстановки или пока не будет достигнуто максимальное число рекурсий.

Начиная с версии .NET Core 3.0, пользовательские реализации EncoderFallbackBuffer.GetNextChar() должны возвращать последовательности символов, преобразуемые в целевую кодировку. Если подставляемые символы нельзя перекодировать в целевую кодировку, создается исключение ArgumentException. Среда выполнения больше не будет выполнять рекурсивные вызовы к экземпляру EncoderFallbackBuffer.

Такой подход применяется только в том случае, если выполнены все следующие три условия:

  • Среда выполнения обнаруживает последовательность UTF-16, которая была неправильно сформирована или не подлежит преобразованию в целевую кодировку.
  • Указана пользовательская реализация EncoderFallback.
  • Пользовательская реализация EncoderFallback пытается заменить новую неправильно сформированную или непреобразуемую последовательность UTF-16.

Представленные версии

3.0

В большинстве случаев от разработчиков не требуется никаких действий.

Если приложение использует пользовательский класс EncoderFallback и EncoderFallbackBuffer, убедитесь, что реализация EncoderFallbackBuffer.Fallback заполняет буфер отката правильно сформированными данными UTF-16, которые можно сразу же преобразовать в целевую кодировку, когда среда выполнения впервые вызывает метод Fallback.

Категория

Основные библиотеки .NET

Затронутые API


Изменено поведение форматирования и анализа при наличии плавающей запятой

Поведение форматирования и анализа при наличии плавающей запятой (с помощью типов Double и Single) теперь совместимо со стандартами IEEE. Благодаря этому поведение типов с плавающей запятой в .NET соответствует их поведению в языках, совместимых с IEEE. Например, результат double.Parse("SomeLiteral") всегда должен совпадать с результатом, создаваемым в C# для double x = SomeLiteral.

Описание изменения

В .NET Core 2.2 и более ранних версиях форматирование с помощью Double.ToString и Single.ToString и анализ с помощью Double.Parse, Double.TryParse, Single.Parse и Single.TryParse не были совместимы со стандартами IEEE. В результате это не позволяло гарантировать, что значение будет соответствовать какой-либо поддерживаемой стандартной или пользовательской строке формата. Для некоторых входных данных попытка проанализировать отформатированное значение может завершиться ошибкой, а для других — проанализированное значение не равно исходному.

Начиная с .NET Core 3.0, операции анализа и форматирования для чисел с плавающей запятой совместимы со стандартом IEEE 754.

В следующей таблице показаны два фрагмента кода и отличие выходных данных между .NET Core 2.2 и .NET Core 3.1.

Фрагмент кода Выходные данные в .NET Core 2.2 Выходные данные в .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0–
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));
False True

Дополнительные сведения см. в записи блога Улучшения в синтаксическом анализе и форматировании плавающей запятой в .NET Core 3.0.

Представленные версии

3.0

В разделе Потенциальное воздействие на существующий код записи блога Улучшения в синтаксическом анализе и форматировании чисел с плавающей запятой в .NET Core 3.0 предлагаются изменения, которые можно внести в код, чтобы сохранить предыдущее поведение.

  • Для некоторых изменений в форматировании можно получить поведение, эквивалентное предыдущему поведению, указав другую строку форматирования.
  • Но для изменений в синтаксическом анализе не существует механизма, позволяющего вернуть предыдущее поведение.

Категория

Основные библиотеки .NET

Затронутые API


Операции синтаксического анализа с плавающей запятой больше не завершаются ошибкой и не вызывают исключение OverflowException

Методы синтаксического анализа с плавающей запятой больше не вызывают OverflowException и не возвращают false при синтаксическом анализе строки, числовое значение которой находится вне диапазона типа с плавающей запятой Single или Double.

Описание изменения

В .NET Core 2.2 и более ранних версиях методы Double.Parse и Single.Parse вызывают OverflowException для значений, которые выходят за пределы диапазона соответствующего типа. Методы Double.TryParse и Single.TryParse возвращают false для строковых представлений числовых значений вне диапазона.

Начиная с .NET Core 3.0 методы Double.Parse, Double.TryParse, Single.Parse и Single.TryParse больше не завершаются сбоем при анализе числовых строк вне диапазона. Вместо этого методы синтаксического анализа Double возвращают Double.PositiveInfinity для значений, превышающих Double.MaxValue, и Double.NegativeInfinity — для значений, которые меньше Double.MinValue. Подобным образом, методы синтаксического анализа Single возвращают Single.PositiveInfinity для значений, превышающих Single.MaxValue, и Single.NegativeInfinity — для значений, которые меньше Single.MinValue.

Это изменение было внесено для улучшения соответствия требованиям IEEE 754:2008.

Представленные версии

3.0

Это изменение может повлиять на код одним из двух способов:

  • Код зависит от обработчика OverflowException для выполнения при переполнении. В этом случае следует удалить оператор catch и поместить необходимый код в инструкцию If, которая проверяет, является ли Double.IsInfinity или Single.IsInfinitytrue.

  • В коде предполагается, что значения с плавающей запятой не являются Infinity. В этом случае следует добавить необходимый код для проверки значений с плавающей запятой PositiveInfinity и NegativeInfinity.

Категория

Основные библиотеки .NET

Затронутые API


Исключение InvalidAsynchronousStateException перенесено в другую сборку

Класс InvalidAsynchronousStateException перемещен.

Описание изменения

В .NET Core 2.2 и более ранних версиях класс InvalidAsynchronousStateException находится в сборке System.ComponentModel.TypeConverter.

Начиная с .NET Core 3.0, он находится в сборке System.ComponentModel.Primitives.

Представленные версии

3.0

Это изменение влияет только на приложения, использующие отражение для загрузки InvalidAsynchronousStateException путем вызова метода, такого как Assembly.GetType, или перегрузки Activator.CreateInstance, которая предполагает, что тип находится в определенной сборке. В этом случае обновите сборку, указанную в вызове метода, в соответствии с новым расположением сборки типа.

Категория

Основные библиотеки .NET

Затронутые API

Нет.


Замена неправильно сформированных последовательностей байтов в кодировке UTF-8 в соответствии с правилами Юникода

UTF8Encoding Когда класс сталкивается с неправильно сформированной последовательностью байтов UTF-8 во время операции перекодирования байтов к символам, он заменяет такую последовательность символом ' (U+FFFD REPLACE CHARACTER) в выходной строке. В .NET Core 3.0, в отличие от предыдущих версий .NET Core и .NET Framework, применяются рекомендации по Юникоду для таких замен при операциях перекодирования.

Это лишь часть больших усилий улучшить обработку данных в формате UTF-8 в .NET, включая новые типы System.Text.Unicode.Utf8 и System.Text.Rune. Для типа UTF8Encoding предоставлен улучшенный механизм обработки ошибок, чтобы его выходные данные соответствовали новым типам.

Описание изменения

Начиная с .NET Core 3.0, при перекодировании байтов в символы класс UTF8Encoding выполняет подстановку символов на основе рекомендаций по Юникоду. Используемый механизм подстановки описан в документе по стандарту "Юникод" версии 12.0, раздел 3.9 (PDF) с заголовком U+FFFD Substitution of Maximal Subparts (Замена наибольшей части неправильной последовательности символом U+FFFD).

Такой подход применяется только в том случае, если входная последовательность байтов содержит некорректные данные в кодировке UTF-8. Кроме того, если экземпляр UTF8Encoding был создан с помощью throwOnInvalidBytes: true, экземпляр UTF8Encoding будет и дальше выдавать исключение при недопустимых входных данных, а не выполнять замену символом U+FFFD. Дополнительные сведения о конструкторе UTF8Encoding см. в статье UTF8Encoding(Boolean, Boolean).

В следующей таблице показано влияние этого изменения на примере недопустимых 3-байтовых входных данных.

Некорректно сформированные 3-байтовые входные данные Выходные данные в версиях до .NET Core 3.0 Выходные данные в .NET Core 3.0 и более поздних версиях
[ ED A0 90 ] [ FFFD FFFD ] (выходные данные в виде двухзначного кода) [ FFFD FFFD FFFD ] (выходные данные в виде трехзначного кода)

Согласно таблице 3-9 из PDF-документа по Юникоду, ссылка на который приведена выше, предпочтительным является вариант с выходными данными в виде трехзначного кода.

Представленные версии

3.0

От разработчика не требуется никаких действий.

Категория

Основные библиотеки .NET

Затронутые API


Класс TypeDescriptionProviderAttribute перенесен в другую сборку

Класс TypeDescriptionProviderAttribute перемещен.

Описание изменения

В .NET Core 2.2 и более ранних версиях класс TypeDescriptionProviderAttribute находится в сборке System.ComponentModel.TypeConverter.

Начиная с .NET Core 3.0 он находится в сборке System.ObjectModel.

Представленные версии

3.0

Это изменение влияет только на приложения, использующие отражение для загрузки типа TypeDescriptionProviderAttribute путем вызова метода, такого как Assembly.GetType, или перегрузки Activator.CreateInstance, которая предполагает, что тип находится в определенной сборке. В этом случае сборку, указанную в вызове метода, необходимо обновить в соответствии с новым расположением сборки типа.

Категория

Windows Forms

Затронутые API

Нет.


ZipArchiveEntry больше не обрабатывает архивы с несогласованными размерами записей

Для ZIP-архивов указывается размер в сжатом и несжатом виде в центральном каталоге и в локальном заголовке. В данных записи также содержится информация о ее размере. В .NET Core 2.2 и более ранних версиях эти значения не проверялись на согласованность. Начиная с версии .NET Core 3.0 такая проверка выполняется.

Описание изменения

В .NET Core 2.2 и более ранних версиях метод ZipArchiveEntry.Open() выполняется успешно, даже если данные в локальном заголовке не совпадают с данными в центральном заголовке ZIP-файла. Данные распаковываются до тех пор, пока не будет достигнут конец сжатого потока, даже если его длина превышает размер несжатого файла, указанный в центральном каталоге или в локальном заголовке.

Начиная с .NET Core 3.0 метод ZipArchiveEntry.Open() проверяет, чтобы данные в локальном и центральном заголовках о размерах сжатой и несжатой записи были согласованными. Если в локальном заголовке архива и/или в дескрипторе данных указаны размеры, которые отличаются от размеров в центральном каталоге ZIP-файла, метод вызывает исключение InvalidDataException. При считывании записи распакованные данные усекаются до размера несжатого файла, который указан в заголовке.

Это изменение позволит ZipArchiveEntry корректно представлять размер данных и обеспечит считывание именно такого объема данных.

Представленные версии

3.0

Переархивируйте все ZIP-файлы, с которыми возникают такие проблемы.

Категория

Основные библиотеки .NET

Затронутые API


FieldInfo.SetValue вызывает исключение для статических полей и полей только для инициализации

Начиная с .NET Core версии 3.0, при попытке задать значение в статическом поле InitOnly путем вызова System.Reflection.FieldInfo.SetValue, возникает исключение.

Описание изменения

В .NET Framework и версиях .NET Core до 3.0 можно было задать значение статического поля, которое являлось константой после его инициализации (только для чтения в C#) путем вызова System.Reflection.FieldInfo.SetValue. Однако установка такого поля таким образом приведет к непредсказуемому поведению в зависимости от целевой платформы и параметров оптимизации.

В .NET Core 3.0 и более поздних версиях, при вызове SetValue для статического поля InitOnly создается исключение System.FieldAccessException.

Совет

Поле InitOnly — это поле, которое можно задать только во время объявления или в конструкторе содержащего класса. Иными словами, оно остается константой после инициализации.

Представленные версии

3.0

Инициализируйте статические поля InitOnly в статическом конструкторе. Это относится как к динамическим, так и к не динамическим типам.

Кроме того, можно удалить атрибут FieldAttributes.InitOnly из поля, а затем вызвать FieldInfo.SetValue.

Категория

Основные библиотеки .NET

Затронутые API


.NET Core 2.1

API-интерфейсы пути не выдают исключение для недопустимых символов

API-интерфейсы, использующие пути к файлам, больше не проверяют символы пути и не выдают исключение ArgumentException при обнаружении недопустимого символа.

Описание изменения

На платформе .NET Framework и .NET Core 1.0–2.0 методы, перечисленные в разделе Затронутые API, выдают исключение ArgumentException, если аргумент пути содержит недопустимый символ. Начиная с версии .NET Core 2.1, эти методы больше не проверяют наличие недопустимых символов пути и не выдают исключение при обнаружении недопустимого символа.

Причина изменения

Агрессивная проверка символов пути блокирует некоторые межплатформенные сценарии. Это изменение было внесено, чтобы платформа .NET не пыталась реплицировать или предсказать результат вызовов API операционной системы. Дополнительные сведения см. в записи блога Предварительный обзор System.IO в .NET Core 2.1.

Представленные версии

.NET Core 2.1

Если ваш код использовал эти API для проверки наличия недопустимых символов, можно добавить вызов Path.GetInvalidPathChars.

Затронутые API

См. также


Во встроенные типы структур добавлены частные поля

Частные поля добавлены в некоторые типы структур в ссылочных сборках. В результате в C# эти типы структуры всегда должны создаваться с помощью оператора new или литерала по умолчанию.

Описание изменения

В .NET Core 2.0 и предыдущих версиях некоторые типы структур, например ConsoleKeyInfo, можно создать в C# без использования оператора new или литерала по умолчанию. Это вызвано тем, что ссылочные сборки, используемые компилятором C#, не содержат частных полей для структур. Все частные поля для типов структуры .NET добавляются в ссылочные сборки, начиная с .NET Core 2.1.

Например, следующий код C# компилируется в .NET Core 2.0, но не в .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

В .NET Core 2.1 предыдущий код приводит к следующей ошибке компилятора: CS0165 — использование неназначенных локальных переменных key

Представленные версии

2.1

Создайте экземпляры типов структуры с помощью оператора new или литерала по умолчанию.

Например:

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

Категория

Основные библиотеки .NET

Затронутые API


Изменено значение по умолчанию для UseShellExecute

ProcessStartInfo.UseShellExecute имеет значение false по умолчанию в .NET Core. В .NET Framework его значение по умолчанию — true.

Описание изменения

Process.Start позволяет запускать приложение напрямую, например с помощью кода, как Process.Start("mspaint.exe"), запускающего Paint. Это также позволяет косвенно запускать связанное приложение, если для ProcessStartInfo.UseShellExecute установлено значение true. В .NET Framework значением по умолчанию для ProcessStartInfo.UseShellExecute является true, что означает, что такой код как Process.Start("mytextfile.txt") будет запускать Блокнот, если вы связали файлы .txt с этим редактором. Чтобы предотвратить косвенный запуск приложения на .NET Framework, необходимо явно установить false на ProcessStartInfo.UseShellExecute. В .NET Core значением по умолчанию для ProcessStartInfo.UseShellExecute является значение false. Это означает, что связанные по умолчанию приложения не запускаются при вызове Process.Start.

Следующие свойства System.Diagnostics.ProcessStartInfo работают только в том случае, если ProcessStartInfo.UseShellExecute имеет значение true:

Это изменение введено в .NET Core для повышения производительности. Как правило, Process.Start используется для непосредственного запуска приложения. Запуск приложения напрямую не требует затрагивания оболочки Windows и влечет за собой соответствующие расходы на производительность. Чтобы ускорить этот вариант по умолчанию, .NET Core изменяет значение по умолчанию ProcessStartInfo.UseShellExecute на false. При необходимости вы можете выбрать более медленный путь.

Представленные версии

2.1

Примечание.

В более ранних версиях .NET Core UseShellExecute не был внедрен для Windows.

Если приложение полагается на прежнее поведение, вызовите Process.Start(ProcessStartInfo), указав для параметра UseShellExecute значение true в объекте ProcessStartInfo.

Категория

Основные библиотеки .NET

Затронутые API


Версии OpenSSL в macOS

В среде выполнения .NET Core 3.0 и более поздних версий в macOS вместо версий OpenSSL 1.0.x для типов AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl и SafeEvpPKeyHandle теперь предпочтительно использовать версии OpenSSL 1.1.x.

Среда выполнения .NET Core 2.1 теперь поддерживает версии OpenSSL 1.1.x, однако предпочтительными по-прежнему являются версии OpenSSL 1.0.x.

Описание изменения

Ранее в среде выполнения .NET Core для типов, которые взаимодействуют с OpenSSL, использовались версии OpenSSL 1.0.x в macOS. Последняя версия OpenSSL 1.0.x (OpenSSL 1.0.2) теперь не поддерживается. Для сохранения типов, использующих OpenSSL в поддерживаемых версиях OpenSSL, в средах выполнения .NET Core 3.0 и более поздних версий теперь используются более новые версии OpenSSL в macOS.

В связи с этим изменением поведение сред выполнения .NET Core в macOS теперь реализуется следующим образом.

  • В средах выполнения .NET Core 3.0 и более поздних версий при условии доступности используется OpenSSL 1.1.x, и только если версия 1.1.x не доступна, осуществляется откат к OpenSSL 1.0.x.

    Для вызывающих объектов, использующих типы взаимодействия OpenSSL с пользовательскими методами P/Invoke, необходимо следовать указаниям в примечаниях SafeEvpPKeyHandle.OpenSslVersion. Если не проверить значение OpenSslVersion, приложение может аварийно завершить работу.

  • В средах выполнения .NET Core 2.1 при условии доступности используется OpenSSL 1.0.x, а если версия 1.0.x не доступна, осуществляется откат к OpenSSL 1.1.x.

    В среде выполнения версии 2.1 предпочтительно использовать более раннюю версию OpenSSL, поскольку в .NET Core 2.1 отсутствует свойство SafeEvpPKeyHandle.OpenSslVersion, в связи с чем во время выполнения невозможно гарантированно определить версию OpenSSL.

Представленные версии

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

Категория

Основные библиотеки .NET

Затронутые API


.NET Core 1.0

Исключение UnauthorizedAccessException, вызванное FileSystemInfo.Attributes

В .NET Core UnauthorizedAccessException возникает, когда вызывающий пытается задать значение атрибута файла, но у него нет разрешений на запись.

Описание изменения

В .NET Framework ArgumentException возникает, когда вызывающий пытается задать значение атрибута файла в FileSystemInfo.Attributes, но у него нет разрешений на запись. В .NET Core вместо него возникает UnauthorizedAccessException (в .NET Core ArgumentException по-прежнему возникает, если вызывающий пытается задать недопустимый атрибут файла).

Представленные версии

1.0

Изменяйте любые инструкции catch, чтобы получить UnauthorizedAccessException вместо или в дополнение к ArgumentException по мере необходимости.

Категория

Основные библиотеки .NET

Затронутые API


Обработка исключений поврежденного состояния не поддерживается

Обработка исключений поврежденного состояния в .NET Core не поддерживается.

Описание изменения

Ранее исключения поврежденного состояния процесса могли быть перехвачены и обработаны обработчиками исключений управляемого кода, например с помощью инструкции try-catch в C#.

Начиная с .NET Core 1.0 исключения поврежденного состояния процесса не могут обрабатываться управляемым кодом. Среда CLR не доставляет исключения поврежденного состояния процесса в управляемый код.

Представленные версии

1.0

Старайтесь исключить потребность в обработке исключений поврежденного состояния процесса, устраняя ситуации, которые вызывают подобные исключения. Если обработка исключений поврежденного состояния процесса совершенно необходима, напишите обработчик исключений в коде C или C++.

Категория

Основные библиотеки .NET

Затронутые API


Для свойств UriBuilder больше не добавляются начальные символы

UriBuilder.Fragment больше не добавляет начальный символ #, а UriBuilder.Query больше не добавляет начальный символ ?, если он уже существует.

Описание изменения

В .NET Framework свойства UriBuilder.Fragment и UriBuilder.Query всегда добавляют к сохраненному значению в начале символ # или ? соответственно. Такое поведение может привести к появлению нескольких символов # или ? в сохраненном значении, если строка уже содержит один из этих начальных символов. Например, значение UriBuilder.Fragment может стать ##main.

Начиная с .NET Core 1.0 эти свойства больше не добавляют начальные символы # или ? к сохраненному значению, если в начале строки уже есть начальный символ.

Представленные версии

1.0

При задании значений свойств больше не нужно явно удалять эти начальные символы. Это особенно полезно при добавлении значений, так как больше не нужно каждый раз удалять начальные символы # или ?.

Например, в следующем фрагменте кода показано различие в поведении между .NET Framework и .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);
  • В .NET Framework выходными данными будет ????one=1&two=2&three=3&four=4.
  • В .NET Core выходными данными будет ?one=1&two=2&three=3&four=4.

Категория

Основные библиотеки .NET

Затронутые API


Process.StartInfo выдает исключение InvalidOperationException для процессов, которые не были запущены

Чтение свойства Process.StartInfo для процессов, которые не были запущены кодом, приводит к возникновению InvalidOperationException.

Описание изменения

В .NET Framework обращение к свойству Process.StartInfo для процессов, которые не были запущены кодом, возвращает пустой объект ProcessStartInfo. Пустой объект содержит значения по умолчанию для всех его свойств, кроме EnvironmentVariables.

Начиная с .NET Core 1.0, при чтении свойства Process.StartInfo для процесса, который не был запущен (путем вызова Process.Start) возникает исключение InvalidOperationException.

Представленные версии

1.0

Не обращайтесь к свойству Process.StartInfo для процессов, которые не были запущены кодом. Например, не считывайте это свойство для процессов, возвращаемых Process.GetProcesses.

Категория

Основные библиотеки .NET

Затронутые API