Windows Forms en .NET Core: Controles inexistentes y cómo sustituirlos

Como seguramente sabrás ya, .NET Core 3.x incluye la capacidad de crear aplicaciones de escritorio para Windows basadas en la clásica y archiconocida API de Windows Forms.

Windows Forms es un conjunto de APIS de interfaz de usuario que se incluían como parte de la plataforma .NET ya desde su versión 1.0, hace un montón de años y que permiten crear interfaces de usuario de manera visual para todo tipo de aplicaciones de escritorio. Además tiene la capacidad de enlazar automáticamente los controles a datos de modo que crear ciertos tipos de interfaces de acceso a datos CRUD (para leer, escribir, actualizar y borrar) es una tarea muy sencilla. En 2018 lo hicieron Open Source y con .NET Core 3.0 en 2019 lanzaron la primera versión para esta plataforma de desarrollo (en .NET "clásico" siempre ha estado disponible) que incluye también las herramientas visuales (aunque en el momento de escribir esto están todavía en Beta).

A lo largo de los años ha habido intentos de convertir Windows Forms en una biblioteca gráfica multiplataforma, al más puro estilo Java AWT, siendo la más relevante la implementación para Mono. Pero la mayor "pega" de Windows Forms a día de hoy es que está restringida a Windows, ya que tiene una dependencia muy alta en las APIs nativas de Windows.  No obstante, sigue siendo una estupenda opción para crear aplicaciones bajo este sistema operativo, y extiende un poco más el ámbito al que llega .NET Core.

Al hacer la migración de .NET framework a .NET Core Microsoft primero intentó implementar todos los controles, incluso los más antiguos y así parecía que sería en la beta del diseñador que salió con .NET Core 3.0 en septiembre de 2019. Sin embargo, poco después, en la versión 3.1 de noviembre de 2019 decidió que ciertos controles no merecían la pena y que los iba a eliminar. Esto no supone mucho problema salvo que quieras migrar directamente una aplicación de .NET "clásico" a .NET Core (cosa que tampoco tiene mucho sentido de todos modos, dado que sólo funcionará en Windows igualmente y pocas ventajas vas a obtener), ya que todos ellos tienen un control alternativo que permite hacer lo mismo o muy parecido. Y eso es precisamente lo que vamos a ver hoy.

Si ya conoces Windows Forms "clásico" y quieres desarrollar con Windows Forms para .NET Core, debes saber qué controles han desaparecido y cuáles son las alternativas que tienes para utilizar.

Esta es la lista de controles de Windows Forms "clásico" en .NET 4.8 que no se han migrado a .NET Core:

• Menu
• Menu.MenuItemCollection
• MainMenu
• ContextMenu
• MenuItem
• ToolBar
• ToolBarAppearance
• ToolBarButton
• ToolBar.ToolBarButtonCollection
• ToolBarButtonClickEventArgs
• ToolBarButtonStyle
• ToolBarTextAlign
• DataGrid
• DataGridBoolColumn
• DataGridCell
• DataGridColumnStyle
• DataGridLineStyle
• DataGridParentRowsLabelStyle
• DataGridPreferredColumnWidthTypeConverter
• DataGridTableStyle
• DataGridTextBox
• DataGridTextBoxColumn
• GridColumnStylesCollection
• GridTablesFactory
• GridTableStylesCollection
• IDataGridEditingService
• DataGrid.HitTestType
• IMenuEditorService

Pero la buena noticia es que en su mayoría tienen un equivalente más moderno que hace lo mismo o es muy parecido en cuanto a funcionalidad, por lo que no te resultará complicado conseguir lo que necesitas.

La siguiente tabla te muestra cuáles son esas equivalencias:

Además existen algunas diferencias menores más entre la versión para .NET 4.8 y la versión para .NET Core, como por ejemplo:

• El tipo de letra tradicional es Microsoft Sans Serif a tamaño 8pt, pero en .NET Core se ha cambiado a Segoe UI a 9pt, para ofrecer un aspecto más moderno.

• Se ha cambiado el diálogo de selección de carpetas desde el tradicional en forma de árbol (horrible y tedioso de usar) por el más moderno que sale en aplicaciones recientes, y que tiene más funcionalidad. Si por alguna extraña razón quieres conservar el antiguo sólo tienes que establecer la propiedad AutoUpgradeEnabled = false para el control y te lo conservará.

• Se ha eliminado el ajuste llamado AllowUpdateChildControlIndexForTabControls introducido con .NET 4.6 y que permitía evitar que los controles dentro de una pestaña reordenasen automáticamente su orden de tabulación. Ahora siempre lo hacen y no se puede desconectar, aunque raramente se usaba para algo.
• El control RichTextBox para edición enriquecida de texto usaba diferentes versiones del editor según la versión de .NET. Ahora sólo se utiliza la última versión.
• El atributo SerializableAtribute que indicaba que un control se podía persistir en formato binario para posteriormente poder cargarlo, se ha eliminado de los controles en los que realmente no es posible hacerlo porque no tienen representación binaria. Es una mejora y no tanto una limitación.