Критические изменения для миграции с .NET Framework на .NET CoreBreaking changes for migration from .NET Framework to .NET Core

Если вы переносите приложение с .NET Framework на .NET Core версий 1.0–3.1, критические изменения, перечисленные в этой статье, могут повлиять на работу приложения.If you're migrating an app from .NET Framework to .NET Core versions 1.0 through 3.1, the breaking changes listed in this article may affect you. Критические изменения сгруппированы по категориям, а в этих категориях — по версии .NET Core, в которых они были представлены.Breaking changes are grouped by category, and within those categories, by the version of .NET Core in which they were introduced.

Примечание

Эта статья не является исчерпывающим списком критических изменений между .NET Framework и .NET Core.This article is not a complete list of breaking changes between .NET Framework and .NET Core. Здесь добавляются самые важные критические изменения, как только мы о них узнаем.The most important breaking changes are added here as we become aware of them.

Библиотеки Core .NETCore .NET libraries

.NET Core 2.1.NET Core 2.1

Изменение значения по умолчанию для UseShellExecuteChange in default value of UseShellExecute

ProcessStartInfo.UseShellExecute имеет значение false по умолчанию в .NET Core.ProcessStartInfo.UseShellExecute has a default value of false on .NET Core. В .NET Framework его значение по умолчанию — true.On .NET Framework, its default value is true.

Описание измененийChange description

Process.Start позволяет запускать приложение напрямую, например с помощью кода, как Process.Start("mspaint.exe"), запускающего Paint.Process.Start lets you launch an application directly, for example, with code such as Process.Start("mspaint.exe") that launches Paint. Это также позволяет косвенно запускать связанное приложение, если для ProcessStartInfo.UseShellExecute установлено значение true.It also lets you indirectly launch an associated application if ProcessStartInfo.UseShellExecute is set to true. В .NET Framework значением по умолчанию для ProcessStartInfo.UseShellExecute является true, что означает, что такой код как Process.Start("mytextfile.txt") будет запускать Блокнот, если вы связали файлы .txt с этим редактором.On .NET Framework, the default value for ProcessStartInfo.UseShellExecute is true, meaning that code such as Process.Start("mytextfile.txt") would launch Notepad, if you've associated .txt files with that editor. Чтобы предотвратить косвенный запуск приложения на .NET Framework, необходимо явно установить false на ProcessStartInfo.UseShellExecute.To prevent indirectly launching an app on .NET Framework, you must explicitly set ProcessStartInfo.UseShellExecute to false. В .NET Core значением по умолчанию для ProcessStartInfo.UseShellExecute является значение false.On .NET Core, the default value for ProcessStartInfo.UseShellExecute is false. Это означает, что связанные по умолчанию приложения не запускаются при вызове Process.Start.This means that, by default, associated applications are not launched when you call Process.Start.

Это изменение введено в .NET Core для повышения производительности.This change was introduced in .NET Core for performance reasons. Как правило, Process.Start используется для непосредственного запуска приложения.Typically, Process.Start is used to launch an application directly. Запуск приложения напрямую не требует затрагивания оболочки Windows и влечет за собой соответствующие расходы на производительность.Launching an app directly does not need to involve the Windows shell and incur the associated performance cost. Чтобы ускорить этот вариант по умолчанию, .NET Core изменяет значение по умолчанию ProcessStartInfo.UseShellExecute на false.To make this default case faster, .NET Core changes the default value of ProcessStartInfo.UseShellExecute to false. При необходимости вы можете выбрать более медленный путь.You can opt in to the slower path if you need it.

Представленная версияVersion introduced

2.12.1

Примечание

В более ранних версиях .NET Core UseShellExecute не был внедрен для Windows.In earlier versions of .NET Core, UseShellExecute was not implemented for Windows.

Если приложение полагается на прежнее поведение, вызовите Process.Start(ProcessStartInfo), указав для параметра UseShellExecute значение true в объекте ProcessStartInfo.If your app relies on the old behavior, call Process.Start(ProcessStartInfo) with UseShellExecute set to true on the ProcessStartInfo object.

КатегорияCategory

Библиотеки Core .NETCore .NET libraries

Затронутые APIAffected APIs


.NET Core 1.0.NET Core 1.0

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

В .NET Core UnauthorizedAccessException возникает, когда вызывающий пытается задать значение атрибута файла, но у него нет разрешений на запись.In .NET Core, an UnauthorizedAccessException is thrown when the caller attempts to set a file attribute value but doesn't have write permission.

Описание измененийChange description

В .NET Framework ArgumentException возникает, когда вызывающий пытается задать значение атрибута файла в FileSystemInfo.Attributes, но у него нет разрешений на запись.In .NET Framework, an ArgumentException is thrown when the caller attempts to set a file attribute value in FileSystemInfo.Attributes but doesn't have write permission. В .NET Core вместо него возникает UnauthorizedAccessExceptionIn .NET Core, an UnauthorizedAccessException is thrown instead. (в .NET Core ArgumentException по-прежнему возникает, если вызывающий пытается задать недопустимый атрибут файла).(In .NET Core, an ArgumentException is still thrown if the caller attempts to set an invalid file attribute.)

