Cambios importantes para la migración desde .NET Framework a .NET Core

  • Artículo

Si va a migrar una aplicación desde .NET Framework a las versiones de 1.0 a 3.1 de .NET Core, los cambios más importantes que se enumeran en este artículo pueden afectarle. Los cambios importantes se agrupan por categoría y, dentro de esas categorías, por la versión de .NET Core en la que se realizaron.

Nota

Este artículo no es una lista completa de los cambios importantes entre .NET Framework y .NET Core. Aquí se agregan los principales cambios importantes a medida que se conocen.

Bibliotecas de Core .NET

.NET 8

Se ha quitado la API IDispatchImplAttribute

.NET Core 2.1

Cambio del valor predeterminado de UseShellExecute

ProcessStartInfo.UseShellExecute tiene un valor predeterminado de false en .NET Core. En .NET Framework, su valor predeterminado es true.

Descripción del cambio

Process.Start permite iniciar una aplicación directamente, por ejemplo, con código como Process.Start("mspaint.exe") que inicia Paint. También permite iniciar indirectamente una aplicación asociada si ProcessStartInfo.UseShellExecute se establece en true. En .NET Framework, el valor predeterminado de ProcessStartInfo.UseShellExecute es true, lo que significa que código como Process.Start("mytextfile.txt") iniciaría el Bloc de notas, si ha asociado archivos .txt con ese editor. Para evitar el inicio indirecto de una aplicación en .NET Framework, debe establecer explícitamente ProcessStartInfo.UseShellExecute en false. En .NET Core, el valor predeterminado de ProcessStartInfo.UseShellExecute es false. Esto significa que, de forma predeterminada, las aplicaciones asociadas no se inician cuando se llama a Process.Start.

Las siguientes propiedades de System.Diagnostics.ProcessStartInfo solo funcionan cuando ProcessStartInfo.UseShellExecute es true:

Este cambio se introdujo en .NET Core por motivos de rendimiento. Normalmente, Process.Start se usa para iniciar una aplicación directamente. Iniciar una aplicación directamente no implica el uso del shell de Windows e incurrir en el costo de rendimiento asociado. Para que este caso predeterminado sea más rápido, .NET Core cambia el valor predeterminado de ProcessStartInfo.UseShellExecute por false. Puede optar por la ruta de acceso más lenta si lo necesita.

Versión introducida

2.1

Nota

En versiones anteriores de .NET Core, no se implementaba UseShellExecute para Windows.

Si la aplicación se basa en el comportamiento anterior, llame a Process.Start(ProcessStartInfo) con UseShellExecute establecido en true en el objeto ProcessStartInfo.

Categoría

Bibliotecas de Core .NET

API afectadas

.NET Core 1.0

UnauthorizedAccessException producida por FileSystemInfo.Attributes

En .NET Core, se produce una UnauthorizedAccessException si el autor de la llamada intenta establecer un valor de atributo de archivo pero no tiene permiso de escritura.

Descripción del cambio

En .NET Framework, se produce una ArgumentException si el autor de la llamada intenta establecer un valor de atributo de archivo en FileSystemInfo.Attributes pero no tiene permiso de escritura. En .NET Core, se produce una UnauthorizedAccessException en su lugar. (En .NET Core, se sigue produciendo una ArgumentException si el autor de la llamada intenta establecer un atributo de archivo no válido).

Versión introducida

1.0

Modifique las instrucciones catch para capturar una UnauthorizedAccessException en lugar de una ArgumentException, o además de esta, según sea necesario.

Categoría

Bibliotecas de Core .NET

API afectadas

No se admite el control de excepciones de estado dañado

No se admite el control de excepciones de estado de proceso dañado en .NET Core.

Descripción del cambio

Anteriormente, las excepciones de estado de proceso dañado podían detectarse y controlarse mediante controladores de excepciones de código administrado, por ejemplo, al usar una instrucción try-catch en C#.

A partir de .NET Core 1.0, las excepciones de estado de proceso dañado no se pueden controlar mediante código administrado. Common Language Runtime no entrega las excepciones de estado de proceso dañado al código administrado.

