O suporte oficial a projetos VSIX em SDK-style simplifica a configuração de extensões baseadas em VSSDK. A migração, porém, precisa preservar o pacote produzido e o fluxo de depuração; um arquivo de projeto menor não comprova equivalência.
Escopo do suporte
O anúncio de 29 de abril de 2026 situa o suporte no Visual Studio 18.5, com o workload de desenvolvimento de extensões. Ele se refere a extensões VSSDK: o framework VisualStudio.Extensibility já usava SDK-style. Projetos legados não precisam ser convertidos obrigatoriamente.
A redução de até 75% no tempo de build é um resultado de adoção interna relatado pela Microsoft para soluções grandes, com mudanças pequenas ou restritas a um subprojeto. Não é uma promessa para qualquer extensão nem uma medição realizada neste site. O exemplo compacto de projeto no post também não define quantas linhas um projeto real deverá ter.
O que conferir ao converter
Entre os pontos de migração, o post orienta habilitar WPF quando houver XAML e marcar a extensão como implantável na solução SLN ou SLNX para o fluxo F5. Também explica as propriedades VSSDKBuildToolsAutoSetup e VsixDeployOnDebug. Confira o exemplo oficial para o tipo de extensão e a configuração de solução usados.
Como critério de aceite proposto, mantenha o projeto anterior em uma branch de comparação e registre o que deve permanecer no VSIX: manifesto, assemblies, recursos, dependências e pontos de entrada da extensão. Após a conversão, compare esse inventário com o pacote novo e investigue ausências ou inclusões inesperadas.
Faça a primeira validação em uma instância de desenvolvimento apropriada, sem substituir a instalação de trabalho da equipe. Abra a funcionalidade que a extensão acrescenta, confirme carregamento e fechamento e repita o fluxo de depuração. Compilar sem erro e iniciar o IDE são verificações diferentes.
Como medir sem confundir os cenários
Uma avaliação de desempenho deve separar build limpo, build sem mudanças e build após a mesma pequena alteração de código. Registre SDK, Visual Studio, configuração, hardware e estado de caches. Use o mesmo cenário antes e depois da migração e mantenha os tempos individuais, em vez de divulgar apenas a melhor execução.
Se o build ficou mais rápido, confira se os dois projetos produziram os artefatos esperados. Um arquivo que deixou de ser empacotado pode reduzir o trabalho realizado e, ao mesmo tempo, tornar a extensão incorreta. Esse controle ajuda a distinguir otimização de perda de funcionalidade.
Não foi compilada nem medida uma extensão VSIX para este artigo. Os passos acima são uma proposta de validação. Use o ganho relatado no anúncio como motivo para investigar seu caso, não como resultado já obtido pela sua equipe.