Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden die .NET-Ausnahmen aufgeführt, die von .NET Framework-APIs generiert werden.
Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.
Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung zur Einstellung des Supports.
Ausnahmekategorien
Die Messaging-APIs generieren Ausnahmen, die in die folgenden Kategorien fallen können, sowie die zugeordnete Aktion, die Sie ausführen können, um sie zu beheben. Die Bedeutung und Ursachen einer Ausnahme können je nach Typ der Messagingentität variieren:
- Fehler der Benutzercodierung (System.ArgumentException, System.InvalidOperationException, System.OperationCanceledException, System.Runtime.Serialization.SerializationException). Allgemeine Aktion: Versuchen Sie, den Code zu beheben, bevor Sie fortfahren.
- Setup-/Konfigurationsfehler (Microsoft.ServiceBus.Messaging.MessagingEntityNotFoundException, System.UnauthorizedAccessException. Allgemeine Aktion: Überprüfen Sie Ihre Konfiguration, und ändern Sie sie bei Bedarf.
- Vorübergehende Ausnahmen (Microsoft.ServiceBus.Messaging.MessagingException, Microsoft.ServiceBus.Messaging.ServerBusyException, Microsoft.ServiceBus.Messaging.MessagingCommunicationException). Allgemeine Aktion: Wiederholen Sie den Vorgang, oder benachrichtigen Sie Benutzer. Die
RetryPolicyKlasse im Client-SDK kann so konfiguriert werden, dass Wiederholungen automatisch verarbeitet werden. Weitere Informationen finden Sie unter "Wiederholungsanleitungen". - Andere Ausnahmen (System.Transactions.TransactionException, System.TimeoutException, Microsoft.ServiceBus.Messaging.MessageLockLostException, Microsoft.ServiceBus.Messaging.SessionLockLostException). Allgemeine Aktion: spezifisch für den Ausnahmetyp; verweisen Sie auf die Tabelle im folgenden Abschnitt:
Von Bedeutung
- Azure Service Bus wiederholt einen Vorgang nicht, wenn bei einer in einem Transaktionsbereich befindlichen Operation eine Ausnahme auftritt.
- Anleitungen zu Wiederholungen, die für Azure Service Bus spezifisch sind, finden Sie unter " Wiederholungsanleitungen für Service Bus".
Ausnahmetypen
In der folgenden Tabelle sind Messaging-Ausnahmetypen und deren Ursachen sowie vorgeschlagene Aktionen aufgeführt, die Sie ausführen können.
| Ausnahmetyp | Beschreibung/Ursache/Beispiele | Vorgeschlagene Aktion | Hinweis zur automatischen/sofortigen Wiederholung |
|---|---|---|---|
| TimeoutException | Der Server reagierte nicht innerhalb des angegebenen Zeitraums auf den angeforderten Vorgang, der von OperationTimeout gesteuert wird. Möglicherweise hat der Server den angeforderten Vorgang abgeschlossen. Dies kann aufgrund von Netzwerk- oder anderen Infrastrukturverzögerungen passieren. | Überprüfen Sie den Systemstatus auf Konsistenz, und versuchen Sie es bei Bedarf erneut. Weitere Informationen finden Sie unter Timeoutausnahmen. | In einigen Fällen kann eine Wiederholung helfen. Fügen Sie dem Code eine Wiederholungslogik hinzu. |
| InvalidOperationException | Der angeforderte Benutzervorgang ist auf dem Server oder innerhalb des Diensts unzulässig. Sehen Sie sich die Details in der Ausnahmemeldung an. Beispielsweise generiert "Complete()" diese Ausnahme, wenn die Nachricht im ReceiveAndDelete-Modus empfangen wurde. | Überprüfen Sie den Code und die Dokumentation. Stellen Sie sicher, dass der angeforderte Vorgang gültig ist. | Der Wiederholungsversuch ist nicht hilfreich. |
| OperationCanceledException | Es wurde versucht, einen Vorgang für ein Objekt aufzurufen, das bereits geschlossen, abgebrochen oder verworfen wurde. In seltenen Fällen wurde die Ambient-Transaktion bereits verworfen. | Überprüfen Sie den Code, und stellen Sie sicher, dass keine Vorgänge für verworfene Objekte aufgerufen werden. | Der Wiederholungsversuch ist nicht hilfreich. |
| Nicht authorisierte Zugriffs Ausnahme | Das TokenProvider-Objekt konnte kein Token abrufen, das Token ist ungültig, oder das Token enthält nicht die Ansprüche, die zum Ausführen des Vorgangs erforderlich sind. | Stellen Sie sicher, dass der Tokenanbieter mit den richtigen Werten erstellt wird. Überprüfen Sie die Konfiguration des Zugriffssteuerungsdiensts. | In einigen Fällen kann eine Wiederholung helfen. Fügen Sie dem Code eine Wiederholungslogik hinzu. |
|
ArgumentException ArgumentNullException ArgumentOutOfRangeException |
Mindestens eines der für die Methode bereitgestellten Argumente ist ungültig. Der für NamespaceManager oder Create bereitgestellte URI enthält Pfadsegmente. Das für NamespaceManager oder Create bereitgestellte URI-Schema ist ungültig. Der Eigenschaftswert ist größer als 32 KB. |
Überprüfen Sie den aufrufenden Code, und stellen Sie sicher, dass die Argumente richtig sind. | Der Wiederholungsversuch ist nicht hilfreich. |
| MessagingEntityNotFoundException | Die dem Vorgang zugeordnete Entität ist nicht vorhanden oder wurde gelöscht. | Stellen Sie sicher, dass die Entität vorhanden ist. | Der Wiederholungsversuch ist nicht hilfreich. |
| MessageNotFoundException | Versuchen Sie, eine Nachricht mit einer bestimmten Sequenznummer zu empfangen. Diese Nachricht wurde nicht gefunden. | Stellen Sie sicher, dass die Nachricht noch nicht empfangen wurde. Überprüfen Sie in der Warteschlange für unzustellbare Nachrichten, ob die Nachricht als unzustellbar gekennzeichnet wurde. | Der Wiederholungsversuch ist nicht hilfreich. |
| MessagingCommunicationException (Englisch) | Der Client kann keine Verbindung mit Service Bus herstellen. | Stellen Sie sicher, dass der angegebene Hostname korrekt ist und der Host erreichbar ist. Wenn Ihr Code in einer Umgebung mit einer Firewall/einem Proxy ausgeführt wird, stellen Sie sicher, dass der Datenverkehr an die ServiceBus-Domäne/IP-Adresse und die Ports nicht blockiert ist. |
Ein erneuter Versuch kann hilfreich sein, wenn gelegentlich Verbindungsprobleme vorkommen. |
| ServerBusyException | Der Dienst kann die Anforderung derzeit nicht verarbeiten. | Der Client kann für einen bestimmten Zeitraum warten und dann den Vorgang wiederholen. | Der Client kann nach bestimmten Intervallen erneut versuchen. Wenn ein Wiederholungsversuche zu einer anderen Ausnahme führt, überprüfen Sie das Wiederholungsverhalten dieser Ausnahme. |
| MessagingException (Messaging-Ausnahme) | Generische Messaging-Ausnahme, die in den folgenden Fällen ausgelöst werden kann: Es wird versucht, einen QueueClient mit einem Namen oder Pfad zu erstellen, der zu einem anderen Entitätstyp gehört (z. B. ein Thema). Es wird versucht, eine Nachricht zu senden, die größer als 256 KB ist. Beim Verarbeiten der Anforderung ist ein Fehler auf dem Server oder Dienst aufgetreten. Sehen Sie sich die Details in der Ausnahmemeldung an. In der Regel handelt es sich um eine vorübergehende Ausnahme.Die Anforderung wurde beendet, da die Entität gedrosselt wird. Fehlercode: 50001, 50002, 50008. |
Überprüfen Sie den Code, und stellen Sie sicher, dass nur serialisierbare Objekte für den Nachrichtentext verwendet werden (oder einen benutzerdefinierten Serialisierer verwenden). Überprüfen Sie die Dokumentation für die unterstützten Werttypen der Eigenschaften, und verwenden Sie nur unterstützte Typen. Überprüfen Sie die IsTransient-Eigenschaft . Wenn dies der Fall ist, können Sie den Vorgang wiederholen. |
Ist die Ausnahme auf eine Drosselung zurückzuführen, wiederholen Sie den Vorgang nach einigen Sekunden. Das Wiederholungsverhalten ist nicht definiert und kann in anderen Szenarien möglicherweise nicht hilfreich sein. |
| MessagingEntityAlreadyExistsException | Versuchen Sie, eine Entität mit einem Namen zu erstellen, der bereits von einer anderen Entität in diesem Dienstnamespace verwendet wird. | Löschen Sie die vorhandene Entität, oder wählen Sie einen anderen Namen für die zu erstellende Entität aus. | Der Wiederholungsversuch ist nicht hilfreich. |
| QuotaExceededException | Die Messaging-Entität hat ihre maximale zulässige Größe erreicht, oder die maximale Anzahl von Verbindungen zu einem Namespace wurde überschritten. | Schaffen Sie Platz in der Entität, indem Sie Nachrichten aus der Entität oder ihren Unterwarteschlangen empfangen. Weitere Informationen finden Sie unter QuotaExceededException. | Eine Wiederholung kann helfen, wenn in der Zwischenzeit Nachrichten entfernt wurden. |
| RuleActionException | Service Bus gibt diese Ausnahme zurück, wenn Sie versuchen, eine ungültige Regelaktion zu erstellen. Service Bus fügt diese Ausnahme zu einer unzustellbaren Nachricht hinzu, wenn beim Verarbeiten der Regelaktion für diese Nachricht ein Fehler festgestellt wird. | Überprüfen Sie die Regelaktion auf ihre Richtigkeit. | Der Wiederholungsversuch ist nicht hilfreich. |
| FilterAusnahme | Service Bus gibt diese Ausnahme zurück, wenn Sie versuchen, einen ungültigen Filter zu erstellen. Service Bus fügt diese Ausnahme zu einer unzustellbaren Nachricht hinzu, wenn beim Verarbeiten des Filters für diese Nachricht ein Fehler festgestellt wird. | Überprüfen Sie den Filter auf Richtigkeit. | Der Wiederholungsversuch ist nicht hilfreich. |
| SessionCannotBeLockedException | Versuchen Sie, eine Sitzung mit einer bestimmten Sitzungs-ID zu akzeptieren, die Sitzung ist jedoch derzeit von einem anderen Client gesperrt. | Stellen Sie sicher, dass die Sitzung von anderen Clients entsperrt ist. | Die Wiederholung kann hilfreich sein, wenn die Sitzung in der Zwischenzeit freigegeben wurde. |
| TransactionSizeExceededException | Zu viele Vorgänge sind Teil der Transaktion. | Verringern Sie die Anzahl der Vorgänge, die Teil dieser Transaktion sind. | Der Wiederholungsversuch ist nicht hilfreich. |
| MessagingEntityDisabledException | Anforderung eines Laufzeitvorgangs für eine deaktivierte Entität. | Aktivieren Sie die Entität. | Die Wiederholung kann hilfreich sein, wenn die Entität in der Zwischenzeit aktiviert wurde. |
| NoMatchingSubscriptionException | Service Bus gibt diese Ausnahme zurück, wenn Sie eine Nachricht an ein Thema senden, das die Vorfilterung aktiviert hat und keine der Filter übereinstimmen. | Stellen Sie sicher, dass mindestens ein Filter übereinstimmt. | Der Wiederholungsversuch ist nicht hilfreich. |
| MessageSizeExceededException | Eine Nachrichtennutzlast überschreitet den Grenzwert von 256 KB. Der Grenzwert von 256 KB ist die Gesamtnachrichtengröße, die Systemeigenschaften und einen beliebigen .NET-Overhead umfassen kann. | Reduzieren Sie die Größe der Nachrichtennutzlast, und wiederholen Sie den Vorgang. | Der Wiederholungsversuch ist nicht hilfreich. |
| TransactionException (Transaktion) | Die Umgebungstransaktion (Transaction.Current) ist ungültig. Möglicherweise wurde sie abgeschlossen oder abgebrochen. Eine innere Ausnahme kann zusätzliche Informationen bereitstellen. |
Der Wiederholungsversuch ist nicht hilfreich. | |
| TransactionInDoubtException | Es wird versucht, eine Transaktion auszuführen, die zweifelhaft ist, oder es wird versucht, die Transaktion abzuschließen, und die Transaktion wird erneut zweifelhaft. | Ihre Anwendung muss diese Ausnahme behandeln (als Sonderfall), da die Transaktion möglicherweise bereits abgeschlossen wurde. | - |
QuotaExceededException
QuotaExceededException gibt an, dass ein Kontingent für eine bestimmte Entität überschritten wurde.
Hinweis
Informationen zu Servicebuskontingenten finden Sie unter "Kontingente".
Warteschlangen und Themen
Für Warteschlangen und Themen ist dies häufig die Größe der Warteschlange. Die Fehlermeldungseigenschaft enthält weitere Details, wie das folgende Beispiel zeigt:
Microsoft.ServiceBus.Messaging.QuotaExceededException
Message: The maximum entity size has been reached or exceeded for Topic: 'xxx-xxx-xxx'.
Size of entity in bytes:1073742326, Max entity size in bytes:
1073741824..TrackingId:xxxxxxxxxxxxxxxxxxxxxxxxxx, TimeStamp:3/15/2013 7:50:18 AM
Die Meldung besagt, dass das Thema seine maximale Größe überschritten hat, in diesem Fall 1GB (Standardgrenzwert).
Namensräume
Für Namespaces kann QuotaExceededException angeben, dass eine Anwendung die maximale Anzahl von Verbindungen zu einem Namespace überschritten hat. Beispiel:
Microsoft.ServiceBus.Messaging.QuotaExceededException: ConnectionsQuotaExceeded for namespace xxx.
<tracking-id-guid>_G12 --->
System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
ConnectionsQuotaExceeded for namespace xxx.
Häufige Ursachen
Für diesen Fehler gibt es zwei häufige Ursachen: die Warteschlange für unzustellbare Nachrichten und nicht funktionierende Nachrichtenempfänger.
Warteschlange für unzustellbare Nachrichten Ein Leser kann Nachrichten nicht abschließen, und die Nachrichten werden nach Ablauf der Sperre an die Warteschlange/das Thema zurückgegeben. Dies kann passieren, wenn der Leser auf eine Ausnahme stößt, die verhindert, dass brokeredMessage.Complete aufgerufen wird. Nachdem eine Nachricht 10 Mal gelesen wurde, wird sie standardmäßig in die Warteschlange für unzustellbare Nachrichten verschoben. Dieses Verhalten wird von der Eigenschaft QueueDescription.MaxDeliveryCount gesteuert und hat den Standardwert 10. Wenn sich Nachrichten in der Warteschlange für unzustellbare Nachrichten anhäufen, belegen sie Speicherplatz.
Um das Problem zu beheben, lesen und schließen Sie die Nachrichten in der Warteschlange für unzustellbare Nachrichten ab – genau wie in jeder anderen Warteschlange. Sie können die FormatDeadLetterPath-Methode verwenden, um den Pfad der Dead-Letter-Queue zu formatieren.
Empfänger beendet. Ein Empfänger hat den Empfang von Nachrichten aus einer Warteschlange oder einem Abonnement beendet. Die Möglichkeit zur Identifizierung besteht darin, die QueueDescription.MessageCountDetails-Eigenschaft zu betrachten, die den vollständigen Aufschlüsselung der Nachrichten anzeigt. Wenn die ActiveMessageCount-Eigenschaft hoch oder wächst, werden die Nachrichten nicht so schnell gelesen, wie sie geschrieben werden.
TimeoutException
Eine TimeoutException gibt an, dass ein vom Benutzer initiierter Vorgang länger dauert als das Timeout des Vorgangs.
Sie sollten den Wert der ServicePointManager.DefaultConnectionLimit-Eigenschaft überprüfen, da durch Drücken dieses Grenzwerts auch eine TimeoutException verursacht werden kann.
Es wird erwartet, dass es während oder zwischen Wartungsarbeiten, z. B. bei Service Bus-Dienstupdates (oder) Betriebssystemaktualisierungen für Ressourcen, die den Dienst ausführen, zu Timeouts kommt. Während Betriebssystemupdates werden Entitäten verschoben, und Knoten werden aktualisiert oder neu gestartet, was zu Timeouts führen kann. Details zum Servicelevelvertrag (SLA) für den Azure Service Bus-Dienst finden Sie unter SLA für Service Bus.
Warteschlangen und Themen
Bei Warteschlangen und Themen wird das Timeout entweder in der MessagingFactorySettings.OperationTimeout-Eigenschaft als Teil der Verbindungszeichenfolge oder über ServiceBusConnectionStringBuilder angegeben. Die Fehlermeldung selbst kann variieren, enthält jedoch immer den für den aktuellen Vorgang angegebenen Timeoutwert.
MessageLockLostException
Ursache
Die MessageLockLostException wird ausgelöst, wenn eine Nachricht mithilfe des PeekLock-Empfangsmodus empfangen wird und die vom Client gehaltene Sperre auf der Dienstseite abläuft.
Die Sperre einer Nachricht kann aus verschiedenen Gründen ablaufen:
- Der Timer der Sperre ist abgelaufen, bevor die Clientanwendung ihn erneuert hat.
- Die Clientanwendung hat die Sperre abgerufen, diese in einem dauerhaften Speicher gespeichert und dann neu gestartet. Nach dem Neustart betrachtete die Clientanwendung die Inflight-Nachrichten und versuchte, diese abzuschließen.
Möglicherweise tritt diese Ausnahme auch in den folgenden Szenarien auf:
- Dienstupdate
- Betriebssystemupdate
- Ändern von Eigenschaften für die Entität (Warteschlange, Thema, Abonnement) während Aufrechterhaltung der Sperre.
Beschluss
Wenn eine Clientanwendung MessageLockLostException empfängt, kann sie die Nachricht nicht mehr verarbeiten. Die Clientanwendung kann die Ausnahme optional zu Analysezwecken protokollieren, jedoch muss der Client die Nachricht verwerfen.
Da die Sperre der Nachricht abgelaufen ist, wird sie wieder in die Warteschlange (oder das Abonnement) eingereiht, sodass sie von der nächsten Clientanwendung verarbeiten werden kann, die einen Empfangsaufruf sendet.
Wenn der MaxDeliveryCount überschritten wurde, wird die Nachricht möglicherweise in das DeadLetterQueue verschoben.
SessionLockLostException
Ursache
Die SessionLockLostException wird ausgelöst, wenn eine Sitzung akzeptiert wird und die vom Client gehaltene Sperre auf der Dienstseite abläuft.
Die Sperre einer Sitzung kann aus verschiedenen Gründen ablaufen:
- Der Timer der Sperre ist abgelaufen, bevor die Clientanwendung ihn erneuert hat.
- Die Clientanwendung hat die Sperre abgerufen, diese in einem dauerhaften Speicher gespeichert und dann neu gestartet. Nach diesem Neustart hat die Clientanwendung die In-Flight-Sitzungen abgerufen und versucht, die Nachrichten in diesen Sitzungen abzuschließen.
Möglicherweise tritt diese Ausnahme auch in den folgenden Szenarien auf:
- Dienstupdate
- Betriebssystemupdate
- Ändern von Eigenschaften für die Entität (Warteschlange, Thema, Abonnement) während Aufrechterhaltung der Sperre.
Beschluss
Wenn eine Clientanwendung SessionLockLostException empfängt, kann sie die Nachrichten in der Sitzung nicht mehr verarbeiten. Die Clientanwendung kann die Ausnahme zu Analysezwecken protokollieren, jedoch muss der Client die Nachricht verwerfen.
Da die Sperre der Sitzung abgelaufen ist, wird sie wieder in die Warteschlange (oder das Abonnement) eingereiht, sodass sie von der nächsten Clientanwendung, die die Sitzung akzeptiert, gesperrt werden kann. Da die Sitzungssperre immer von jeweils einer einzelnen Clientanwendung aufrechterhalten wird, wird die Reihenfolge der Verarbeitung garantiert.
SocketException (Socket-Ausnahme)
Ursache
In den folgenden Fällen wird eine SocketException ausgelöst:
- Wenn ein Verbindungsversuch fehlschlägt, weil der Host nach einem festgelegten Zeitraum nicht ordnungsgemäß reagiert hat (TCP-Fehlercode 10060)
- Eine aktive Verbindung ist fehlgeschlagen, weil der verbundene Host nicht reagiert hat.
- Fehler beim Verarbeiten der Nachricht, oder das Timeout wird vom Remotehost überschritten.
- Es liegt ein Problem mit der zugrunde liegenden Netzwerkressource vor.
Beschluss
Die SocketException-Fehler deuten darauf hin, dass der virtuelle Computer, auf dem die Anwendungen gehostet werden, den Namen <mynamespace>.servicebus.windows.net nicht in die entsprechende IP-Adresse konvertieren kann.
Überprüfen Sie, ob der folgende Befehl erfolgreich eine IP-Adresse zuweisen kann.
PS C:\> nslookup <mynamespace>.servicebus.windows.net
Dadurch sollte eine Ausgabe ähnlich der folgenden zurückgegeben werden:
Name: <cloudappinstance>.cloudapp.net
Address: XX.XX.XXX.240
Aliases: <mynamespace>.servicebus.windows.net
Wenn der obige Name nicht in eine IP-Adresse und den Namespacealias aufgelöst wird, wenden Sie sich zur weiteren Untersuchung an den Netzwerkadministrator. Die Namensauflösung erfolgt über einen DNS-Server. Diese Ressource befindet sich üblicherweise im Kundennetzwerk. Wenn die DNS-Auflösung über Azure DNS erfolgt, wenden Sie sich an den Azure-Support.
Wenn die Namensauflösung erwartungsgemäß funktioniert, überprüfen Sie hier, ob Verbindungen mit Azure Service Bus erlaubt sind.
MessagingException (Messaging-Ausnahme)
Ursache
MessagingException ist eine generische Ausnahme, die aus verschiedenen Gründen ausgelöst werden kann. Einige der Gründe sind:
- Es wird versucht, einen QueueClient in einem Thema oder einem Abonnement zu erstellen.
- Die Größe der gesendeten Nachricht ist größer als der Grenzwert für die angegebene Ebene. Erfahren Sie mehr über die Servicebuskontingente und -grenzwerte.
- Eine spezifische Datenebenenanforderung (Senden, Empfangen, Abschließen, Verwerfen) wurde aufgrund von Drosselung beendet.
- Probleme treten vorübergehend aufgrund von Dienstupgrades und Neustarts auf.
Hinweis
Die Liste der Ausnahmen ist nicht vollständig.
Beschluss
Die Lösungsschritte hängen davon ab, was dazu führte, dass messagingException ausgelöst wurde.
- Bei vorübergehenden Problemen (bei denen isTransient auf "true" festgelegt ist) oder bei Drosselungsproblemen kann das Wiederholen des Vorgangs dies beheben. Die Standardmäßige Wiederholungsrichtlinie für das SDK kann verwendet werden.
- Bei anderen Problemen geben die Details in der Ausnahme an, dass die Problem- und Lösungsschritte von demselben abgeleitet werden können.
StorageQuotaExceededException
Ursache
Die StorageQuotaExceededException wird generiert, wenn die Gesamtgröße von Entitäten in einem Premium-Namespace den Grenzwert von 1 TB pro Messagingeinheit überschreitet.
Beschluss
- Erhöhen der Anzahl der Messagingeinheiten, die dem Premium-Namespace zugewiesen sind
- Wenn Sie bereits maximal zulässige Messagingeinheiten für einen Namespace verwenden, erstellen Sie einen separaten Namespace.
Nächste Schritte
Die vollständige Service Bus .NET-API-Referenz finden Sie in der Azure .NET-API-Referenz. Tipps zur Problembehandlung finden Sie im Handbuch zur Problembehandlung.