Представленная версияVersion introduced

1.01.0

Изменяйте любые инструкции catch, чтобы получить UnauthorizedAccessException вместо или в дополнение к ArgumentException по мере необходимости.Modify any catch statements to catch an UnauthorizedAccessException instead of, or in addition to, an ArgumentException, as necessary.

КатегорияCategory

Библиотеки Core .NETCore .NET libraries

Затронутые APIAffected APIs


Обработка исключений поврежденного состояния не поддерживаетсяHandling corrupted state exceptions is not supported

Обработка исключений поврежденного состояния в .NET Core не поддерживается.Handling corrupted-process-state exceptions in .NET Core is not supported.

Описание измененийChange description

Ранее исключения поврежденного состояния процесса могли быть перехвачены и обработаны обработчиками исключений управляемого кода, например с помощью инструкции try-catch в C#.Previously, corrupted-process-state exceptions could be caught and handled by managed code exception handlers, for example, by using a try-catch statement in C#.

Начиная с .NET Core 1.0 исключения поврежденного состояния процесса не могут обрабатываться управляемым кодом.Starting in .NET Core 1.0, corrupted-process-state exceptions cannot be handled by managed code. Среда CLR не доставляет исключения поврежденного состояния процесса в управляемый код.The common language runtime doesn't deliver corrupted-process-state exceptions to managed code.

Представленная версияVersion introduced

1.01.0

Старайтесь исключить потребность в обработке исключений поврежденного состояния процесса, устраняя ситуации, которые вызывают подобные исключения.Avoid the need to handle corrupted-process-state exceptions by addressing the situations that lead to them instead. Если обработка исключений поврежденного состояния процесса совершенно необходима, напишите обработчик исключений в коде C или C++.If it's absolutely necessary to handle corrupted-process-state exceptions, write the exception handler in C or C++ code.

КатегорияCategory

Библиотеки Core .NETCore .NET libraries

Затронутые APIAffected APIs


Для свойств UriBuilder больше не добавляются начальные символыUriBuilder properties no longer prepend leading characters

UriBuilder.Fragment больше не добавляет начальный символ #, а UriBuilder.Query больше не добавляет начальный символ ?, если он уже существует.UriBuilder.Fragment no longer prepends a leading # character and UriBuilder.Query no longer prepends a leading ? character when one is already present.

Описание измененийChange description

В .NET Framework свойства UriBuilder.Fragment и UriBuilder.Query всегда добавляют к сохраненному значению в начале символ # или ? соответственно.In .NET Framework, the UriBuilder.Fragment and UriBuilder.Query properties always prepend a # or ? character, respectively, to the value being stored. Такое поведение может привести к появлению нескольких символов # или ? в сохраненном значении, если строка уже содержит один из этих начальных символов.This behavior can result in multiple # or ? characters in the stored value if the string already contains one of these leading characters. Например, значение UriBuilder.Fragment может стать ##main.For example, the value of UriBuilder.Fragment might become ##main.

Начиная с .NET Core 1.0 эти свойства больше не добавляют начальные символы # или ? к сохраненному значению, если в начале строки уже есть начальный символ.Starting in .NET Core 1.0, these properties no longer prepend the # or ? characters to the stored value if one is already present at the beginning of the string.

Представленная версияVersion introduced

1.01.0

При задании значений свойств больше не нужно явно удалять эти начальные символы.You no longer need to explicitly remove any of these leading characters when setting the property values. Это особенно полезно при добавлении значений, так как больше не нужно каждый раз удалять начальные символы # или ?.This is especially useful when you're appending values, because you no longer have to remove the leading # or ? each time you append.

Например, в следующем фрагменте кода показано различие в поведении между .NET Framework и .NET Core.For example, the following code snippet shows the behavior difference between .NET Framework and .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.In .NET Framework, the output is ????one=1&two=2&three=3&four=4.
  • В .NET Core выходными данными будет ?one=1&two=2&three=3&four=4.In .NET Core, the output is ?one=1&two=2&three=3&four=4.

КатегорияCategory

Библиотеки Core .NETCore .NET libraries

Затронутые APIAffected APIs


Process.StartInfo выдает исключение InvalidOperationException для процессов, которые не были запущеныProcess.StartInfo throws InvalidOperationException for processes you didn't start

Чтение свойства Process.StartInfo для процессов, которые не были запущены кодом, приводит к возникновению InvalidOperationException.Reading the Process.StartInfo property for processes that your code didn't start throws an InvalidOperationException.

Описание измененийChange description

