Repase las espinas para bicicletas, primera parte: aprenda los conceptos básicos de la personalización del depurador de Visual Studio usando complementos

Una de las innovaciones de Visual Studio 2012 fue acompañada por la aparición de un nuevo depurador personalizado llamado Concord. Su sistema de componentes permite que los complementos VSIX personalicen el comportamiento del depurador y escriban nuevas herramientas sensibles al contexto que pueden usar el depurador para sus necesidades. Su API proporciona muchas características de QOL, como la coordinación entre el código administrado / no administrado, la integración perfecta con un proceso remoto / depurado localmente, y más. De hecho, ¡casi todo lo que se puede hacer en el IDE se puede hacer mediante programación utilizando la API de Concord! Cambie los valores de variables específicas sobre la marcha, llame a funciones a pedido (¡o haga que el programa salte llamadas a ellas!), ¡Los complementos pueden buscar por PDB (!), Paso a paso e incluso modificación de código! Abra el gato y aprenderá sobre estas innovaciones poco conocidas en el campo de la construcción de bicicletas.

Probablemente deberías comenzar desde el principio. El depurador detecta los componentes leyendo información del archivo vsdconfig al que hace referencia el manifiesto del complemento VSIX. A su vez, vsdconfig indica qué interfaces están implementadas por los componentes del complemento y cómo encontrar estos componentes (enlace a un archivo .dll, indicando la clase o, en el caso de la implementación nativa, indicando CLSID. Daré ejemplos en C #). Además, se indica un identificador único (GUID) para cada componente, así como su "nivel". Un nivel es lo que determina en qué orden se procesarán los complementos, así como en el contexto de qué proceso se cargará esta implementación, en el proceso IDE o en el proceso de la aplicación depurada. Esto se debe al hecho de que algunas funcionalidades solo pueden funcionar en el contexto de un IDE, y viceversa, solo en el contexto de un proceso depurado. Algunas funciones API funcionan de la misma manera allí y allá. Por lo tanto, varios componentes tienen sus propias reglas de diseño, ya que pueden depender de los elementos existentes del depurador, ubicados en sus niveles fijos. Para evitar incidentes, recomiendo RTFM (https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.debugger.componentinterfaces?view=visualstudiosdk-2017) y experimentos independientes en una caja de arena separada, lo que no será una pena elimine si sucede algo (esto está conectado, de nuevo, con un matiz así; en algunos casos, ni siquiera está claro por qué el ensamblaje o tipo no se está cargando, porque todavía no pude encontrar dónde aparecerían los registros que señalarían el problema de forma estable. Error, por ejemplo, con referencia a una dependencia que no se puede cargar en el proceso de destino, puede aparecer en la salida st di-, o no. Sé akuratno, tomar compromete frecuentes, y no sentarse detrás de la rueda de borracho).

La lista de niveles es la siguiente (daré el texto en inglés para que el lector no tenga incidentes al cometer actos RFTM):

Niveles de componentes IDE (valores> 100,000):

Niveles de componentes del proceso de destino (valores <99.999):

A continuación, en orden, el proceso de creación de un proyecto. Si no hubiera matices importantes, podría describir este proceso mínimamente o omitirlo, pero las realidades son completamente diferentes: necesitamos una serie de dependencias de la biblioteca, así como una herramienta para crear archivos de configuración, que por alguna razón no se distribuye con VisualStudio, pero está disponible solo con nuget. De hecho, ahora necesitamos pasar a la esencia. El proceso de creación y configuración de un proyecto se estructura de la siguiente manera:

1. Abra Visual Studio. En mi caso, 2017 Community Edition
2. Proyecto VSIX ( Visual C # -> pestaña Extensibilidad , o mediante búsqueda). Llamémoslo "HelloVSIX"
3. Agregue un nuevo proyecto de biblioteca de clases en solución y llámelo "DebuggeePlugin"
4. Ponemos la referencia en el proyecto "DebuggeePlugin" en el proyecto "HelloVSIX"
5. Ponemos la referencia al ensamblado "Microsoft.VisualStudio.Debugger.Engine" en el proyecto DebuggeePlugin
6. Agregue la referencia para el paquete nuget Microsoft.VSSDK.Debugger.VSDConfigTool al proyecto "DebuggeePlugin". Esta es nuestra herramienta para generar configuraciones VSD.

Ahora, estamos listos para hacer que nuestro complemento haga algo útil. Hagamos lo más simple que se puede hacer: dejar que muestre un cuadro de mensaje que dice "Hola VSIX" cuando el proceso de destino se encuentra con un punto de entrada. Para hacer esto, necesitamos crear una clase que implemente la interfaz IDkmEntryPointNotification , así como completar varios archivos de configuración. Agregue una nueva clase pública llamada DkmEntryPointNotificationService, y herede la interfaz IDkmEntryPointNotification , y deje la implementación predeterminada por ahora:

using Microsoft.VisualStudio.Debugger; using Microsoft.VisualStudio.Debugger.ComponentInterfaces; using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DebuggeePlugin { class DkmEntryPointNotificationService : IDkmEntryPointNotification { public void OnEntryPoint(DkmProcess process, DkmThread thread, DkmEventDescriptor eventDescriptor) { throw new NotImplementedException(); } } } 

Agregue el archivo "DkmEntryPointNotificationService.vsdconfigxml" al proyecto "DebuggeePlugin". Para cada clase declarada que debería recibir notificaciones a través de implementaciones de las interfaces de espacio de nombres Microsoft.VisualStudio.Debugger.ComponentInterfaces, debe tener dicho archivo. Por cierto, es posible implementar varias interfaces de este tipo a la vez en una clase. Ahora necesitamos cambiar la acción de compilación de nuestro archivo ".vsdconfigxml". Para hacer esto, debe editar manualmente el archivo del proyecto (en serio). Descargamos el proyecto DebuggeePlugin y lo abrimos con el editor de estudio. Necesitamos encontrar la siguiente etiqueta XLM:

 <None Include="DkmEntryPointNotificationService.vsdconfigxml" /> 

y mueva esta etiqueta a su propio ItemGroup, cambiando el tipo de None a VsdConfigXmlFiles:

 <ItemGroup> <VsdConfigXmlFiles Include="DkmEntryPointNotificationService.vsdconfigxml" /> </ItemGroup> 

Puede guardar y volver a cargar el proyecto.

Ahora, ve a las configuraciones. Lo primero que debe hacer: si el archivo vsdconfig.xsd se agrega al proyecto DebuggeePlugin, entonces debe eliminarse. Lo reemplazaremos ahora, porque es más fácil trabajar con texto sin formato. Abra DkmEntryPointNotificationService.vsdconfigxml y reemplace el texto con lo siguiente:

 <?xml version="1.0" encoding="utf-8"?> <Configuration xmlns="http://schemas.microsoft.com/vstudio/vsdconfig/2008"> <ManagedComponent ComponentId="422413E1-450E-40A6-AE24-7E80A81CC668" ComponentLevel=^_^quot𘙮quot^_^ AssemblyName="DebuggeePlugin"> <Class Name="DebuggeePlugin.DkmEntryPointNotificationService"> <Implements> <InterfaceGroup> <NoFilter/> <Interface Name="IDkmEntryPointNotification"/> </InterfaceGroup> </Implements> </Class> </ManagedComponent> </Configuration> 

En cualquiera de estos archivos, se nos solicitará que indiquemos lo siguiente:

1. ComponentId: este valor se puede generar utilizando la herramienta de generación de GUID (Herramientas -> CreateGUID)
2. ComponentLevel es el nivel de nuestro componente en la jerarquía. Consulte la tabla anterior y la información de ayuda sobre MSDN para seleccionar el rango de valores deseado.
3. Assemblyname es el nombre de nuestro ensamblado (¡no es una solución!). En este caso, habrá un DebuggeePlugin
4. Nombre de clase: debe indicarse, incluido el espacio de nombres en el que se encuentra la clase. En este caso, DebuggeePlugin.DkmEntryPointNotificationService
5. Matriz InterfaceGroup: cada entrada en ella indica una interfaz implementada por este componente. Dentro de cada nodo de InterfaceGroup, debe haber un subnodo que indique las interfaces comunes a todos, en este grupo, filtro, pero sobre filtros más adelante. Ahora solo tenemos un nodo de interfaz y lleva el nombre de la interfaz IdkmEntryPointNotification. Si tuviéramos varias interfaces, habría varios nodos de interfaz.

Permítame recordarle que para cada clase que debería recibir notificaciones del depurador, debe haber dicho archivo. Pero la diversión no termina ahí. Cada uno de estos archivos, posteriormente, se recopila en un archivo .vsdconfig en el directorio de salida del proyecto. Y deben referenciarse en el manifiesto del complemento. Esto se hace de la siguiente manera:

1. Después de haber generado el archivo ".vsdconfigxml", debemos ... recopilar la solución una vez, de lo contrario no tendremos ningún archivo .vsdconfig en el directorio de salida del proyecto)
2. Después de eso, abra el editor de texto para el archivo source.extension.vsixmanifest y agregue el siguiente código antes de cerrar la etiqueta PackageManifest:

  <Assets> <Asset Type="DebuggerEngineExtension" d:Source="File" Path="DebuggeePlugin.vsdconfig" /> </Assets> 

Si, después de las acciones completadas, el archivo "DebuggeePlugin.vsdconfig" aparece en el proyecto HelloVSIX, debe RETIRARSE DEL PROYECTO y la solución debe recopilarse nuevamente, de lo contrario no se actualizará.

¡El trabajo preparatorio ha terminado! Puede comenzar a depurar nuestro complemento. Esto se realiza mediante el lanzamiento de una instancia experimental de VisualStudio (para proyectos VSIX, este es el objetivo de depuración predeterminado, por lo que no son necesarios pasos adicionales). En realidad, hacemos clic en Debug-> StartDebugging y vemos una instancia experimental de VisualStudio. En él, por defecto, nuestro complemento ya debería estar instalado. Puede verificar esto a través del menú Herramientas-> Extensiones y actualizaciones.

Debido al hecho de que implementamos la interfaz IDkmEntryPointNotification, tendremos que crear un proyecto de prueba en una instancia experimental de VisualStudio. En realidad, creamos un nuevo proyecto, seleccionamos C ++ -> Aplicación de consola (elija C ++, porque los siguientes ejemplos contendrán detalles específicos de C ++), llámelo VSIXTestApp , ejecute sin ningún cambio, recopile y vea que nuestra instancia experimental dejó de lanzar una excepción dentro del método DebuggeePlugin. DkmEntryPointNotificationService.OnEntryPoint. Genial Ahora necesita mostrar el cuadro de mensaje. Para hacer esto, es necesario agregar las siguientes referencias al proyecto DebuggeePlugin:

• Microsoft.VisualStudio.Shell.15.0
• Microsoft.VisualStudio.Shell.Interop
• Microsoft.VisualStudio.Shell.Interop.8.0
• Microsoft.VisualStudio.OLE.Interop

Agregue dos usos al comienzo del archivo DkmEntryPointNotificationService.cs:

 using Microsoft.VisualStudio.Shell; using Microsoft.VisualStudio.Shell.Interop; 

Y agregue una llamada al método VsShellUtilities.ShowMessageBox en el método DkmEntryPointNotificationService.OnEntryPoint:

 using Microsoft.VisualStudio.Debugger; using Microsoft.VisualStudio.Debugger.ComponentInterfaces; using Microsoft.VisualStudio.Shell; using Microsoft.VisualStudio.Shell.Interop; using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DebuggeePlugin { class DkmEntryPointNotificationService : IDkmEntryPointNotification { public void OnEntryPoint(DkmProcess process, DkmThread thread, DkmEventDescriptor eventDescriptor) { VsShellUtilities.ShowMessageBox(Microsoft.VisualStudio.Shell.ServiceProvider.GlobalProvider, "Hello VSIX", "Hello VSIX", OLEMSGICON.OLEMSGICON_INFO, OLEMSGBUTTON.OLEMSGBUTTON_OK, OLEMSGDEFBUTTON.OLEMSGDEFBUTTON_FIRST); } } } 

Reconstruimos, lanzamos una instancia experimental del estudio, lanzamos un proyecto de prueba y ¡listo!

¡Vemos que la instancia de prueba del estudio creó MessageBox!



¿Y qué, de hecho, se beneficia?

Aquí aprendimos cómo configurar un proyecto VSIX que contenga un complemento para el depurador de Visual Studio, teniendo en cuenta la mayoría de los matices que se interpusieron en el camino del resultado. Este es el punto de partida para un trabajo más detallado. En el próximo artículo, le mostraré otro punto importante: cómo se realiza la comunicación entre el IDE y los componentes de destino de depuración.

Para obtener más ayuda sobre el uso de la API de Concord, puede consultar no solo MSDN, sino también los siguientes repositorios de Microsoft en el github:
github.com/microsoft/PTVS
github.com/Microsoft/ConcordExtensibilitySamples