As grandes extensões do Visual Studio compartilham alguns recursos importantes que os diferenciam dos demais. Eles parecem e se sentem bem criados, têm desempenho e confiabilidade, fazem o que anunciam com perfeição e se misturam naturalmente aos recursos do Visual Studio.
Para facilitar a criação de grandes extensões, trabalhamos com a comunidade de extensibilidade para criar uma lista de verificação simples a seguir. Existe até um
modelo de problema do GitHub que você pode usar para se lembrar de consultar a lista de verificação.

Regras
A lista a seguir não está em ordem específica. Lembre-se de concluir todos os itens para obter melhores resultados.

Regra 1: siga as regras de segmentação
Adicione o pacote
Microsoft.VisualStudio.SDK.Analyzers NuGet ao seu projeto VSIX. Isso ajudará você a descobrir e corrigir violações comuns das práticas recomendadas relacionadas a encadeamento.
Regra 2: adicionar ícone de alta qualidade
Todas as extensões devem ter um ícone associado a ela. Verifique se o ícone é um arquivo .png de alta qualidade com o tamanho de 128 × 128 pixels em 96 DPI ou mais. Depois de adicionar o ícone ao seu projeto VSIX, registre-o no arquivo .vsixmanifest como a imagem Icon e Preview. O Visual Studio Marketplace usa o ícone maior e será redimensionado dinamicamente quando mostrado no Visual Studio.
Regra 3: Nome e descrição
Estudos mostram que os usuários têm maior probabilidade de instalar extensões com nomes curtos e descritivos e descrições precisas. Verifique se o nome reflete a essência do que a extensão faz. A descrição no arquivo .vsixmanifest deve definir as expectativas quanto ao que a extensão faz. Portanto, uma breve menção de quais problemas ele resolve e quais os principais recursos que possui são fundamentais.
Regra 4: escreva uma boa descrição do mercado
Essa é uma das coisas mais importantes que você deve fazer para tornar sua extensão bem-sucedida. Uma boa descrição consiste em:
- Capturas de tela / GIFs animados da interface do usuário adicionados pela extensão
- Descrição detalhada dos recursos individuais
- Links para mais detalhes, se aplicável
Regra 5: Adicionar licença
A licença é visível no Marketplace, no instalador do VSIX e na caixa de diálogo Gerenciador de Extensões. Sempre especifique uma licença para definir as expectativas para os usuários. Considere usar o
choosealicense.com para ajudar a encontrar a licença certa para você. O motivo dessa regra é remover qualquer ambiguidade, o que é importante para muitos usuários do Visual Studio.
Regra 6: adicionar aviso de privacidade
Se a extensão coletar dados como telemetria ou se comunicar de outra forma com um terminal remoto, adicione uma observação sobre ele na descrição.
Regra 7: Use KnownMonikers quando possível
O Visual Studio é enviado com milhares de ícones disponíveis na coleção
KnownMonikers . Ao adicionar ícones aos botões de comando, verifique se você pode usar os ícones KnownMonikers existentes, pois eles fazem parte de uma linguagem de design familiar aos usuários do Visual Studio. Aqui está uma
lista completa
dos KnownMonikers e pegue a extensão
KnownMonikers Explorer para encontrar o
caminho certo para os seus cenários.
Regra 8: faça parecer nativo ao VS
Siga os mesmos padrões e princípios de design que o próprio Visual Studio usa. Isso faz com que a extensão pareça natural para os usuários. Também reduz as distrações causadas pela interface do usuário mal projetada. Certifique-se de que todos os botões, menus, barras de ferramentas e janelas de ferramentas sejam visíveis apenas por padrão quando o usuário estiver no contexto certo para usá-los. Existem algumas regras práticas a seguir:
- Nunca adicione um novo menu de nível superior (ao lado de Arquivo, Editar etc.)
- Nenhum botão, menu e barra de ferramentas deve estar visível em contextos aos quais não se aplicam
- Se o carregamento automático for necessário (provavelmente não é), faça-o o mais tarde possível.
- Use VisibilityConstraints para alternar a visibilidade dos comandos em vez de confiar no carregamento automático
Regra 9: use intervalos de versão adequados
Pode ser tentador oferecer suporte a versões do Visual Studio desde o Visual Studio 2010, para garantir que todos possam usar sua nova extensão. O problema é que, ao fazer isso, não é mais possível usar APIs introduzidas posteriormente à versão mínima suportada pela extensão. Freqüentemente, essas novas APIs são importantes e ajudam a melhorar o desempenho e a confiabilidade de sua extensão e do próprio Visual Studio.
Aqui estão nossas recomendações para decidir quais versões do Visual Studio dar suporte:
- Oferece suporte apenas à versão anterior e atual do Visual Studio.
- Não especifique um intervalo de versão em aberto. Por exemplo, [16.0,). Saiba mais sobre os intervalos de versões .
Seus pensamentos
O que você acha desta lista de verificação? Você concorda com as regras? Por favor, deixe-nos saber sua opinião nos comentários abaixo ou no
repositório do
GitHub da lista de verificação . Espero que isso torne um pouco mais fácil dar às suas extensões esse pequeno item extra que a diferencia das demais.