В .NET Framework обращение к свойству Process.StartInfo для процессов, которые не были запущены кодом, возвращает пустой объект ProcessStartInfo.In .NET Framework, accessing the Process.StartInfo property for processes that your code didn't start returns a dummy ProcessStartInfo object. Пустой объект содержит значения по умолчанию для всех его свойств, кроме EnvironmentVariables.The dummy object contains default values for all of its properties except EnvironmentVariables.

Начиная с .NET Core 1.0, при чтении свойства Process.StartInfo для процесса, который не был запущен (путем вызова Process.Start) возникает исключение InvalidOperationException.Starting in .NET Core 1.0, if you read the Process.StartInfo property for a process that you didn't start (that is, by calling Process.Start), an InvalidOperationException is thrown.

Представленная версияVersion introduced

1.01.0

Не обращайтесь к свойству Process.StartInfo для процессов, которые не были запущены кодом.Do not access the Process.StartInfo property for processes that your code didn't start. Например, не считывайте это свойство для процессов, возвращаемых Process.GetProcesses.For example, don't read this property for processes returned by Process.GetProcesses.

КатегорияCategory

Библиотеки Core .NETCore .NET libraries

Затронутые APIAffected APIs


ШифрованиеCryptography

.NET Core 2.1.NET Core 2.1

Логический параметр SignedCms.ComputeSignature учитываетсяBoolean parameter of SignedCms.ComputeSignature is respected

В .NET Core учитывается логический параметр silent метода SignedCms.ComputeSignature(CmsSigner, Boolean).In .NET Core, the Boolean silent parameter of the SignedCms.ComputeSignature(CmsSigner, Boolean) method is respected. Если этот параметр имеет значение true, запрос на ввод ПИН-кода не отображается.A PIN prompt is not shown if this parameter is set to true.

Описание измененийChange description

В .NET Framework параметр silent метода SignedCms.ComputeSignature(CmsSigner, Boolean) игнорируется, и если поставщик этого требует, запрос на ввод ПИН-кода отображается всегда.In .NET Framework, the silent parameter of the SignedCms.ComputeSignature(CmsSigner, Boolean) method is ignored, and a PIN prompt is always shown if required by the provider. В .NET Core параметр silent учитывается, и если для него задано значение true, запрос на ввод ПИН-кода никогда не отображается, даже если этого требует поставщик.In .NET Core, the silent parameter is respected, and if set to true, a PIN prompt is never shown, even if it's required by the provider.

В .NET Core в версии 2.1 реализована поддержка сообщений CMS/PKCS #7.Support for CMS/PKCS #7 messages was introduced into .NET Core in version 2.1.

Представленная версияVersion introduced

2.12.1

Чтобы запрос на ввод ПИН-кода появлялся при необходимости, классические приложения должны вызывать SignedCms.ComputeSignature(CmsSigner, Boolean) и присваивать логическому параметру значение false.To ensure a PIN prompt appears if required, desktop applications should call SignedCms.ComputeSignature(CmsSigner, Boolean) and set the Boolean parameter to false. Полученное поведение аналогично поведению .NET Framework независимо от того, отключен ли в нем тихий контекст.The resulting behavior is the same as on .NET Framework regardless of whether the silent context is disabled there.

КатегорияCategory

ШифрованиеCryptography

Затронутые APIAffected APIs


MSBuildMSBuild

.NET Core 3.0.NET Core 3.0

Изменение имени файла манифеста для ресурсаResource manifest file name change

Начиная с .NET Core 3.0, в стандартных ситуациях MSBuild создает другие имена файлов манифеста для файлов ресурсов.Starting in .NET Core 3.0, in the default case, MSBuild generates a different manifest file name for resource files.

Представленная версияVersion introduced

3.03.0

Описание измененийChange description

До версии .NET Core 3.0, если для элемента EmbeddedResource в файле проекта не были указаны метаданные LogicalName, ManifestResourceNameили DependentUpon, платформа MSBuild создавала имя файла манифеста в формате <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.Prior to .NET Core 3.0, if no LogicalName, ManifestResourceName, or DependentUpon metadata was specified for an EmbeddedResource item in the project file, MSBuild generated a manifest file name in the pattern <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Если в файле проекта не определено значение RootNamespace, по умолчанию используется имя проекта.If RootNamespace is not defined in the project file, it defaults to the project name. Например, для файла ресурсов с именем Form1.resx в корневом каталоге проекта создавался манифест с именем MyProject.Form1.resources.For example, the generated manifest name for a resource file named Form1.resx in the root project directory was MyProject.Form1.resources.

