Solución de problemas de servicios asincrónicas
Se aplica a: Visual Studio 2019 y versiones posteriores
En este artículo se presentan sugerencias de solución de problemas y posibles soluciones para varios problemas comunes que pueden producirse al intentar obtener un servicio asincrónica en el SDK de Visual Studio.
Los servicios asincrónicas pueden producir errores de varias maneras. Una técnica útil con la que iniciar la investigación consiste en comprobar el registro de actividad de Visual Studio, que a menudo registra errores o advertencias cuando las cosas van awry con servicios asincrónicas.
Problemas al solicitar un servicio
Quizás el desafío más común con los servicios asincronados es comprender el resultado o la excepción que obtienen de una llamada a IServiceBroker.GetProxyAsync o IServiceBroker.GetPipeAsync. Un IServiceBroker objeto abstrae intencionadamente las preocupaciones sobre dónde y cómo se puede activar un servicio asincrónica. Pero cuando las cosas van mal, es necesario profundizar más para diagnosticar y corregir el problema.
Sin servicio
El resultado de una solicitud de servicio puede ser null cuando se cumple cualquiera de las condiciones siguientes:
- El servicio solicitado no está registrado. El autor del servicio asincrónica debe registrarlo con ProvideBrokeredServiceAttribute o con un archivo .pkgdef creado a mano.
- El servicio solicitado se registra con la configuración que no expone el servicio a este cliente. El ámbito predeterminado es ServiceAudience.Process, lo que significa que el servicio asincrónica solo se puede activar cuando se proffera desde el mismo proceso que el cliente. Si el cliente está en otro proceso y la intención es que el servicio asincrónica esté disponible para él, cambie el registro del servicio para expandir su ServiceAudience.
- El servicio solicitado está registrado con ServiceAudience.LiveShareGuest, existe una conexión de Live Share, pero el host no ofrece ese servicio asincrónica o la ProvideBrokeredServiceAttribute.AllowTransitiveGuestClients propiedad no está establecida
trueen . Al exponer un servicio asincrónica a través de Live Share, consulte Protección de un servicio asincrónica. - El servicio solicitado está registrado, pero falta información sobre el paquete que se va a inicializar para que se pueda proferido su fábrica. El ProvideBrokeredServiceAttribute atributo genera automáticamente el registro que indica el paquete al que se aplicó el atributo para que Visual Studio pueda cargar ese paquete según sea necesario. Si el atributo se aplica al paquete incorrecto o el archivo .pkgdef está creado a mano, es posible que esta información falte o sea inexacta.
- El paquete de Visual Studio responsable de proffering the brokered service throws during initialization or otherwise fails to proffer that service factory. Compruebe el registro de actividad de Visual Studio para obtener evidencia de un error de carga del paquete.
- El propio generador de servicios devuelve
null.
La solicitud de servicio produce una excepción.
Una solicitud de servicio puede producir una ServiceCompositionException excepción cuando la factoría de servicios produce una excepción. Esto significa que todos los problemas enumerados anteriormente que provocarían que un null resultado no se aplique. Examine los detalles de la excepción (incluidas las excepciones internas) para comprender lo que salió mal y realizar las correcciones necesarias para el cliente o la factoría de servicios.
Obtiene un servicio local mientras se esperaba uno remoto
Una solicitud se puede completar local o remotamente, según el registro del servicio y el estado actual de Visual Studio. El ámbito predeterminado es ServiceAudience.Process, lo que significa que el servicio asincrónica solo se puede activar cuando se proffera desde el mismo proceso que el cliente.
Cuando un servicio asincrónica debe exponerse desde un host de Live Share a un invitado conectado, pero está ServiceAudience limitado a ámbitos locales, una solicitud de un invitado de Live Share activará el servicio asincrónica desde ese mismo equipo en lugar del host. Actualice el registro para incluir ServiceAudience.LiveShareGuest para exponer los servicios asincrónicas a través de Live Share. También es posible que tenga que establecer en ProvideBrokeredServiceAttribute.AllowTransitiveGuestClients true .
Importante
El registro del servicio asincrónica debe existir tanto en el invitado de Live Share como en el host para admitir al invitado al activar el servicio asincrónica desde el host.
Al exponer un servicio asincrónica a través de Live Share, consulte Protección de un servicio asincrónica.
Problemas al proferir un servicio
Un servicio asincrónica debe proferirse desde una AsyncPackage clase a menos que el servicio asincrónica se exporte a través de MEF, como se describe en Cómo proporcionar un servicio asincrónica.
Un intento de proffer de un servicio asincrónica producirá una excepción si se cumple alguna de estas condiciones:
- El moniker del servicio que se está proffered no coincide exactamente con un servicio registrado (nombre y versión).
- Ya se ha representado una fábrica para el mismo moniker de servicio.
El resultado de una llamada a IBrokeredServiceContainer.Proffer es .IDisposable Un servicio asincrónica deja de estar disponible para las nuevas solicitudes después de eliminar este valor. Cuando el servicio asincrónica tiene afinidad específica con algún contexto, como una solución abierta, puede ser adecuado solo profferar el servicio asincrónica cuando ese contexto está activo. No es necesario conservar y eliminar este valor cuando se elimina el paquete.
Seguimiento de RPC entre el cliente y el servicio
Una vez establecida una conexión entre el cliente y el servicio, el seguimiento de su comunicación puede ser útil, especialmente cuando se encuentran en diferentes procesos.
De forma predeterminada, los seguimientos de las comunicaciones entre servicios asincronados que abarcan procesos (de forma que rpc se aplica) se registran en los archivos .svclog que se encuentran en el %TEMP%\VSLogs directorio. Estos archivos xml se ven mejor con el Visor de seguimiento de servicio. Esta herramienta puede abrir muchos archivos .svclog a la vez y unirlos para formar un grafo de varias partes para facilitar mucho la comprensión de RPC entre el cliente y el servicio.
Un propio servicio asincronado puede realizar un seguimiento directamente para agregarlos a estos archivos de seguimiento .svclog , lo que ayuda a realizar un diagnóstico adicional del comportamiento del servicio asincronizado. Los seguimientos guardados en %TEMP%\VSLogs se pueden recopilar cuando se invoca el comando "Notificar un problema" y el usuario decide compartir registros.
Para realizar un seguimiento de sus propios mensajes de forma que se puedan detectar y combinar fácilmente con otros seguimientos .svclog , el código (ya sea un servicio asincrónico o no) puede hacer algo parecido a esto:
// Define your log's ID, a namespace-like fully qualified name.
// In general it is expected that you follow you team's assembly namespace.
// Also an optional parameter, the ServiceMoniker for your service
var myLogId = new LogId("Microsoft.SomeTeam.MyLogName", serviceId: null);
var requestedLevel = new LoggingLevelSettings(SourceLevels.Warning | SourceLevels.ActivityTracing);
var myLogOptions = new LoggerOptions(requestedLevel, PrivacyFlags.MayContainPrivateInformation);
TraceSource myTraceSource;
using (TraceConfiguration traceConfig = await TraceConfiguration.CreateTraceConfigurationInstanceAsync(serviceBroker, ownsServiceBroker: false, cancellationToken))
{
myTraceSource = await traceConfig.RegisterLogSourceAsync(myLogId, myLogOptions, traceSource: null, cancellationToken);
}
myTraceSource Ahora se puede usar para el seguimiento, ya que tiene los agentes de escucha adecuados agregados para escribir los seguimientos en un archivo .svclog. Si ya tiene un TraceSource que desea usar, páselo al RegisterLogSourceAsync método y descarte el resultado, ya que los agentes de escucha se agregarán a su existente TraceSource.
Cuando se realiza el seguimiento desde un servicio asincrónico que sirve a un cliente remoto, se asigna automáticamente una actividad a la ExecutionContext que se ejecuta el código que permite unir el svclog junto con el svclog del cliente para ver una vista holística mediante el Visor de seguimiento de servicios.