Versión introducida

1.0

Para no tener que controlar las excepciones de estado de proceso dañado, aborde las situaciones que conducen a ellas. Si es absolutamente necesario controlar las excepciones de estado de proceso dañado, escriba el controlador de excepciones en código de C o C++.

Categoría

Bibliotecas de Core .NET

API afectadas

Las propiedades UriBuilder ya no anteponen caracteres iniciales

UriBuilder.Fragment ya no antepone un carácter # inicial y UriBuilder.Query ya no antepone un carácter ? inicial si ya existe uno.

Descripción del cambio

En .NET Framework, las propiedades UriBuilder.Fragment y UriBuilder.Query siempre anteponen un carácter # o ?, respectivamente, al valor que se va a almacenar. Este comportamiento puede producir varios caracteres # o ? en el valor almacenado si la cadena ya contiene uno de estos caracteres iniciales. Por ejemplo, el valor de UriBuilder.Fragment podría convertirse en ##main.

A partir de .NET Core 1.0, estas propiedades ya no anteponen los caracteres # o ? al valor almacenado si ya hay uno presente al principio de la cadena.

Versión introducida

1.0

Ya no es necesario quitar explícitamente ninguno de estos caracteres iniciales al establecer los valores de propiedad. Esto es especialmente útil cuando se anexan valores, puesto que ya no es necesario quitar los caracteres # iniciales o ? al anexar.

Por ejemplo, en el siguiente fragmento de código puede verse la diferencia de comportamiento entre .NET Framework y .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);
  • En .NET Framework, el resultado es ????one=1&two=2&three=3&four=4.
  • En .NET Core, el resultado es ?one=1&two=2&three=3&four=4.

Categoría

Bibliotecas de Core .NET

API afectadas

Process.StartInfo produce una excepción InvalidOperationException para los procesos que no se iniciaron

Al leer la propiedad Process.StartInfo de los procesos que el código no ha iniciado, se produce una excepción InvalidOperationException.

Descripción del cambio

En .NET Framework, el acceso a la propiedad Process.StartInfo para los procesos que el código no inició devuelve un objeto ProcessStartInfo ficticio. El objeto ficticio contiene los valores predeterminados de todas sus propiedades excepto EnvironmentVariables.

A partir de .NET Core 1,0, si lee la propiedad Process.StartInfo de un proceso que no se inició (es decir, mediante la llamada a Process.Start), se produce una excepción InvalidOperationException.

Versión introducida

1.0

No acceda a la propiedad Process.StartInfo de los procesos que el código no ha iniciado. Por ejemplo, no lea esta propiedad de los procesos devueltos por Process.GetProcesses.

Categoría

Bibliotecas de Core .NET

API afectadas

Criptografía

.NET Core 2.1

Se respeta el parámetro booleano de SignedCms.ComputeSignature

En .NET Core, se respeta el parámetro booleano silent del método SignedCms.ComputeSignature(CmsSigner, Boolean). No se muestra una solicitud de PIN si este parámetro se establece en true.

Descripción del cambio

En .NET Framework, se omite el parámetro silent del método SignedCms.ComputeSignature(CmsSigner, Boolean) y siempre se muestra una solicitud de PIN si lo exige el proveedor. En .NET Core, se respeta el parámetro silent y, si se establece en true, nunca se muestra una solicitud de PIN, aunque lo exija el proveedor.

La compatibilidad con los mensajes CMS/PKCS #7 se presentó en .NET Core en la versión 2.1.

Versión introducida

2.1

Para asegurarse de que aparece una solicitud de PIN si esta se exige, las aplicaciones de escritorio deben llamar a SignedCms.ComputeSignature(CmsSigner, Boolean) y establecer el parámetro booleano en false. El comportamiento resultante es el mismo que en .NET Framework independientemente de si el contexto silencioso está deshabilitado.

Categoría

Criptografía

API afectadas

MSBuild

.NET Core 3.0

Cambio de nombre de archivo de manifiesto del recurso

A partir de .NET Core 3.0, en el caso predeterminado, MSBuild genera un nombre de archivo de manifiesto diferente para los archivos de recursos.

