Setembro de 2019

Volume 34 – Número 9

[Primeira Palavra]

Visual Basic no .NET Core

Por Kathleen Dollard | Setembro de 2019

Comecei a escrever código de Visual Basic há mais de duas décadas e entendo por que tantas pessoas ainda programam em Visual Basic .NET. Ele tem quase todos os recursos do C#, além de uma funcionalidade exclusiva que torna mais fácil se concentrar no que seu software realiza. Isso é proveniente dos recursos, extensões e estabilidade da própria linguagem. O Visual Basic também inclui recursos exclusivos de produtividade, como literais do XML e conexão de eventos in-loco.

Agora, o Visual Basic .NET 16.0 está trazendo seus recursos do Visual Basic favoritos para o .NET Core 3.0. As partes essenciais da linguagem de programação Visual Basic .NET estão presentes no .NET Core desde seu desenvolvimento inicial, mas os desenvolvedores poderão esperar uma experiência aprimorada quando a Microsoft fornecer o Visual Studio 16.3 e o .NET Core 3.0 incluindo o Visual Basic 16.0 e o C# 8.0.

Em minha função trabalhando na transição para o .NET Core, pude me aprofundar na tecnologia por trás das extensões de linguagem: as funções especiais, os modelos de aplicativo e o meu subsistema. Esses recursos estão contidos em microsoft.visualbasic.dll, também chamado de Runtime do Visual Basic. Muitos deles agora estão incluídos no .NET Core 3.0, exceto aqueles dependentes do WinForms (Windows Forms).

Windows Forms

O Visual Basic .NET tem uma relação especial com o WinForms, que foi modelado principalmente nas versões mais antigas do Visual Basic. Entre todas as opções que os programadores do .NET têm para criar aplicativos, o WinForms continua sendo a melhor para realizar o trabalho rapidamente. Além das funções tradicionais, o WinForms oferece uma maneira rápida de desenvolver front-ends finos para serviços locais ou na nuvem, seja para produção ou para protótipos funcionais.

Enquanto a biblioteca WinForms estiver disponível, os designers do WinForms não serão parte do Visual Studio 16.3. Isso limita a experiência, então a equipe do Visual Basic .NET decidiu se concentrar na parte não WinForms das extensões de linguagem para o Visual Basic 16.0. Isso significa que você poderá usar o WinForms no .NET Core com o Visual Basic, mas não terá a caixa de diálogo de propriedade do projeto para habilitar o modelo de aplicativo do Visual Basic. Você precisará de um formulário de inicialização ou subprincipal e verá que os Meus recursos ainda não estão disponíveis.

Partes do Runtime do Visual Basic dependem do WinForms, mesmo para tipos inesperados como My.Computer. Estamos dividindo o runtime em partes que são dependentes do WinForms e aquelas que não são, com a parte dependente do WinForms prevista para aparecer em uma versão futura do Visual Basic.

Além dessas limitações, o Visual Basic .NET 16.0 traz grande parte das funções do runtime do Visual Basic para o .NET Core. Isso inclui os principais recursos que você espera, como Fix e Mid. A telemetria da porta da API ajudou a equipe a priorizar o trabalho aqui e alguns recursos com uso muito baixo não eram portados.

Abertura e estabilidade

O Visual Basic .NET 16.0 inclui as funções financeiras e de arquivo que foram modeladas por pessoas na comunidade. É claro que Visual Basic .NET tem sido um software livre desde 2015. Há áreas significativas nas quais você pode contribuir e muitas delas não são tão intimidadoras quanto o compilador Roslyn! Você também pode fazer parte da revitalização das comunidades do Visual Basic .NET no Facebook e no Gitter. Saiba mais sobre o design de comunidade e de linguagem no site de design de linguagem do Visual Basic .NET (github.com/dotnet/vblang).

Para esta versão mais recente do Visual Basic, o runtime foi portado diretamente. Não houve nenhuma alteração e nenhum esforço para os recursos de "limpeza". As coisas devem funcionar no .NET Core da mesma forma que funcionavam no .NET Framework. Tudo isso faz parte do compromisso profundo com a estabilidade na equipe do Visual Basic. É claro que essa estabilidade é importante para compatibilidade com versões anteriores, mas o compromisso se estende para garantir que o código escrito em diferentes pontos na evolução do Visual Basic continue sendo fácil de ler. Novos recursos são incorporados lentamente no Visual Basic .NET e somente aqueles que proporcionam uma sensação natural ao serem usados no Visual Basic são adicionados.

Você pode desenvolver aplicativos destinados ao .NET Core ou ao .NET Framework (.NET 4.8 e inferior) com o Visual Studio. Embora o .NET Framework permanecerá compatível por um longo tempo, desenvolver aplicativos no .NET Core traz uma série de vantagens, incluindo implantação lado a lado e independente que elimina problemas que ocorrem quando a instalação de outro aplicativo faz alterações em computadores de produção. Para o WinForms, há novos recursos, como melhor suporte a DPI alto. E, no futuro, novas funcionalidades no .NET, no Visual Basic .NET e no C# só estarão disponíveis no .NET Core. No Visual Basic, você obterá as vantagens do Visual Basic 16.0 apenas ao usar o .NET Core 3.0 (netcoreapp2.2) como estrutura de destino.

