Les extensions Cool Visual Studio ont plusieurs fonctionnalités clés qui les distinguent des autres. Ils ont l'air bien pensés, fonctionnels et fiables. De plus, ils font ce qu'ils doivent, au niveau d'excellence et s'intègrent nativement dans les fonctions internes de Visual Studio.
Pour faciliter l'écriture de bonnes extensions, nous travaillons avec la communauté pour développer une liste de contrôle simple. Il existe même un
modèle de problème GitHub que vous pouvez utiliser. Dans cet article, nous allons examiner 9 règles d'expansion intéressantes. Détails sous la coupe.
Les règles
La liste suivante n'est pas en règle. N'oubliez pas de suivre toutes les règles pour de meilleurs résultats.
Règle 1: respectez les règles de couverture
Ajoutez le package NuGet
Microsoft.VisualStudio.SDK.Analyzers à votre projet VSIX. Cela vous aidera à identifier et à résoudre les erreurs de filetage courantes.
Règle 2: Ajouter une icône de haute qualité
Toutes les extensions doivent être associées à une icône. Assurez-vous que l'icône est un fichier .png de haute qualité avec une résolution de 128 × 128 pixels et un DPI de 96 ou plus. Après avoir ajouté l'icône au projet VSIX, enregistrez-la dans le fichier .vsixmanifest en tant qu'icône et image d'aperçu. Visual Studio Marketplace utilise une icône plus grande et la vôtre changera dynamiquement lorsqu'elle sera affichée dans Visual Studio.
Règle 3: titre et description
Des études montrent que les utilisateurs installent plus souvent des extensions avec des noms descriptifs courts et des informations précises à leur sujet. Assurez-vous que le nom capture l'essence de ce que fait l'extension. La description dans le fichier .vsixmanifest doit créer des attentes sur ce que fait l'extension. Au total, une brève description des problèmes que l'extension résout et quelles sont ses fonctions clés.
Règle 4: Rédiger une bonne description du marché
C'est l'une des choses les plus importantes que vous devez faire pour réussir votre expansion. Une bonne description consiste en:
- Captures d'écran / GIF de ce qui sera ajouté par l'extension
- Description détaillée des fonctionnalités
- Liens vers les détails, si nécessaire
Règle 5: Indiquez la licence
La licence s'affiche dans Marketplace, dans le programme d'installation de VSIX et dans la boîte de dialogue Gestionnaire d'extensions. Spécifiez toujours une licence pour créer des attentes pour les utilisateurs. Pensez à utiliser
choosealicense.com pour trouver la bonne licence. La raison de cette règle est de résoudre toute ambiguïté, ce qui est important pour de nombreux utilisateurs de Visual Studio.
Règle 6: ajouter un avis de confidentialité
Si l'extension collecte des données, telles que la télémétrie, ajoutez une note à ce sujet dans la description.
Règle 7: Utilisez des KnownMonikers dans la mesure du possible
Visual Studio est livré avec des milliers d'icônes disponibles dans la collection
KnownMonikers . Lors de l'ajout d'icônes aux boutons, vérifiez: vous pouvez peut-être utiliser les icônes KnownMonikers existantes, car elles font partie du langage de conception familier aux utilisateurs de Visual Studio. Voici une
liste complète
des KnownMonikers , et vous pouvez également utiliser l'extension
KnownMonikers Explorer pour trouver celle qui convient à vos scripts.
Règle 8: créer un sentiment d'extension native
Suivez les mêmes modèles et principes de conception que Visual Studio lui-même utilise. Cela rend l'extension naturelle pour les utilisateurs. Il réduit également les distractions causées par une interface utilisateur mal conçue. Assurez-vous que tous les boutons, menus, barres d'outils et fenêtres d'outils ne sont visibles par défaut que lorsque l'utilisateur est dans le bon contexte pour les utiliser. Il existe plusieurs règles:
- N'ajoutez jamais un nouveau menu de niveau supérieur (à côté de Fichier, Modifier, etc.)
- Aucun bouton, menu ou barre d'outils ne doit être visible dans les contextes auxquels ils n'appartiennent pas.
- Si vous avez besoin du chargement automatique (probablement pas), faites-le dès que possible.
- Utilisez VisibilityConstraints pour basculer la visibilité des commandes au lieu de compter sur le chargement automatique
Règle 9: utilisez les plages de versions correctes
Il peut être tentant de prendre en charge des versions de Visual Studio jusqu'à Visual Studio 2010 afin que tout le monde puisse utiliser votre nouvelle extension. Le problème est que vous ne pouvez plus utiliser les API introduites plus tard que l'ancienne version prise en charge par l'extension. Ces nouvelles API sont souvent importantes et contribuent à améliorer les performances et la fiabilité de votre extension et de Visual Studio lui-même.
Voici nos instructions pour décider des versions de Visual Studio à prendre en charge:
- Prise en charge uniquement des versions précédentes et actuelles de Visual Studio - si possible, ne prend pas en charge les versions antérieures
- Ne spécifiez pas la gamme des versions disponibles. Par exemple. [16.0,). En savoir plus sur les versions ici .
Votre opinion
Que pensez-vous de cette liste de contrôle? Êtes-vous d'accord avec les règles? Veuillez partager vos réflexions ci-dessous dans les commentaires ou dans
le référentiel GitHub . J'espère que la liste de contrôle vous aidera à créer des extensions intéressantes qui deviendront très populaires.