Versión introducida

3.0

Descripción del cambio

Antes de .NET Core 3.0, si no se especificaban los metadatos LogicalName, ManifestResourceName o DependentUpon para un elemento de EmbeddedResource del archivo del proyecto, MSBuild generaba un nombre de archivo de manifiesto con el patrón <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Si RootNamespace no está definido en el archivo del proyecto, se toma como valor predeterminado el nombre del proyecto. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx en el directorio raíz del proyecto era suproject.Form1.Resources.

A partir de .NET Core 3.0, si un archivo de recursos está ubicado conjuntamente con un archivo de código fuente del mismo nombre (por ejemplo, Form1.resx y Form1.cs), MSBuild usa la información de tipo del archivo de código fuente para generar el nombre del archivo de manifiesto con el patrón <Namespace>.<ClassName>.resources. El espacio de nombres y el nombre de clase se extraen del primer tipo del archivo de código fuente ubicado conjuntamente. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx que se ubica conjuntamente con un archivo de código fuente denominado Form1.cs es myNameSpace.Form1.Resources. Lo más importante que hay que tener en cuenta es que la primera parte del nombre de archivo es diferente en versiones anteriores de .NET Core (myNameSpace en lugar de MyProject).

Nota

Si tiene los metadatos LogicalName, ManifestResourceName o DependentUpon especificados en un elemento EmbeddedResource del archivo del proyecto, este cambio no afecta a ese archivo de recursos.

Este cambio importante se presentó con la incorporación de la propiedad EmbeddedResourceUseDependentUponConvention a los proyectos de .NET Core. De forma predeterminada, los archivos de recursos no se enumeran explícitamente en un archivo de proyecto de .NET Core, por lo que no tienen metadatos DependentUpon para especificar cómo nombrar el archivo .resources generado. Cuando EmbeddedResourceUseDependentUponConvention se establece en true, que es el valor predeterminado, MSBuild busca un archivo de código fuente ubicado conjuntamente y extrae un espacio de nombres y un nombre de clase de ese archivo. Si establece EmbeddedResourceUseDependentUponConvention en false, MSBuild genera el nombre del manifiesto según el comportamiento anterior, que combina RootNamespace y la ruta de acceso relativa del archivo.

En la mayoría de los casos, no se requiere ninguna acción por parte del desarrollador y la aplicación seguirá funcionando. Sin embargo, si este cambio invalida la aplicación, puede:

  • Cambiar el código para que espere el nuevo nombre de manifiesto.

  • Rechazar la nueva convención de nomenclatura mediante el establecimiento de EmbeddedResourceUseDependentUponConvention en false en el archivo del proyecto.

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

Categoría

MSBuild

API afectadas

N/D

Redes

.NET Core 2.0

WebClient.CancelAsync no siempre se cancela inmediatamente

A partir de .NET Core 2.0, al llamar a WebClient.CancelAsync(), no se cancela inmediatamente la solicitud si la respuesta ha empezado a recuperar cambios.

Descripción del cambio

Antes, si se llamaba a WebClient.CancelAsync(), la solicitud se cancelaba inmediatamente. A partir de .NET Core 2.0, al llamar a WebClient.CancelAsync(), la solicitud se cancela inmediatamente solo si la respuesta no ha empezado a recuperar cambios. Si la respuesta ha empezado a recuperar cambios, la solicitud se cancela solo después de leer una respuesta completa.

Este cambio se implementó porque la API de WebClient quedó en desuso en favor de HttpClient.

Versión introducida

2.0

Use la clase System.Net.Http.HttpClient en lugar de System.Net.WebClient, que está en desuso.

Categoría

Redes

API afectadas

Windows Forms

Se ha agregado compatibilidad con Windows Forms a .NET Core, versión 3.0. Si va a realizar la migración de una aplicación de Windows Forms desde .NET Framework a .NET Core, los cambios más importantes que se enumeran aquí pueden afectar a los usuarios de la aplicación.

.NET Core 3.1

Controles eliminados

A partir de .NET Core 3.1, algunos controles de Windows Forms ya no están disponibles.

Descripción del cambio