Начиная с версии .NET Core 3.0, при размещении файла ресурса в одной папке с одноименным исходным файлом, (Form1.resx и Form1.cs), MSBuild использует сведения о типе из исходного файла для создания имени файла манифеста в формате <Namespace>.<ClassName>.resources.Starting in .NET Core 3.0, if a resource file is colocated with a source file of the same name (for example, Form1.resx and Form1.cs), MSBuild uses type information from the source file to generate the manifest file name in the pattern <Namespace>.<ClassName>.resources. Пространство имен и имя класса извлекаются из первого типа в исходном файле, найденном в той же папке.The namespace and class name are extracted from the first type in the colocated source file. Например, для файла ресурсов с именем Form1.resx, который расположен в одной папке с исходным файлом Form1.cs, создается манифест с именем MyNamespace.Form1.resources.For example, the generated manifest name for a resource file named Form1.resx that's colocated with a source file named Form1.cs is MyNamespace.Form1.resources. Важно отметить, что первая часть имени файла отличается от имени в прежних версиях .NET Core (MyNamespace вместо MyProject).The key thing to note is that the first part of the file name is different to prior versions of .NET Core (MyNamespace instead of MyProject).

Примечание

Если для элемента EmbeddedResource в файле проекта указаны метаданные LogicalName, ManifestResourceName или DependentUpon, это изменение не применяется к соответствующему файлу ресурсов.If you have LogicalName, ManifestResourceName, or DependentUpon metadata specified on an EmbeddedResource item in the project file, then this change does not affect that resource file.

Это критическое изменение было введено одновременно с добавлением свойства EmbeddedResourceUseDependentUponConvention для проектов .NET Core.This breaking change was introduced with the addition of the EmbeddedResourceUseDependentUponConvention property to .NET Core projects. По умолчанию файлы ресурсов не указаны явным образом в файле проекта .NET Core, поэтому в них нет метаданных DependentUpon, которые позволяют задать формат именования созданного файла .resources.By default, resource files aren't explicitly listed in a .NET Core project file, so they have no DependentUpon metadata to specify how to name the generated .resources file. Если EmbeddedResourceUseDependentUponConvention имеет значение true (используется по умолчанию), MSBuild ищет в той же папке исходный файл и извлекает из этого файла пространство имен и имя класса.When EmbeddedResourceUseDependentUponConvention is set to true, which is the default, MSBuild looks for a colocated source file and extracts a namespace and class name from that file. Если для EmbeddedResourceUseDependentUponConvention задано значение false, MSBuild создает имя манифеста по правилам для прежних версий, то есть объединяет RootNamespace и относительный путь к файлу.If you set EmbeddedResourceUseDependentUponConvention to false, MSBuild generates the manifest name according to the previous behavior, which combines RootNamespace and the relative file path.

В большинстве случаев разработчикам не нужно предпринимать по этому поводу никаких действий, и приложение должно работать нормально.In most cases, no action is required on the part of the developer, and your app should continue to work. Если же это изменение нарушит работу приложения, вы можете выполнить одно из следующих действий.However, if this change breaks your app, you can either:

  • Измените код так, чтобы он ожидал новое имя манифеста.Change your code to expect the new manifest name.

  • Откажитесь от нового соглашения об именовании, указав в файле проекта параметр EmbeddedResourceUseDependentUponConvention со значением false.Opt out of the new naming convention by setting EmbeddedResourceUseDependentUponConvention to false in your project file.

    <PropertyGroup>
      <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
    </PropertyGroup>
    

КатегорияCategory

MSBuildMSBuild

Затронутые APIAffected APIs

Н/ДN/A


СетиNetworking

.NET Core 2.0;.NET Core 2.0

WebClient.CancelAsync не всегда сразу отменяет запросWebClient.CancelAsync doesn't always cancel immediately

Начиная с .NET Core 2.0 вызов WebClient.CancelAsync() не отменяет запрос сразу, если ответ начал поступать.Starting in .NET Core 2.0, calling WebClient.CancelAsync() doesn't cancel the request immediately if the response has started to fetch.

Описание измененийChange description

Ранее вызов WebClient.CancelAsync() отменял запрос сразу.Previously, calling WebClient.CancelAsync() canceled the request immediately. Начиная с .NET Core 2.0 вызов WebClient.CancelAsync() отменяет запрос сразу, только если ответ не начал поступать.Starting in .NET Core 2.0, calling WebClient.CancelAsync() cancels the request immediately only if the response hasn't started fetching. Если ответ начал поступать, запрос отменяется только после считывания полного ответа.If the response has started to fetch, the request is cancelled only after a complete response is read.

Это изменение было реализовано, так как API WebClient является нерекомендуемым и заменен на HttpClient.This change was implemented because the WebClient API is deprecated in favor of HttpClient.

Представленная версияVersion introduced

2.02.0

Используйте класс System.Net.Http.HttpClient вместо System.Net.WebClient, который является нерекомендуемым.Use the System.Net.Http.HttpClient class instead of System.Net.WebClient, which is deprecated.

КатегорияCategory

СетиNetworking

Затронутые APIAffected APIs


Windows FormsWindows Forms

Поддержка Windows Forms была добавлена в .NET Core в версии 3.0.Windows Forms support was added to .NET Core in version 3.0. Если вы переносите приложение Windows Forms с .NET Framework на .NET Core, критические изменения, перечисленные здесь, могут повлиять на работу приложения.If you're migrating a Windows Forms app from .NET Framework to .NET Core, the breaking changes listed here may affect your app.