Suporte multiplataforma

O Visual Basic .NET no .NET Core é multiplataforma, embora o WinForms, o Windows Presentation Foundation e outros recursos específicos do Windows só funcionem no Windows. Você pode encontrar os sistemas operacionais compatíveis em aka.ms/net-core-3-0-supported-os. Se executar um aplicativo Visual Basic .NET em um sistema operacional como o Linux, os recursos que funcionam num esquema multiplataforma funcionarão. Se chamar uma funcionalidade do Runtime do Visual Basic que não funcione nessa plataforma, obterá uma System.PlatformNotSupportedException com uma mensagem semelhante a "<método> não compatível com esta plataforma". Esse é o mesmo comportamento do restante do .NET, portanto, se você estiver trabalhando num esquema multiplataforma, será conveniente testar o aplicativo nos sistemas operacionais em que você pretende implantá-lo, independentemente da linguagem usada.

Alguns tipos de projeto não são compatíveis com o .NET Core 3.0. Por exemplo, o WebForms não será compatível, independentemente da linguagem. O Visual Basic não é compatível com o Razor do ASP.NET Core, portanto, não é possível simplesmente portar aplicativos MVC. E, embora a Microsoft não ofereça um modelo de desenvolvimento para a Web que seja totalmente no Visual Basic, você pode usar o Visual Basic na API Web do ASP.NET com front-ends do JavaScript ou criar aplicativos combinados com exibições em projetos Razor em C#.

Analisador de Portabilidade de API

Você pode testar a compatibilidade dos aplicativos executando o Analisador de Portabilidade de API. A ferramenta está disponível para download como uma extensão do Visual Studio na galeria do Visual Studio ou como uma ferramenta de linha de comando. Saiba mais em aka.ms/api-portability. O Analisador de Portabilidade de API gera uma planilha que lista o percentual do aplicativo que funcionará apenas nas plataformas que você selecionar, neste caso, o .NET Core 3.0. Outras guias analisam as APIs específicas usadas no aplicativo, bem como aquelas que não são compatíveis.

Nós queremos ouvir você!

A equipe deseja entender os problemas que os programadores do Visual Basic .NET enfrentam ao migrar para o .NET Core. Sua ajuda será bem-vinda na próxima fase desse percurso. Se você executar o Analisador de Portabilidade e achar que precisa de coisas que estão ausentes no namespace do Visual Basic ou tiver outros problemas específicos do Visual Basic, informe-nos abrindo um registro de problema ou comentando em um existente no site de design de linguagem do Visual Basic .NET (github.com/dotnet/vblang).

O trabalho que estamos fazendo com o .NET Core prepara o Visual Basic para o futuro. Combinado com o compromisso de longo prazo da Microsoft com o .NET Framework 4.8, você tem flexibilidade para aplicativos novos e herdados no Visual Basic, uma das linguagens de programação mais produtivas já criadas.

Alterações nos instaladores do Visual Studio e do .NET Core

Se você executar 'dotnet --info' em um prompt de comando, verá uma lista de SDKs e runtimes do .NET Core instalados. Podem existir muito mais do que você esperava!

Os instaladores anteriores do Visual Studio e do .NET Core não estavam removendo SDKs e runtimes mais antigos ao atualizar ou desinstalar. Embora você possa precisar deles para dar suporte à fixação do SDK por meio de global.json ou direcionar os runtimes mais antigos, eles podem estar apenas permanecendo sem uso em seu computador.

Agora, começando com o Visual Studio 2019 16.3, o Visual Studio gerenciará as versões de SDKs do .NET Core e os runtimes que ele instala. Ele manterá apenas uma cópia do SDK do .NET Core em cada computador por canal (versão prévia ou versão) e instalará o runtime mais recente. Você pode direcionar os runtimes anteriores selecionando-os – juntamente com os respectivos modelos e pacotes de direcionamento – na guia Componentes Individuais do Instalador do Visual Studio.

Quando você baixa e instala o SDK do .NET Core 3.0 de dotnet.microsoft.com/download, patches anteriores na mesma faixa de recurso são removidos. Por exemplo, a versão 3.0.100 será desinstalada quando você instalar a 3.0.102. As versões prévias nessa faixa também serão removidas.

Cada versão do SDK pode ter como destino todas as versões anteriores do runtime, de modo que você geralmente precisa apenas de uma. Se precisar de SDKs ou runtimes adicionais, você poderá baixá-los em dotnet.microsoft.com/download.

Você pode remover manualmente SDKs e runtimes do .NET Core ou pode limpá-los usando a Ferramenta de Desinstalação do .NET Core lançada recentemente no Windows e no macOS (aka.ms/remove-sdk-runtime). Mas tenha cuidado, pois os SDKs não são rastreados pelo Visual Studio e, portanto, remover os incorretos pode causar problemas. Se você excluir algo de que o Visual Studio precisa, execute "Reparar" no Instalador do Visual Studio.


Kathleen Dollardé uma gerente de programa principal na equipe do .NET Core na Microsoft. Ela é gerente de programa do Visual Basic, contribui para as linguagens gerenciadas e trabalha na CLI do .NET Core e no SDK.


Discuta esse artigo no fórum do MSDN Magazine