A partir de .NET Core 3.1, varios controles de Windows Forms ya no están disponibles. Los controles de reemplazo, con un mejor diseño y soporte técnico, se introdujeron en .NET Framework 2.0. Los controles en desuso se eliminaron previamente de los cuadros de herramientas del diseñador, pero todavía estaban disponibles para su uso.

Los siguientes tipos ya no están disponibles:

Versión introducida

3.1

Cada control eliminado tiene un control de reemplazo recomendado. Consulte la tabla siguiente:

Control eliminado (API) Reemplazo recomendado API asociadas que se han eliminado
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menú ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Categoría

Windows Forms

API afectadas

El evento CellFormatting no se produce si se muestra información en pantalla.

Ahora, DataGridView muestra información en pantalla del texto y los errores de una celda cuando se mantiene el mouse sobre ella y cuando se selecciona mediante el teclado. Si se muestra información en pantalla, no se produce el evento DataGridView.CellFormatting.

Descripción del cambio

Antes de .NET Core 3.1, un elemento DataGridView con la propiedad ShowCellToolTips establecida en true mostraba información en pantalla del texto y los errores de una celda cuando se mantenía el mouse sobre ella. La información en pantalla no se mostraba si la celda se seleccionaba mediante el teclado (por ejemplo, mediante la tecla Tab, teclas de método abreviado o las teclas de dirección). Si el usuario editaba una celda y, luego, mientras el elemento DataGridView aún estaba en modo de edición, mantenía el mouse sobre una celda que no tenía establecida la propiedad ToolTipText, se producía un evento CellFormatting para dar formato al texto de la celda para su presentación en ella.

Para cumplir los estándares de accesibilidad, a partir de .NET Core 3.1, un elemento DataGridView que tenga la propiedad ShowCellToolTips establecida en true muestra información en pantalla del texto y los errores de una celda no solo cuando se mantiene el mouse sobre la celda, sino también cuando se selecciona mediante el teclado. Como consecuencia de este cambio, el evento CellFormattingno se produce cuando se mantiene el mouse sobre las celdas que no tienen establecida la propiedad ToolTipText mientras DataGridView está en modo de edición. El evento no se produce porque el contenido de la celda se muestra como información en pantalla en lugar de mostrarse en la celda.

Versión introducida

3.1

Refactorice cualquier código que dependa del evento CellFormatting mientras DataGridView está en modo de edición.

Categoría

Windows Forms

API afectadas

None

.NET Core 3.0

Fuente de control predeterminada cambiada a Segoe UI 9 pt

Descripción del cambio

En .NET Framework, la propiedad Control.DefaultFont estaba establecida en Microsoft Sans Serif 8 pt. En la imagen siguiente se muestra una ventana con la fuente predeterminada.

Default control font in .NET Framework

A partir de .NET Core 3.0, la fuente predeterminada está establecida en Segoe UI 9 pt (la misma fuente que SystemFonts.MessageBoxFont). Como resultado de este cambio, los formularios y los controles tienen un tamaño aproximadamente un 27 % mayor en razón del mayor tamaño de la nueva fuente predeterminada. Por ejemplo:

Default control font in .NET Core

Este cambio se ha realizado a fin de adaptarse a las directrices para la experiencia de usuario de Windows.

Versión introducida

3.0

Debido al cambio en el tamaño de los formularios y controles, asegúrese de que la aplicación se representa correctamente.

Para conservar la fuente original, establezca la fuente predeterminada del formulario en Microsoft Sans Serif 8 pt. Por ejemplo:

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

Categoría

  • Windows Forms

API afectadas

Ninguno.

Modernización de FolderBrowserDialog

El control FolderBrowserDialog ha cambiado en las aplicaciones de Windows Forms para .NET Core.

Descripción del cambio

En .NET Framework, Windows Forms utiliza el siguiente cuadro de diálogo para el control FolderBrowserDialog:

The FolderBrowserDialogControl in the .NET Framework

En .NET Core 3.0, Windows Forms usa un control basado en COM más reciente que se presentó en Windows Vista:

The FolderBrowserDialogControl in the .NET Core