.NET Core 3.1.NET Core 3.1

Удаленные элементы управленияRemoved controls

Начиная с .NET Core 3.1, некоторые элементы управления Windows Forms больше не доступны.Starting in .NET Core 3.1, some Windows Forms controls are no longer available.

Описание измененийChange description

Начиная с .NET Core 3.1, различные элементы управления Windows Forms больше не доступны.Starting with .NET Core 3.1, various Windows Forms controls are no longer available. В .NET Framework 2.0 они были заменены элементами управления с улучшенной структурой и поддержкой.Replacement controls that have better design and support were introduced in .NET Framework 2.0. Нерекомендуемые элементы управления были ранее удалены из панелей элементов конструктора, но по-прежнему были доступны для использования.The deprecated controls were previously removed from designer toolboxes but were still available to be used.

Следующие типы больше не доступны.The following types are no longer available:

Представленная версияVersion introduced

3.13.1

Каждый удаленный элемент управления имеет рекомендуемую замену.Each removed control has a recommended replacement control. См. таблицу ниже.Refer to the following table:

Удаленный элемент управления (API)Removed control (API) Рекомендуемая заменаRecommended replacement Связанные удаленные интерфейсы APIAssociated APIs that are removed
ContextMenuContextMenu ContextMenuStripContextMenuStrip
DataGridDataGrid DataGridViewDataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestTypeDataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenuMainMenu MenuStripMenuStrip
МенюMenu ToolStripDropDown, ToolStripDropDownMenuToolStripDropDown, ToolStripDropDownMenu MenuItemCollectionMenuItemCollection
MenuItemMenuItem ToolStripMenuItemToolStripMenuItem
ToolBarToolBar ToolStripToolStrip ToolBarAppearanceToolBarAppearance
ToolBarButtonToolBarButton ToolStripButtonToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlignToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Событие CellFormatting не возникает при отображении подсказкиCellFormatting event not raised if tooltip is shown

DataGridView теперь отображает всплывающие подсказки для ошибок и текста в ячейке при наведении указателя мыши и при выборе с помощью клавиатуры.A DataGridView now shows a cell's text and error tooltips when hovered by a mouse and when selected via the keyboard. Если подсказка отображается, событие DataGridView.CellFormatting не возникает.If a tooltip is shown, the DataGridView.CellFormatting event is not raised.

Описание измененийChange description

До .NET Core 3.1 DataGridView, у которого для свойства ShowCellToolTips было задано значение true, отображал подсказку для ошибок и текста в ячейке при наведении указателя мыши на эту ячейку.Prior to .NET Core 3.1, a DataGridView that had the ShowCellToolTips property set to true showed a tooltip for a cell's text and errors when the cell was hovered by a mouse. Подсказки не отображались при выборе ячейки с помощью клавиатуры (например, с помощью клавиши TAB, сочетаний клавиш или клавиш со стрелками).Tooltips were not shown when a cell was selected via the keyboard (for example, by using the Tab key, shortcut keys, or arrow navigation). Если пользователь изменил ячейку, а затем, пока DataGridView находился в режиме редактирования, навел указатель на ячейку, для которой не задано свойство ToolTipText, возникало событие CellFormatting для форматирования текста ячейки, отображаемого в ней.If the user edited a cell, and then, while the DataGridView was still in edit mode, hovered over a cell that did not have the ToolTipText property set, a CellFormatting event was raised to format the cell's text for display in the cell.

Чтобы удовлетворить требованиям стандартов специальных возможностей, начиная с .NET Core 3.1, DataGridView, у которого для свойства ShowCellToolTips задано значение true, отображает подсказки для ошибок и текста ячейки не только при наведении указателя мыши, но и при выборе ячейки с помощью клавиатуры.To meet accessibility standards, starting in .NET Core 3.1, a DataGridView that has the ShowCellToolTips property set to true shows tooltips for a cell's text and errors not only when the cell is hovered, but also when it's selected via the keyboard. Как следствие этого изменения событие CellFormattingне возникает, когда указатель наводится на ячейки, для которых не задано свойство ToolTipText, пока DataGridView находится в режиме редактирования.As a consequence of this change, the CellFormatting event is not raised when cells that don't have the ToolTipText property set are hovered while the DataGridView is in edit mode. Событие не возникает, так как содержимое ячейки, на которую наведен указатель, выводится в виде подсказки, а не отображается в ячейке.The event is not raised because the content of the hovered cell is shown as a tooltip instead of being displayed in the cell.

Представленная версияVersion introduced

3.13.1

Выполните рефакторинг всего кода, зависящего от события CellFormatting, когда DataGridView находится в режиме редактирования.Refactor any code that depends on the CellFormatting event while the DataGridView is in edit mode.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

ОтсутствуютNone


.NET Core 3.0.NET Core 3.0

Шрифт элемента управления по умолчанию изменен на Segoe UI 9 птDefault control font changed to Segoe UI 9 pt

