Freigeben über

Problembehandlung für Brokerdienste

  • Artikel

Gilt für: Visual Studio 2019 und höhere Versionen

In diesem Artikel werden Vorschläge zur Problembehandlung und mögliche Lösungen für mehrere häufige Probleme vorgestellt, die auftreten können, wenn Sie versuchen, einen brokerierten Dienst im Visual Studio SDK abzurufen.

Brokerdienste können auf verschiedene Arten fehlschlagen. Eine nützliche Methode, mit der Sie ihre Untersuchung beginnen können, ist das Überprüfen des Visual Studio-Aktivitätsprotokolls, das häufig Fehler oder Warnungen protokolliert, wenn es um brokerierte Dienste geht.

Probleme beim Anfordern eines Diensts

Die wahrscheinlich häufigste Herausforderung bei brokerierten Diensten besteht darin, das Ergebnis oder die Ausnahme zu verstehen, die sie durch einen Aufruf IServiceBroker.GetProxyAsync von oder IServiceBroker.GetPipeAsyncerhalten. Ein IServiceBroker abstrahiert absichtlich Bedenken darüber, wo und wie ein vermittelter Dienst aktiviert werden kann. Aber wenn etwas schief geht, ist es notwendig, einen tieferen Drilldown auszuführen, um das Problem zu diagnostizieren und zu beheben.

Kein Dienst

Das Ergebnis einer Dienstanforderung kann sein null , wenn eine der folgenden Bedingungen zutrifft:

  • Der angeforderte Dienst ist nicht registriert. Der Brokerdienstautor sollte ihn bei ProvideBrokeredServiceAttribute oder einer von Hand erstellten PKGDEF-Datei registrieren.
  • Der angeforderte Dienst wird mit einer Konfiguration registriert, die den Dienst nicht für diesen Client verfügbar macht. Der Standardbereich ist ServiceAudience.Process. Dies bedeutet, dass der Brokerdienst nur aktiviert werden kann, wenn er aus demselben Prozess wie der Client stammt. Wenn sich der Client in einem anderen Prozess befindet und der brokerierte Dienst für ihn verfügbar sein soll, ändern Sie die Dienstregistrierung, um ihre ServiceAudiencezu erweitern.
  • Der angeforderte Dienst ist bei ServiceAudience.LiveShareGuestregistriert, eine Live Share-Verbindung ist vorhanden, aber der Host bietet diesen Brokerdienst nicht an, oder die ProvideBrokeredServiceAttribute.AllowTransitiveGuestClients Eigenschaft ist nicht auf truefestgelegt. Wenn Sie einen brokerierten Dienst über Live Share verfügbar machen, lesen Sie Schützen eines brokerierten Diensts.
  • Der angeforderte Dienst ist registriert, aber es fehlen Informationen darüber, welches Paket initialisiert werden soll, damit seine Factory proffered werden kann. Das ProvideBrokeredServiceAttribute Attribut generiert automatisch eine Registrierung, die das Paket angibt, auf das das Attribut angewendet wurde, damit Visual Studio das Paket nach Bedarf laden kann. Wenn das Attribut auf das falsche Paket angewendet wird oder die PKGDEF-Datei von Hand erstellt wurde, fehlen diese Informationen möglicherweise oder sind ungenau.
  • Das Visual Studio-Paket, das für die Bereitstellung des brokerierten Diensts verantwortlich ist, löst während der Initialisierung aus oder kann diese Dienstfactory nicht tatsächlich vermitteln. Überprüfen Sie das Visual Studio-Aktivitätsprotokoll auf Hinweise auf einen Fehler beim Laden des Pakets.
  • Die Dienstfactory selbst gibt zurück null.

Die Dienstanforderung löst eine Ausnahme aus.

Eine Dienstanforderung löst möglicherweise eine aus ServiceCompositionException , wenn die Service Factory eine Ausnahme auslöst. Dies bedeutet, dass alle oben aufgeführten Probleme, die zu einem null Ergebnis führen würden, nicht zutreffen. Sehen Sie sich die Ausnahmedetails (einschließlich der inneren Ausnahmen) an, um zu verstehen, was schiefgelaufen ist, und nehmen Sie alle erforderlichen Korrekturen am Client oder der Dienstfactory vor.

Sie erhalten einen lokalen Dienst, während ein Remotedienst erwartet wurde

Abhängig von der Dienstregistrierung und dem aktuellen Status von Visual Studio kann eine Anforderung lokal oder remote erfüllt werden. Der Standardbereich ist ServiceAudience.Process. Dies bedeutet, dass der Brokerdienst nur aktiviert werden kann, wenn er aus demselben Prozess wie der Client stammt.

