Septiembre de 2019
Volumen 34, número 9
[Primera palabra]
Visual Basic en .NET Core
Por Kathleen Dollard | Septiembre de 2019
Empecé a escribir código con Visual Basic hace más de dos décadas y entiendo por qué muchas personas siguen programando con Visual Basic .NET. Tiene casi todas las características de C#, además de una funcionalidad única que permite centrarse con más facilidad en lo que el software lleva a cabo. Esta funcionalidad procede tanto de las características propias como de las extensiones y la estabilidad del lenguaje. Visual Basic incluye también características de productividad únicas, como los literales XML y el enlace de eventos en contexto.
Ahora Visual Basic .NET 16.0 incorpora sus características favoritas de Visual Basic a .NET Core 3.0. Las partes esenciales del lenguaje de programación Visual Basic .NET están en .NET Core desde el principio, pero los desarrolladores pueden esperar una experiencia enriquecida cuando Microsoft distribuya Visual Studio 16.3 y .NET Core 3.0 con Visual Basic 16.0 y C# 8.0 integrados.
Cuando trabajé en la transición a .NET Core, pude profundizar en la tecnología en la que se basan las extensiones del lenguaje: las funciones especiales, los modelos de aplicación y el subsistema My. Estas características se encuentran en microsoft.visualbasic.dll, también denominado entorno en tiempo de ejecución de Visual Basic, y muchas de ellas se incluyen ahora en .NET Core 3.0, excepto las que dependen de Windows Forms (WinForms).
Windows Forms
Visual Basic .NET tiene una relación especial con WinForms, que se modeló en gran medida en las primeras versiones de Visual Basic. Entre todas las opciones que tienen los programadores de .NET para compilar aplicaciones, WinForms sigue siendo la mejor para realizar el trabajo con rapidez. Además de los roles tradicionales, WinForms ofrece una forma rápida de desarrollar servidores de front-end ligeros para servicios en el entorno local o en la nube, ya sean para producción o para prototipos funcionales.
Aunque la biblioteca de WinForms estará disponible, los diseñadores de WinForms no formarán parte de Visual Studio 16.3. Esto limita la experiencia, por lo que el equipo de Visual Basic .NET decidió centrarse en la parte que no era WinForms de las extensiones del lenguaje para Visual Basic 16.0. Esto significa que puede usar WinForms en .NET Core con Visual Basic, pero no tendrá el cuadro de diálogo de propiedades del proyecto para habilitar el modelo de aplicación de Visual Basic. Necesitará un formulario de inicio o de Sub Main, y verá que las características de My no están disponibles aún.
Algunas partes del entorno en tiempo de ejecución de Visual Basic dependen de WinForms, incluso para tipos no esperados, como My.Computer. Vamos a dividir el entorno en tiempo de ejecución en la parte que depende de WinForms y la que no. La parte que depende de WinForms se incluirá en una versión futura de Visual Basic.
Más allá de estas limitaciones, Visual Basic .NET 16.0 aporta gran parte de las funciones del entorno en tiempo de ejecución de Visual Basic a .NET Core. Esto incluye las características clave que espera, como Fix y Mid. La telemetría de la portabilidad de las API ayudó al equipo a clasificar el trabajo por orden de prioridad y algunas características que tenían poco uso no se portaron.
Apertura y estabilidad
Visual Basic .NET 16.0 incluye las funciones financieras y de archivos que portaron los amigos de la comunidad. Por supuesto, Visual Basic .NET es de código abierto desde 2015. Hay áreas importantes en las que puede contribuir y muchas de ellas no son tan intimidantes como el compilador Roslyn. También puede formar parte del restablecimiento de las comunidades de Visual Basic .NET en Facebook y Gitter. Para obtener más información sobre la comunidad y el diseño del lenguaje, visite el sitio de diseño del lenguaje Visual Basic .NET (github.com/dotnet/vblang).
Para esta última versión de Visual Basic, el entorno en tiempo de ejecución se portó directamente. No se realizaron cambios ni se “limpiaron” características. Las cosas deberían funcionar igual en .NET Core que en .NET Framework. Todo esto forma parte del compromiso profundo del equipo de Visual Basic con la estabilidad. Esta estabilidad es importante para la compatibilidad con versiones anteriores, por supuesto, pero el compromiso se extiende a garantizar que el código escrito en distintos momentos de la evolución de Visual Basic siga siendo fácil de leer. En Visual Basic .NET se incorporan características nuevas lentamente y solo se agregan las que se ven naturales en Visual Basic.
Puede desarrollar aplicaciones para .NET Core o .NET Framework (.NET 4.8 y versiones anteriores) con Visual Studio. Aunque .NET Framework seguirá siendo compatible durante mucho tiempo, el desarrollo de aplicaciones en .NET Core aporta una serie de ventajas, como la implementación en paralelo y autónoma que elimina los problemas que se producen cuando la instalación de otra aplicación realiza cambios en las máquinas de producción. En el caso de WinForms, hay nuevas características, como una mayor compatibilidad con valores altos de PPP. Y, más adelante, las nuevas características de .NET, Visual Basic .NET y C# solo estarán disponibles en .NET Core. En Visual Basic, obtendrá las ventajas de Visual Basic 16.0 solo con elegir .NET Core 3.0 (netcoreapp 2.2) como plataforma de destino.
Funcionalidad multiplataforma
Visual Basic .NET en .NET Core es multiplataforma, aunque WinForms, Windows Presentation Foundation y otras características específicas de Windows solo funcionarán en Windows. Puede ver los sistemas operativos compatibles en aka.ms/net-Core-3-0-Supported-os. Si ejecuta una aplicación de Visual Basic .NET en un sistema operativo como Linux, las características que son multiplataforma funcionarán sin problemas. Si llama a funcionalidad del entorno en tiempo de ejecución de Visual Basic que no funciona en esa plataforma, obtendrá una excepción System.PlatformNotSupportedException con un mensaje parecido a “<método> no se admite en esta plataforma”. Este es el mismo comportamiento que el del resto de .NET; por tanto, si está trabajando en modo multiplataforma, querrá probar la aplicación en los sistemas operativos en los que espera implementarla, independientemente del lenguaje que use.
Algunos tipos de proyectos no se admiten en .NET Core 3.0. Por ejemplo, WebForms no se admite en ningún lenguaje. ASP.NET Core Razor no admite Visual Basic, por lo que no podrá trasladar las aplicaciones de MVC sin más. Además, aunque Microsoft no ofrece un modelo de desarrollo web que sea Visual Basic al 100 %, puede usar Visual Basic en ASP.NET Web API con front-end de JavaScript o crear aplicaciones combinadas con vistas en proyectos de Razor en C#.
Analizador de portabilidad de API
Puede probar la compatibilidad de sus aplicaciones ejecutando el Analizador de portabilidad de API. Esta herramienta está disponible para descargarla como extensión de Visual Studio de la galería de Visual Studio o como herramienta de la línea de comandos. Encontrará más información en aka.ms/API-Portability. El Analizador de portabilidad de API genera una hoja de cálculo en la que se indica el porcentaje de la aplicación que funcionará en las plataformas que seleccione; en este caso, .NET Core 3.0. Otras pestañas profundizan en las API específicas que se usan en la aplicación, así como en las que no se admiten.
Queremos conocer su opinión.
El equipo quiere comprender los problemas a los que se enfrenan los programadores de Visual Basic .NET que migran a .NET Core y le invitamos a que colabore en la siguiente fase de ese proceso. Si ejecuta el Analizador de portabilidad y descubre que faltan elementos en el espacio de nombres VisualBasic u otros problemas específicos de Visual Basic, háganoslo saber abriendo una incidencia o comentando una que ya se haya abierto en el sitio de diseño del lenguaje Visual Basic .NET (github.com/dotnet/vblang).
El trabajo que estamos realizando con .NET Core configura Visual Basic para el futuro. Combinado con el compromiso a largo plazo de Microsoft con .NET Framework 4.8, Visual Basic, uno de los lenguajes de programación más productivos que se han creado jamás, ofrece flexibilidad para aplicaciones nuevas y heredadas.
Cambios en los instaladores de Visual Studio y .NET Core
Si ejecuta “dotnet --info” en un símbolo del sistema, verá una lista de los SDK y los entornos en tiempo de ejecución de .NET Core instalados. Puede haber mucho más de lo que esperaba.
Los instaladores anteriores de Visual Studio y .NET Core no quitaban los SDK ni los entornos en tiempo de ejecución antiguos cuando se actualizaban o desinstalaban. Aunque es posible que los necesite para anclar SDK mediante global.json o para elegir como destino entornos en tiempo de ejecución más antiguos, es posible que se encuentren sin usar en la máquina.
Ahora, a partir de Visual Studio 2019 16.3, Visual Studio administrará las versiones de los SDK y los entornos en tiempo de ejecución de .NET Core que instale. Solo mantendrá una copia del SDK de .NET Core en cada máquina por canal (versión preliminar o de lanzamiento) e instalará el último entorno en tiempo de ejecución. Puede elegir como destino entornos en tiempo de ejecución anteriores, junto con sus plantillas y paquetes de destino, en la pestaña Componentes individuales del Instalador de Visual Studio.
Ahora, al descargar e instalar el SDK de .NET Core 3.0 desde dotnet.Microsoft.com/download, se quitarán las revisiones anteriores del mismo grupo de características. Por ejemplo, al instalar la versión 3.0.102 se desinstalará la versión 3.0.100. También se quitarán las versiones preliminares de ese grupo.
Cada versión del SDK puede tener como destino todas las versiones anteriores del entorno en tiempo de ejecución, por lo que, normalmente, solo necesitará una. Si necesita otros SDK o entornos en tiempo de ejecución, puede descargarlos de dotnet.Microsoft.com/download.
Puede quitar manualmente los SDK y los entornos en tiempo de ejecución de .NET Core, o bien puede limpiarlos con la herramienta de desinstalación de .NET Core publicada recientemente en Windows y MacOS (aka.ms/Remove-SDK-Runtime). Tenga cuidado, porque Visual Studio no realiza un seguimiento de los SDK y, si quita los que no son, puede haber problemas. Si elimina algo que Visual Studio necesita, ejecute “Reparar” en el Instalador de Visual Studio.
Kathleen Dollardes administradora de programas principal en el equipo de .NET Core en Microsoft. Es la administradora de programas para Visual Basic, colabora con el equipo de lenguajes administrados y trabaja en la CLI y el SDK de .NET Core.