Описание измененийChange description

В .NET Framework свойству Control.DefaultFont присвоено значение Microsoft Sans Serif 8 pt.In .NET Framework, the Control.DefaultFont property was set to Microsoft Sans Serif 8 pt. На следующем рисунке показано окно, в котором используется шрифт по умолчанию.The following image shows a window that uses the default font.

Шрифт по умолчанию для элемента управления в .NET Framework

Начиная с .NET Core 3.0 шрифтом по умолчанию является Segoe UI 9 pt (тот же шрифт, что и SystemFonts.MessageBoxFont).Starting in .NET Core 3.0, the default font is set to Segoe UI 9 pt (the same font as SystemFonts.MessageBoxFont). В результате этого изменения размер форм и элементов управления увеличен на 27 % с учетом увеличенного размера нового шрифта по умолчанию.As a result of this change, forms and controls are sized about 27% larger to account for the larger size of the new default font. Пример:For example:

Шрифт по умолчанию для элемента управления в .NET Core

Это изменение было внесено в соответствии с рекомендациями по пользовательскому интерфейсу Windows.This change was made to align with Windows user experience (UX) guidelines.

Представленная версияVersion introduced

3,03.0

Так как размер форм и элементов управления изменился, убедитесь, что приложение отображается правильно.Because of the change in the size of forms and controls, ensure that your application renders correctly.

Чтобы оставить исходный шрифт, задайте для формы шрифт по умолчанию: Microsoft Sans Serif 8 pt.To retain the original font, set your form's default font to Microsoft Sans Serif 8 pt. Пример:For example:

public MyForm()
{
    InitializeComponent();
    Font = new Font(new FontFamily("Microsoft Sans Serif"), 8f);
}

КатегорияCategory

  • Windows FormsWindows Forms

Затронутые APIAffected APIs

Нет.None.


Модернизация FolderBrowserDialogModernization of the FolderBrowserDialog

В приложениях Windows Forms для .NET Core в элемент управления FolderBrowserDialog внесены изменения.The FolderBrowserDialog control has changed in Windows Forms applications for .NET Core.

Описание измененийChange description

В Windows Forms в .NET Framework для элемента управления FolderBrowserDialog используется следующее диалоговое окно:In the .NET Framework, Windows forms uses the following dialog for the FolderBrowserDialog control:

FolderBrowserDialogControl в .NET Framework

В .NET Core 3.0 в Windows Forms используется более новый элемент управления на основе COM, появившийся в Windows Vista:In .NET Core 3.0, Windows Forms users a newer COM-based control that was introduced in Windows Vista:

FolderBrowserDialogControl в .NET Core

Представленная версияVersion introduced

3,03.0

Диалоговое окно будет обновлено автоматически.The dialog will be upgraded automatically.

Если вы хотите оставить исходное диалоговое окно, перед отображением диалогового окна задайте для свойства FolderBrowserDialog.AutoUpgradeEnabled значение false, как показано в следующем фрагменте кода:If you desire to retain the original dialog, set the FolderBrowserDialog.AutoUpgradeEnabled property to false before showing the dialog, as illustrated by the following code fragment:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Атрибут SerializableAttribute удален из некоторых типов Windows FormsSerializableAttribute removed from some Windows Forms types

Атрибут SerializableAttribute был удален из некоторых классов Windows Forms, для которых нет известных сценариев двоичной сериализации.The SerializableAttribute has been removed from some Windows Forms classes that have no known binary serialization scenarios.

Описание измененийChange description

Следующие типы помечаются в .NET Framework атрибутом SerializableAttribute, который удален в .NET Core:The following types are decorated with the SerializableAttribute in .NET Framework, but the attribute has been removed in .NET Core:

Механизм сериализации всегда имел серьезные проблемы в плане обслуживания и безопасности.Historically, this serialization mechanism has had serious maintenance and security concerns. Поддержка SerializableAttribute для типов означает, что их необходимо проверять на наличие изменений сериализации в разных версиях, а также, возможно, на разных платформах.Maintaining SerializableAttribute on types means those types must be tested for version-to-version serialization changes and potentially framework-to-framework serialization changes. Это затрудняет развитие таких типов и делает их обслуживание затратнее.This makes it harder to evolve those types and can be costly to maintain. Для этих типов нет известных сценариев двоичной сериализации, благодаря чему удаление атрибута имеет минимальные последствия.These types have no known binary serialization scenarios, which minimizes the impact of removing the attribute.

Дополнительные сведения см. в разделе Двоичная сериализация.For more information, see Binary serialization.

Представленная версияVersion introduced

3.03.0

Измените код, работа которого зависит от возможности сериализации этих типов.Update any code that may depend on these types being marked as serializable.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

  • NoneNone