Versión introducida

3.0

El cuadro de diálogo se actualizará automáticamente.

Si quiere conservar el cuadro de diálogo original, establezca la propiedad FolderBrowserDialog.AutoUpgradeEnabled en false antes de mostrar el cuadro de diálogo, tal y como se muestra en el siguiente fragmento de código:

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

Categoría

Windows Forms

API afectadas

Se ha quitado el atributo SerializableAttribute de algunos tipos de Windows Forms

El atributo SerializableAttribute se ha quitado de algunas clases de Windows Forms que no tienen ningún escenario de serialización binaria conocido.

Descripción del cambio

Los tipos siguientes se representan con el atributo SerializableAttribute en .NET Framework, pero este atributo se ha quitado en .NET Core:

Históricamente, este mecanismo de serialización ha presentado problemas graves de mantenimiento y de seguridad. Mantener el atributo SerializableAttribute en tipos significa que se deben comprobar esos tipos por si hay cambios de serialización de una versión a otra y, posiblemente, también de un marco a otro. Esto dificulta el desarrollo de esos tipos y puede requerir un mantenimiento costoso. Estos tipos no tienen ningún escenario conocido de serialización binaria, lo cual reduce el impacto de la eliminación del atributo.

Para obtener más información, vea Serialización binaria.

Versión introducida

3.0

Actualice cualquier código que pueda depender de estos tipos que están marcados como serializables.

Categoría

Windows Forms

API afectadas

  • None

No se admite el modificador de compatibilidad AllowUpdateChildControlIndexForTabControls

El modificador de compatibilidad Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls se admite en Windows Forms en .NET Framework 4.6 y versiones posteriores, pero no se admite en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

En .NET Framework 4.6 y en versiones posteriores, al seleccionar una pestaña, se reordena su colección de controles. El modificador de compatibilidad Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls permite a una aplicación omitir esta reordenación cuando no se desea este comportamiento.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

  • None

No se admite el modificador de compatibilidad DomainUpDown.UseLegacyScrolling

El modificador de compatibilidad Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling, incorporado en .NET Framework 4.7.1, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

A partir de .NET Framework 4.7.1, el modificador de compatibilidad Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling permite a los desarrolladores rechazar las acciones independientes DomainUpDown.DownButton() y DomainUpDown.UpButton(). El modificador restaura el comportamiento heredado, en el que se rechaza la acción DomainUpDown.UpButton() si hay texto de contexto, y el desarrollador debe usar la acción DomainUpDown.DownButton() en el control antes de la acción DomainUpDown.UpButton(). Para más información, consulte el elemento <AppContextSwitchOverrides>.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

No se admite el modificador de compatibilidad DoNotLoadLatestRichEditControl

El modificador de compatibilidad Switch.System.Windows.Forms.UseLegacyImages, incorporado en .NET Framework 4.7.1, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

En .NET Framework 4.6.2 y versiones anteriores, el control RichTextBox crea una instancia del control de RichEdit v3.0 de Win32 y, en las aplicaciones que tienen como destino .NET Framework 4.7.1, el control RichTextBox crea una instancia de RichEdit v4.1 (en msftedit.dll). El modificador de compatibilidad Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl se incorporó para permitir que las aplicaciones que tienen como destino .NET Framework 4.7.1 y versiones posteriores omitan el nuevo control RichEdit v4.1 y, en su lugar, usen el antiguo control RichEdit v3.

En .NET Core y .NET 5.0 y versiones posteriores no se admite el modificador Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl. Solo se admiten las nuevas versiones del control RichTextBox.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

No se admite el modificador de compatibilidad DoNotSupportSelectAllShortcutInMultilineTextBox

El modificador de compatibilidad Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox, incorporado en .NET Framework 4.6.1, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

A partir de .NET Framework 4.6.1, al seleccionar la tecla de método abreviado Ctrl + A en un control TextBox, se selecciona todo el texto. En .NET Framework 4.6 y en versiones anteriores, al seleccionar la tecla de método abreviado Ctrl + A, no se podía seleccionar todo el texto si las propiedades Textbox.ShortcutsEnabled y TextBox.Multiline estaban establecidas en true. El modificador de compatibilidad Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox se introdujo en .NET Framework 4.6.1 para conservar el comportamiento original. Para obtener más información, vea TextBox.ProcessCmdKey.

