9 reglas de extensión geniales para Visual Studio

Las extensiones geniales de Visual Studio tienen varias características clave que las distinguen del resto. Se ven y en realidad están bien pensados, son funcionales y confiables. Además, hacen lo que deberían, al nivel de excelencia y se ajustan de forma nativa a las funciones internas de Visual Studio.

Para facilitar la escritura de buenas extensiones, estamos trabajando con la comunidad para desarrollar una lista de verificación simple. Incluso hay una plantilla de problema de GitHub que puede usar. En este artículo, veremos 9 reglas de expansión interesantes. Detalles debajo del corte.



Las reglas


La siguiente lista no está en orden. Recuerde seguir todas las reglas para obtener mejores resultados.



Regla 1: adherirse a las reglas de cobertura


Agregue el paquete Microsoft.VisualStudio.SDK.Analyzers NuGet a su proyecto VSIX. Esto lo ayudará a identificar y resolver errores comunes de subprocesos.

Regla 2: Agregar icono de alta calidad


Todas las extensiones deben tener un icono asociado con ellas. Asegúrese de que el icono sea un archivo .png de alta calidad con una resolución de 128 × 128 píxeles y un DPI de 96 o más. Después de agregar el icono al proyecto VSIX, regístrelo en el archivo .vsixmanifest como un icono y una imagen de vista previa. Visual Studio Marketplace utiliza un icono más grande y el suyo cambiará dinámicamente cuando se muestre en Visual Studio.

Regla 3: Título y descripción


Los estudios muestran que los usuarios a menudo instalan extensiones con nombres descriptivos cortos e información precisa sobre ellas. Asegúrese de que el nombre capture la esencia de lo que hace la extensión. La descripción en el archivo .vsixmanifest debería crear expectativas sobre lo que hace la extensión. En total, una breve descripción de qué problemas resuelve la extensión y cuáles son sus funciones clave.

Regla 4: Escribe una buena descripción del mercado


Esta es una de las cosas más importantes que debe hacer para que su expansión sea un éxito. Una buena descripción consiste en:

  • Capturas de pantalla / GIF de lo que agregará la extensión
  • Descripción detallada de las características
  • Enlaces a detalles, si es necesario

Regla 5: indicar la licencia


La licencia se muestra en Marketplace, en el instalador de VSIX y en el cuadro de diálogo Administrador de extensiones. Siempre especifique una licencia para crear expectativas para los usuarios. Considere usar choosealicense.com para encontrar la licencia correcta. La razón de esta regla es resolver cualquier ambigüedad, lo cual es importante para muchos usuarios de Visual Studio.

Regla 6: Agregar un aviso de privacidad


Si la extensión recopila datos, como la telemetría, agregue una nota al respecto en la descripción.

Regla 7: Use los conocidos Monikers donde sea posible


Visual Studio viene con miles de iconos que están disponibles en la colección KnownMonikers . Al agregar íconos a los botones, verifique: tal vez pueda usar los íconos existentes de KnownMonikers, porque son parte del lenguaje de diseño familiar para los usuarios de Visual Studio. Aquí hay una lista completa de KnownMonikers , y también puede usar la extensión KnownMonikers Explorer para encontrar la que mejor se adapte a sus scripts.

Regla 8: Crea una sensación de extensión nativa


Siga los mismos patrones y principios de diseño que usa Visual Studio. Esto hace que la extensión sea natural para los usuarios. También reduce las distracciones causadas por una interfaz de usuario mal diseñada. Asegúrese de que todos los botones, menús, barras de herramientas y ventanas de herramientas estén visibles de forma predeterminada solo cuando el usuario se encuentre en el contexto adecuado para usarlos. Hay varias reglas:

  • Nunca agregue un nuevo menú de nivel superior (junto a Archivo, Editar, etc.)
  • Ningún botón, menú o barra de herramientas debe ser visible en contextos a los que no pertenece.
  • Si necesita carga automática (probablemente no), hágalo lo antes posible.
  • Use VisibilityConstraints para alternar la visibilidad del comando en lugar de confiar en la carga automática

Regla 9: use los rangos de versión correctos


Puede ser tentador admitir versiones de Visual Studio hasta Visual Studio 2010 para que todos puedan usar su nueva extensión. El problema es que ya no puede usar las API introducidas después de la versión anterior que admite la extensión. A menudo, estas nuevas API son importantes y ayudan a mejorar el rendimiento y la confiabilidad tanto de su extensión como de Visual Studio.

Estas son nuestras pautas para decidir qué versiones de Visual Studio admitir:

  • Solo admite versiones anteriores y actuales de Visual Studio; si es posible, no es compatible con versiones anteriores
  • No especifique el rango de versiones disponibles. Por ejemplo [16,0,). Obtenga más información sobre las versiones aquí .

Tu opinion


¿Qué opinas de esta lista de verificación? ¿Estás de acuerdo con las reglas? Comparta sus pensamientos a continuación en los comentarios o en el repositorio de GitHub . Espero que la lista de verificación te ayude a crear extensiones geniales que se volverán realmente populares.

Source: https://habr.com/ru/post/459832/


All Articles