Параметр совместимости AllowUpdateChildControlIndexForTabControls не поддерживаетсяAllowUpdateChildControlIndexForTabControls compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls поддерживается в Windows Forms в .NET Framework 4.6 и более поздних версиях, но не поддерживается в .NET Core,а также в .NET Core 5.0 и более поздних версий.The Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls compatibility switch is supported in Windows Forms on .NET Framework 4.6 and later versions but is not supported on .NET Core or .NET 5.0 and later.

Описание измененийChange description

В .NET Framework 4.6 и более поздних версиях при выборе вкладки ее коллекция элементов управления переупорядочивается.In .NET Framework 4.6 and later versions, selecting a tab reorders its control collection. Параметр совместимости Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls позволяет приложению отменить переупорядочивание, если оно не требуется.The Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls compatibility switch allows an application to skip this reordering when this behavior is undesirable.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

  • NoneNone

Параметр совместимости DomainUpDown.UseLegacyScrolling не поддерживаетсяDomainUpDown.UseLegacyScrolling compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling, появившийся в .NET Framework 4.7.1, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling compatibility switch, which was introduced in .NET Framework 4.7.1, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.

Описание измененийChange description

Начиная с версии .NET Framework 4.7.1 параметр совместимости Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling позволял разработчикам отказаться от независимых действий DomainUpDown.DownButton() и DomainUpDown.UpButton().Starting with .NET Framework 4.7.1, the Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling compatibility switch allowed developers to opt-out of independent DomainUpDown.DownButton() and DomainUpDown.UpButton() actions. Параметр восстанавливал прежнее поведение, при котором действие DomainUpDown.UpButton() игнорируется, если присутствует текст контекста, и разработчику необходимо использовать действие DomainUpDown.DownButton() для элемента управления перед использованием действия DomainUpDown.UpButton().The switch restored the legacy behavior, in which the DomainUpDown.UpButton() is ignored if context text is present, and the developer is required to use DomainUpDown.DownButton() action on the control before the DomainUpDown.UpButton() action. Дополнительные сведения см. в разделе Элемент <AppContextSwitchOverrides>.For more information, see <AppContextSwitchOverrides> element.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Параметр совместимости DoNotLoadLatestRichEditControl не поддерживаетсяDoNotLoadLatestRichEditControl compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.UseLegacyImages, появившийся в .NET Framework 4.7.1, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.UseLegacyImages compatibility switch, which was introduced in .NET Framework 4.7.1, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.

Описание измененийChange description

В .NET Framework 4.6.2 и предыдущих версиях элемент управления RichTextBox создает экземпляр элемента управления Win32 RichEdit версии 3.0, а для приложений, предназначенных для .NET Framework 4.7.1, элемент управления RichTextBox создает экземпляр элемента управления RichEdit версии 4.1 (в msftedit.dll).In .NET Framework 4.6.2 and previous versions, the RichTextBox control instantiates the Win32 RichEdit control v3.0, and for applications that target .NET Framework 4.7.1, the RichTextBox control instantiates RichEdit v4.1 (in msftedit.dll). Параметр совместимости Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl был введен для того, чтобы в приложениях, предназначенных для .NET Framework 4.7.1 и более поздних версий, можно было отказаться от использования нового элемента управления RichEdit версии 4.1 и использовать вместо него прежнюю версию 3.The Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl compatibility switch was introduced to allow applications that target .NET Framework 4.7.1 and later versions to opt out of the new RichEdit v4.1 control and use the old RichEdit v3 control instead.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl не поддерживается.In .NET Core and .NET 5.0 and later versions, the Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl switch is not supported. Поддерживаются только новые версии элемента управления RichTextBox.Only new versions of the RichTextBox control are supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Параметр совместимости DoNotSupportSelectAllShortcutInMultilineTextBox не поддерживаетсяDoNotSupportSelectAllShortcutInMultilineTextBox compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox, появившийся в .NET Framework 4.6.1, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox compatibility switch, which was introduced in .NET Framework 4.6.1, is not supported in Windows Forms on .NET Core and .NET 5.0 and later.

Описание измененийChange description

Начиная с .NET Framework 4.6.1, при нажатии клавиш CTRL + A в элементе управления TextBox выделяется весь текст.Starting with .NET Framework 4.6.1, selecting the Ctrl + A shortcut key in a TextBox control selected all text. В .NET Framework 4.6 и более ранних версиях при нажатии клавиш CTRL + A выделение всего текста не происходило, если свойства Textbox.ShortcutsEnabled и TextBox.Multiline имели значение true.In .NET Framework 4.6 and previous versions, selecting the Ctrl + A shortcut key failed to select all text if the Textbox.ShortcutsEnabled and TextBox.Multiline properties were both set to true. Параметр совместимости Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox появился в .NET Framework 4.6.1 для восстановления прежнего поведения.The Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox compatibility switch was introduced in .NET Framework 4.6.1 to retain the original behavior. Дополнительные сведения см. в разделе TextBox.ProcessCmdKey.For more information see TextBox.ProcessCmdKey.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox не поддерживается.In .NET Core and .NET 5.0 and later versions, the Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

  • NoneNone

