No início desta semana, lançamos o Visual Studio 2019 versão 16.1 Visualização 1 (consulte as notas de versão ). É a primeira visualização da primeira atualização do Visual Studio 2019. Se você ainda não está configurado para obter versões de pré-visualização, faça isso agora . O canal de visualização é instalado lado a lado com o canal de liberação e eles não interferem um no outro. Eu recomendo que todos os autores de extensões instalem a visualização.
A pré-visualização 16.1 está instalada agora? Isso é ótimo. Aqui estão alguns recursos que você pode achar interessantes.
Este artigo no blogSuporte de projeto compartilhado
Há vários motivos pelos quais os autores de extensões às vezes precisam dividir uma extensão em vários projetos para dar suporte às várias versões do Visual Studio. Se você estiver usando uma API que não existia para uma versão anterior do Visual Studio ou se houver alterações significativas entre as versões que você deseja oferecer suporte, agora é mais fácil dividir sua extensão.
Com o Visual Studio 2019 versão 16.1 Visualização 1, adicionamos suporte para fazer referência a Projetos compartilhados de projetos VSIX na mesma solução.
Você pode colocar código comum em um projeto compartilhado separado que seja compilado diretamente nos projetos VSIX no momento da construção. O único código que existe nos próprios projetos VSIX é o código específico da versão do Visual Studio que ele suporta. O resultado são dois VSIXs separados que têm como alvo seu próprio intervalo de versão do Visual Studio e compartilham a maior parte do código do Projeto Compartilhado. Faça o check-out do código da extensão do Extension Manager que faz exatamente isso.
Não há mais necessidade de arquivo .resx
Ao adicionar comandos, menus etc. usando um arquivo VSCT, você deve especificar um arquivo .resx marcado com a propriedade MergeWithCTO MSBuild. Os modelos no Visual Studio cuidam da adição desse arquivo e também adicionam um arquivo .ico referenciado pelo arquivo .resx. No entanto, a necessidade de um .resx é um detalhe de implementação e a maioria das extensões não precisa usá-lo.
Em um esforço para simplificar o projeto VSIX, os requisitos para os arquivos .resx / .ico foram removidos ao usar o pacote Microsoft.VSSDK.BuildTools NuGet mais recente, versão 16.0 ou mais recente.
Nos bastidores, o pacote NuGet fornece um .resx vazio para compilar com a propriedade MergeWithCTO , a menos que você tenha registrado o seu próprio no projeto.
Reconhecimento por monitor
Suporte adicional de reconhecimento por monitor está sendo ativado no 16.1 com o .NET Framework 4.8 instalado. A interface do usuário do Windows Forms agora lida melhor com o dimensionamento de DPI entre monitores. No entanto, isso pode causar problemas de interface do usuário em sua extensão após a instalação do .NET Framework 4.8.
Ao usar o Windows Forms em uma extensão, você pode corresponder aos comportamentos de dimensionamento do Visual Studio 2017 agrupando seu formulário ou controlando a criação em uma chamada DpiAwareness.EnterDpiScope .
using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware)) using (var form = new MyForm()) { form.ShowDialog(); }
Tudo o que você precisa é adicionar uma referência ao pacote Microsoft.VisualStudio.DpiAwareness NuGet. Use este pacote também em extensões direcionadas para versões anteriores do Visual Studio, mas lembre-se de que ele só entrará em vigor quando executado na 16.1 ou mais recente. Portanto, é seguro usar em extensões que abrangem várias versões do Visual Studio.
Para facilitar a simulação de vários monitores em execução com diferentes escalas de DPI, um engenheiro da equipe do Visual Studio IDE criou uma pequena ferramenta útil e a colocou no GitHub . A equipe usou essa ferramenta enquanto adicionava suporte à conscientização por monitor; portanto, você também pode achar útil.
Leia mais sobre como lidar com o reconhecimento por monitor para extensores .
Carregamento automático síncrono desativado
Há 18 meses, enviamos um email aos parceiros de extensão anunciando a descontinuação do carregamento automático síncrono de pacotes de extensão. Há um ano, acompanhamos uma postagem no blog com mais detalhes que descreviam que o pacote carregado automaticamente de forma síncrona não seria suportado em uma versão futura do Visual Studio. Essa versão é 16.1.
Existem ótimos exemplos de como migrar para o AsyncPackage com o carregamento em segundo plano ativado e a maioria das extensões hoje já fez a transição. Se você ainda não o fez, agora é uma boa hora para fazer isso antes que 16.1 saia da pré-visualização.
Novo meta pacote SDK
O meta pacote Microsoft.VisualStudio.SDK é um único pacote NuGet que faz referência a todos os vários pacotes do Visual Studio que compõem o SDK. O interessante do meta pacote é que você tem acesso a todas as interfaces e serviços. Além disso, você também evita problemas com versões de pacotes incompatíveis.
Quando lançamos o Visual Studio 2019 (16.0), o modelo do Projeto VSIX referenciava a versão 15.9 do meta pacote SDK. Isso ocorreu porque a versão 16.0 ainda estava em desenvolvimento. Todos os pacotes individuais tiveram que ser publicados no NuGet antes que pudéssemos depender deles do meta pacote.
A boa notícia é que agora finalmente temos a versão 16.0 pronta. Você deve usá-lo se a versão mais baixa do Visual Studio se sua extensão suportar 16.0. e você pode ler mais sobre versionamento de extensões aqui .
Gerente de programa sênior, Extensibilidade do Visual Studio