En .NET Core y .NET 5.0 y versiones posteriores no se admite el modificador Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

  • None

No se admite el modificador de compatibilidad DontSupportReentrantFilterMessage

El modificador de compatibilidad Switch.System.Windows.Forms.DontSupportReentrantFilterMessage, incorporado en .NET Framework 4.6.1, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

A partir de .NET Framework 4.6.1, el modificador de compatibilidad Switch.System.Windows.Forms.DontSupportReentrantFilterMessage soluciona las posibles excepciones IndexOutOfRangeException cuando se llama al mensaje Application.FilterMessage con una implementación personalizada de IMessageFilter.PreFilterMessage. Para más información, consulte Mitigación: personalizar implementaciones de IMessageFilter.PreFilterMessage.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.DontSupportReentrantFilterMessage.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

No se admite el modificador de compatibilidad EnableVisualStyleValidation

El modificador de compatibilidad Switch.System.Windows.Forms.EnableVisualStyleValidation no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

En .NET Framework, el modificador de compatibilidad Switch.System.Windows.Forms.EnableVisualStyleValidation permitía que una aplicación rechazara la validación de los estilos visuales proporcionados en un formato numérico.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.EnableVisualStyleValidation.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

  • None

No se admite el modificador de compatibilidad UseLegacyContextMenuStripSourceControlValue

El modificador de compatibilidad Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue, incorporado en .NET Framework 4.7.2, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

A partir de .NET Framework 4.7.2, el modificador de compatibilidad Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue permite al desarrollador omitir el nuevo comportamiento de la propiedad ContextMenuStrip.SourceControl, que ahora devuelve una referencia al control de código fuente. El comportamiento anterior de la propiedad era devolver null. Para más información, consulte el elemento <AppContextSwitchOverrides>.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

No se admite el modificador de compatibilidad UseLegacyImages

El modificador de compatibilidad Switch.System.Windows.Forms.UseLegacyImages, incorporado en .NET Framework 4.8, no se admite en Windows Forms en .NET Core ni .NET 5.0 y posterior.

Descripción del cambio

A partir de .NET Framework 4.8, el modificador de compatibilidad Switch.System.Windows.Forms.UseLegacyImages soluciona posibles problemas de escalado de imágenes en escenarios de ClickOnce en entornos con valores altos de PPP. Cuando se establece en true, el modificador permite al usuario restaurar el escalado de imágenes heredadas en pantallas con valores altos de PPP cuya escala está establecida en un valor mayor que 100 %. Para obtener más información, consulte Notas de la versión de .NET Framework 4.8 en GitHub.

En .NET Core y .NET 5.0 y posterior no se admite el modificador Switch.System.Windows.Forms.UseLegacyImages.

Versión introducida

3.0

Quite el modificador. No se admite el modificador y no hay ninguna funcionalidad alternativa disponible.

Categoría

Windows Forms

API afectadas

  • None

Las plantillas About y SplashScreen están rotas

Los archivos About.vb y SplashScreen.vb generados por Visual Studio contienen referencias a tipos en el espacio de nombres My que no están disponibles en .NET Core 3.0 y 3.1.

Versión introducida

3.0

Descripción del cambio

.NET Core 3.0 y 3.1 no contienen compatibilidad con Visual Basic My completa. Las plantillas de formulario About y SplashScreen de Visual Studio para aplicaciones de Windows Forms de Visual Basic hacen referencia a propiedades del tipo My.Application.Info que no están disponibles.

La compatibilidad con Visual Basic My se mejoró en .NET 5; actualice el proyecto a .NET 5 o versiones posteriores.

O bien

Corrija los errores del compilador en los tipos About y SplashScreen de la aplicación. Use la clase System.Reflection.Assembly para obtener la información proporcionada por el tipo My.Application.Info. Aquí hay disponible un puerto directo de ambos formularios.

Sugerencia

