Nuevas características para autores de extensiones en Visual Studio 2019 v.16.1

A principios de la semana pasada, lanzamos Visual Studio 2019 v.16.1 Preview 1 (vea las notas de la versión ). Esta es la primera vista previa de la primera actualización de Visual Studio 2019. Si aún no ha configurado para recibir versiones de Vista previa, hágalo ahora . La versión de vista previa se instala sin problemas junto a la versión de lanzamiento, para que no interfieran entre sí. Recomiendo encarecidamente que todos los autores de extensiones instalen la versión Vista previa.

¿Tiene instalada actualmente la vista previa 16.1? Genial Aquí hay algunas características que te pueden gustar. Detalles debajo del corte!



Apoyo a proyectos compartidos


Hay varias razones por las cuales los autores de extensiones a veces tienen que dividir una extensión en varios proyectos para admitir diferentes versiones de Visual Studio. Si está utilizando una API que no existía para una versión anterior de Visual Studio, o si hay cambios significativos entre las versiones que desea admitir. Ahora se ha vuelto mucho más fácil dividir la extensión.

En Visual Studio 2019 v.16.1 Preview 1, agregamos soporte para referencias al proyecto compartido de proyectos VSIX en la misma solución.

imagen

Puede poner código común en un proyecto compartido separado, que se compila directamente en proyectos VSIX en el momento de la compilación. El único código que existe en los proyectos VSIX es el código específico para la versión compatible de Visual Studio. El resultado son dos VSIX independientes que se dirigen a su propio rango de versiones de Visual Studio y comparten la mayor parte del código de un proyecto común. Consulte el código de la extensión de Extension Manager que hace exactamente eso.

Ya no es necesario un archivo .resx


Al agregar comandos, menús, etc. con un archivo VSCT, debe especificar el archivo .resx marcado con la propiedad MergeWithCTOMSBuild . Las plantillas en Visual Studio se encargan de agregar este archivo y también agregan el archivo .ico al que hace referencia el archivo .resx. Sin embargo, la necesidad de .resx es un detalle de implementación, y la mayoría de las extensiones no necesitan usarlo.

Para simplificar el proyecto VSIX, se ha eliminado el requisito del archivo .resx /.ico para aquellos que usan el último paquete NuGet Microsoft.VSSDK.BuildTools 16.0 o posterior.

Detrás de escena, el paquete NuGet proporciona un .resx vacío para compilar con la propiedad MergeWithCTO hasta que registre el suyo en el proyecto.

Conciencia por monitor


Se incluye soporte adicional por monitor en 16.1 con .NET Framework 4.8 instalado. La interfaz de usuario de Windows Forms ahora es mejor para escalar DPI en monitores. Sin embargo, esto puede causar problemas de IU en su extensión después de instalar .NET Framework 4.8.

Al usar Windows Forms en una extensión, puede asignar el comportamiento de escala de Visual Studio 2017 al empaquetar la creación de su formulario o control en DpiAwareness.EnterDpiScope .

using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware)) using (var form = new MyForm()) { form.ShowDialog(); } 

Todo lo que necesita hacer es agregar un enlace al paquete NuGet Microsoft.VisualStudio.DpiAwareness . Use este paquete en extensiones destinadas a versiones anteriores de Visual Studio, pero tenga en cuenta que solo funcionará cuando se use en la versión 16.1 y posteriores. Por lo tanto, se puede usar en extensiones que abarcan varias versiones de Visual Studio.

Para simplificar la simulación de varios monitores que trabajan con diferentes escalas de DPI, el ingeniero del equipo IDE de Visual Studio creó una pequeña herramienta conveniente y la puso en GitHub . El equipo utilizó esta herramienta cuando agregaron soporte para el reconocimiento por monitor, por lo que también puede encontrarlo útil.

Lea más sobre cómo trabajar con la conciencia por monitor .

Inicio síncrono deshabilitado


Hace 18 meses, enviamos un correo electrónico a los socios de extensión, anunciando la obsolescencia del inicio sincrónico de los paquetes de extensión. Hace un año, publicamos una publicación de blog con información más detallada de que el paquete de inicio automático sincrónico no será compatible con una versión futura de Visual Studio. Esta versión es la 16.1.

Hay excelentes ejemplos de cómo actualizar a AsyncPackage con la carga en segundo plano habilitada, y la mayoría de las extensiones de hoy ya han hecho la transición. Si aún no lo ha hecho, ahora es el momento de hacerlo antes de que 16.1 deje el modo de vista previa.

Nuevo SDK de metapaquete


El metapaquete Microsoft.VisualStudio.SDK es un paquete NuGet separado que hace referencia a todos los diversos paquetes de Visual Studio que componen el SDK. Lo mejor del metapaquete es que tiene acceso a todas las interfaces y servicios. Además, también evita problemas con versiones de paquetes que no coinciden.

Cuando lanzamos Visual Studio 2019 (16.0), la plantilla del proyecto VSIX hacía referencia a la versión 15.9 del metapaquete SDK. Esto se debió a que la versión 16.0 todavía estaba en desarrollo. Todos los paquetes individuales tenían que publicarse en NuGet antes de que pudiéramos obtener dependencia del metapaquete.

La buena noticia es que ahora finalmente estamos listos para la versión 16.0. Si su extensión es compatible con la versión 16.0, entonces debe usarla. También puede obtener más información sobre las versiones de extensión aquí .

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


All Articles