Параметр совместимости DontSupportReentrantFilterMessage не поддерживаетсяDontSupportReentrantFilterMessage compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.DontSupportReentrantFilterMessage, появившийся в .NET Framework 4.6.1, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.DontSupportReentrantFilterMessage compatibility switch, which was introduced in .NET Framework 4.6.1, is not supported in Windows Forms on .NET Core and .NET 5.0 and later.

Описание измененийChange description

Начиная с .NET Framework 4.6.1, параметр совместимости Switch.System.Windows.Forms.DontSupportReentrantFilterMessage устраняет возможные исключения IndexOutOfRangeException при вызове сообщения Application.FilterMessage с пользовательской реализацией IMessageFilter.PreFilterMessage.Starting with the .NET Framework 4.6.1, the Switch.System.Windows.Forms.DontSupportReentrantFilterMessage compatibility switch addresses possible IndexOutOfRangeException exceptions when the Application.FilterMessage message is called with a custom IMessageFilter.PreFilterMessage implementation. Дополнительные сведения см. в разделе Устранение рисков: пользовательские реализации IMessageFilter.PreFilterMessage.For more information, see Mitigation: Custom IMessageFilter.PreFilterMessage Implementations.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.DontSupportReentrantFilterMessage не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.DontSupportReentrantFilterMessage switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Параметр совместимости EnableVisualStyleValidation не поддерживаетсяEnableVisualStyleValidation compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.EnableVisualStyleValidation не поддерживается в Windows Forms в .NET Core или .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.EnableVisualStyleValidation compatibility switch is not supported in Windows Forms on .NET Core or .NET 5.0 and later.

Описание измененийChange description

В .NET Framework параметр совместимости Switch.System.Windows.Forms.EnableVisualStyleValidation позволял приложению отказаться от проверки визуальных стилей, предоставленных в числовой форме.In .NET Framework, the Switch.System.Windows.Forms.EnableVisualStyleValidation compatibility switch allowed an application to opt out of validation of visual styles supplied in a numeric form.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.EnableVisualStyleValidation не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.EnableVisualStyleValidation switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

  • NoneNone

Параметр совместимости UseLegacyContextMenuStripSourceControlValue не поддерживаетсяUseLegacyContextMenuStripSourceControlValue compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue, появившийся в .NET Framework 4.7.2, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue compatibility switch, which was introduced in .NET Framework 4.7.2, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.

Описание измененийChange description

Начиная с версии .NET Framework 4.7.2 параметр совместимости Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue позволяет разработчикам отказаться от нового поведения свойства ContextMenuStrip.SourceControl, которое теперь возвращает ссылку на систему управления версиями.Starting with .NET Framework 4.7.2, the Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue compatibility switch allows the developer to opt out of the new behavior of the ContextMenuStrip.SourceControl property, which now returns a reference to the source control. Ранее это свойство возвращало null.The previous behavior of the property was to return null. Дополнительные сведения см. в разделе Элемент <AppContextSwitchOverrides>.For more information, see <AppContextSwitchOverrides> element.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs


Параметр совместимости UseLegacyImages не поддерживаетсяUseLegacyImages compatibility switch not supported

Параметр совместимости Switch.System.Windows.Forms.UseLegacyImages, появившийся в .NET Framework 4.8, не поддерживается в Windows Forms в .NET Core и .NET 5.0 и более поздних версий.The Switch.System.Windows.Forms.UseLegacyImages compatibility switch, which was introduced in .NET Framework 4.8, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.

Описание измененийChange description

Начиная с .NET Framework 4.8 параметр совместимости Switch.System.Windows.Forms.UseLegacyImages устраняет возможные проблемы с масштабированием изображений в сценариях ClickOnce в средах с высоким DPI.Starting with .NET Framework 4.8, the Switch.System.Windows.Forms.UseLegacyImages compatibility switch addressed possible image scaling issues in ClickOnce scenarios in high DPI environments. Если задано значение true, параметр позволяет пользователю восстановить прежний способ масштабирования изображений при высоком уровне DPI, когда масштаб составляет более 100 %.When set to true, the switch allows the user to restore legacy image scaling on high DPI displays whose scale is set to greater than 100%. Дополнительные сведения см. в заметках о выпуске .NET Framework 4.8 в GitHub.For more information, see .NET Framework 4.8 Release Notes on GitHub.

В .NET Core и .NET 5.0 и более поздних версий параметр Switch.System.Windows.Forms.UseLegacyImages не поддерживается.In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.UseLegacyImages switch is not supported.

Представленная версияVersion introduced

3.03.0

Удалите параметр.Remove the switch. Он не поддерживается, и альтернативного варианта нет.The switch is not supported, and no alternative functionality is available.

КатегорияCategory

Windows FormsWindows Forms

Затронутые APIAffected APIs

  • NoneNone

См. такжеSee also