Se trata de código de ejemplo y no está optimizado. La lista de atributos debe almacenarse en caché para reducir el tiempo de carga del formulario.

Acerca de

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

SplashScreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Category

Windows Forms de Visual Basic

API afectadas

None

Los tipos del espacio de nombres Microsoft.VisualBasic.ApplicationServices no están disponibles

Los tipos del espacio de nombres Microsoft.VisualBasic.ApplicationServices no están disponibles.

Versión introducida

.NET Core 3.0

Descripción del cambio

Los tipos del espacio de nombres Microsoft.VisualBasic.ApplicationServices estaban disponibles en .NET Framework. No están disponibles en .NET Core 3.0 - 3.1.

Los tipos se han quitado para evitar dependencias de ensamblado innecesarias o cambios importantes en las versiones posteriores.

Este espacio de nombres se agregó en .NET 5, actualizando el proyecto a .NET 5 o una versión posterior.

O bien

Si su código depende del uso de los tipos Microsoft.VisualBasic.ApplicationServices y de sus miembros, es posible que pueda usar un tipo o miembro equivalente de la biblioteca de clases .NET. Por ejemplo, algunos miembros System.Environment y System.Security.Principal.WindowsIdentity proporcionan una funcionalidad equivalente a las propiedades de la clase Microsoft.VisualBasic.ApplicationServices.User.

Categoría

Visual Basic

API afectadas

Los tipos del espacio de nombres Microsoft.VisualBasic.Devices no están disponibles

Los tipos del espacio de nombres Microsoft.VisualBasic.Devices no están disponibles.

Versión introducida

.NET Core 3.0

Descripción del cambio

Los tipos del espacio de nombres Microsoft.VisualBasic.Devices estaban disponibles en .NET Framework. No están disponibles en .NET Core 3.0 - 3.1.

Los tipos se han quitado para evitar dependencias de ensamblado innecesarias o cambios importantes en las versiones posteriores.

Este espacio de nombres se agregó en .NET 5, actualizando el proyecto a .NET 5 o una versión posterior.

O bien

Si su código depende del uso de los tipos Microsoft.VisualBasic.Devices y de sus miembros, es posible que pueda usar un tipo o miembro equivalente de la biblioteca de clases .NET. Por ejemplo, los tipos System.DateTime y System.Environment proporcionan una funcionalidad equivalente a la clase Microsoft.VisualBasic.Devices.Clock, y la funcionalidad equivalente a la clase Microsoft.VisualBasic.Devices.Ports la proporcionan los tipos del espacio de nombres System.IO.Ports.

Categoría

Visual Basic

API afectadas

Los tipos del espacio de nombres Microsoft.VisualBasic.MyServices no están disponibles

Los tipos del espacio de nombres Microsoft.VisualBasic.MyServices no están disponibles.

Versión introducida

.NET Core 3.0

Descripción del cambio

Los tipos del espacio de nombres Microsoft.VisualBasic.MyServices estaban disponibles en .NET Framework. No están disponibles en .NET Core 3.0 - 3.1.

Los tipos se han quitado para evitar dependencias de ensamblado innecesarias o cambios importantes en las versiones posteriores.

Este espacio de nombres se agregó en .NET 5, actualizando el proyecto a .NET 5 o una versión posterior.

O bien

Si su código depende del uso de los tipos Microsoft.VisualBasic.MyServices de y sus miembros, hay tipos y miembros correspondientes en la biblioteca de clases .NET. A continuación, se muestra una asignación de tipos Microsoft.VisualBasic.MyServices a sus tipos equivalentes en la biblioteca de clases .NET:

Tipo Microsoft.VisualBasic.MyServices Tipo de la biblioteca de clases .NET
ClipboardProxy System.Windows.Clipboard para las aplicaciones de WPF y System.Windows.Forms.Clipboard para aplicaciones de Windows Forms
FileSystemProxy Tipos del espacio de nombres System.IO
RegistryProxy Tipos relacionados con el registro en el espacio de nombres Microsoft.Win32
SpecialDirectoriesProxy Environment.GetFolderPath

Categoría

Visual Basic

API afectadas

Vea también