Wenn ein Brokerdienst von einem Live Share-Host für einen verbundenen Gast verfügbar gemacht werden soll, der ServiceAudience jedoch auf lokale Bereiche beschränkt ist, aktiviert eine Anforderung von einem Live Share-Gast den Brokerdienst von demselben Computer und nicht vom Host. Aktualisieren Sie die Registrierung, um einzuschließen ServiceAudience.LiveShareGuest , um Ihre brokerierten Dienste über Live Share verfügbar zu machen. Möglicherweise müssen Sie auch auf true festlegenProvideBrokeredServiceAttribute.AllowTransitiveGuestClients.

Wichtig

Die Registrierung für den vermittelten Dienst muss sowohl auf dem Live Share-Gast als auch auf dem Host vorhanden sein, um den Gast bei der Aktivierung des vermittelten Diensts vom Host aus zu unterstützen.

Wenn Sie einen brokerierten Dienst über Live Share verfügbar machen, lesen Sie Schützen eines brokerierten Diensts.

Probleme beim Bereitstellen eines Diensts

Ein vermittelter Dienst muss von einer AsyncPackage Klasse stammen, es sei denn, der brokerierte Dienst wird über MEF exportiert, wie unter Bereitstellen eines brokerierten Diensts beschrieben.

Wenn eine der folgenden Bedingungen erfüllt ist, löst der Versuch, einen Brokerdienst zu vermitteln, eine Ausnahme aus:

  • Der Moniker für den dienst, der proffered wird, stimmt nicht genau mit einem registrierten Dienst (Name und Version) überein.
  • Eine Factory wurde bereits für den gleichen Dienstmoniker bereitgestellt.

Das Ergebnis eines Aufrufs von IBrokeredServiceContainer.Proffer ist ein IDisposable. Ein brokerierter Dienst ist für neue Anforderungen nicht mehr verfügbar, nachdem dieser Wert verworfen wurde. Wenn Ihr Brokerdienst eine bestimmte Affinität zu einem Bestimmten Kontext aufweist, z. B. einer offenen Lösung, kann es sinnvoll sein, den brokerierten Dienst nur dann zu vermitteln, wenn dieser Kontext aktiv ist. Es ist nicht erforderlich, diesen Wert beizubehalten und zu verwerfen, wenn Ihr Paket verworfen wird.

Ablaufverfolgung von RPC zwischen Client und Dienst

Sobald eine Verbindung zwischen Client und Dienst hergestellt wurde, kann die Ablaufverfolgung ihrer Kommunikation nützlich sein, insbesondere wenn sie sich in verschiedenen Prozessen befinden.

Standardmäßig werden Ablaufverfolgungen der Kommunikation zwischen brokerierten Diensten, die Prozesse umfassen (sodass RPC angewendet wird) in SVCLOG-Dateien aufgezeichnet, die %TEMP%\VSLogs sich im Verzeichnis befinden. Diese XML-Dateien können am besten mit dem Service Trace Viewer angezeigt werden. Dieses Tool kann viele SVCLOG-Dateien gleichzeitig öffnen und zu einem Mehrparteiendiagramm zusammenfügen, um das Verständnis des RPC zwischen Client und Dienst zu vereinfachen.

Ein Brokerdienst selbst kann direkt nachverfolgen, um diesen SVCLOG-Ablaufverfolgungsdateien hinzuzufügen, was Diagnose des Brokerdienstverhaltens weiter unterstützt. Alle in gespeicherten %TEMP%\VSLogs Ablaufverfolgungen können gesammelt werden, wenn der Befehl "Problem melden" aufgerufen wird und der Benutzer sich für die Freigabe von Protokollen entscheidet.

Um Ihre eigenen Nachrichten so nachzuverfolgen, dass sie leicht ermittelt und mit anderen SVCLOG-Ablaufverfolgungen kombiniert werden können, kann Ihr Code (unabhängig davon, ob ein Brokerdienst ist oder nicht) etwas wie folgt ausführen:

// 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);
}

Kann myTraceSource jetzt für die Ablaufverfolgung verwendet werden, da die entsprechenden Listener hinzugefügt werden, um Ihre Ablaufverfolgungen in eine SVCLOG-Datei zu schreiben. Wenn Sie bereits über einen TraceSource verfügen, den Sie verwenden möchten, übergeben Sie es an die RegisterLogSourceAsync -Methode, und verwerfen Sie das Ergebnis, da die Listener ihrem vorhandenen TraceSourcehinzugefügt werden.

Bei der Ablaufverfolgung von einem Brokerdienst, der einen Remoteclient bedient, wird automatisch eine Aktivität dem zugewiesen, in dem ExecutionContext Ihr Code ausgeführt wird. Dadurch kann das svclog mit dem svclog des Clients zusammengefügt werden, um eine ganzheitliche Ansicht mithilfe des Dienstablaufverfolgungs-Viewers anzuzeigen.

References