# Service Bus Explorer: a Windows desktop client for Azure messaging entities > A Windows Forms tool for inspecting and administering Service Bus queues, topics and subscriptions, now with Entra sign-in that avoids keeping SAS keys on disk. **paolosalvatori/ServiceBusExplorer** — The Service Bus Explorer allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. The tool provides advanced features like import/export functionality or the ability to test topic, queues, subscriptions, relay services, notification hubs and events hubs. - Repository: https://github.com/paolosalvatori/ServiceBusExplorer - Stars: 2,217 · Forks: 627 - Language: C# - License: MIT - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/paolosalvatori-servicebusexplorer ## A WinForms tool for namespaces you cannot see into Azure Service Bus queues are invisible by design. Once a message lands in a queue or a dead-letter subqueue, nothing in the portal shows you its body, its application properties or how many are sitting there right now. Service Bus Explorer is the desktop answer to that gap: it connects to a namespace as an ordinary client and turns queues, topics and subscriptions into a browsable tree. The repository is C# and the topic list says so plainly, with `windows-forms` among the topics alongside `azure-service-bus`, `azure-event-hubs`, `azure-relay` and `notification-hubs`. That topic set is worth reading as a scope statement. The tool covers Service Bus first, then the neighbouring Azure messaging services, rather than being a general Azure management console. The author is Paolo Salvatori, with Sean Feldman and Erik Mogensen named as collaborators. Release history shows Mogensen doing much of the release engineering work, which matches the shape of the repository: the tree is full of `SetVersion.ps1`, `GetNumberVersion.ps1` and `Generate-VerificationFile.ps1` alongside a `VERIFICATION-Template.txt`. ## Installing on Windows with choco, scoop, winget or a direct download The stated software requirements are Windows 10 or later and .NET Framework 4.6.2, with the README adding that it may run on other versions. Chocolatey is the path the README presents first, and the upgrade command is separate: ```bash choco install ServiceBusExplorer choco upgrade ServiceBusExplorer ``` The default executable lands in the Chocolatey tools directory, and the README points to the project's Chocolatey page for more detail. Winget is documented too: ```bash winget install --id paolosalvatori.ServiceBusExplorer --source winget ``` Version 6.3.0-preview was described in its release notes as the first preview published to WinGet, under the identifier `paolosalvatori.ServiceBusExplorer.Preview`, and that release note says it was created manually. That is worth remembering before you script an install. The GitHub route is a two-stage curl that pulls the latest release URL out of the API response: ```bash curl -s https://api.github.com/repos/paolosalvatori/ServiceBusExplorer/releases/latest | grep browser_download_url | cut -d '"' -f 4 ``` Scoop exists as an option but the README attaches a warning to it in bold: the package is not maintained by this project, it keeps an older `ServiceBusExplorer.exe.config`, and that may cause assembly loading issues, so do not use it for upgrading. A project documenting its own weakest distribution channel that bluntly is a good sign about the rest of the documentation. ## Why the configuration file setting matters before your first run The installation section opens with a recommendation that is easy to skim past: set `Configuration File for Settings and Connection Strings` to `User Configuration File`. The reason follows immediately. The `ServiceBusExplorer.exe.config` in the application directory gets overwritten on upgrade, so any changes you made there are lost. The README also warns against the obvious wrong repair. Do not overwrite the new configuration file with your old one, because the `runtime` section in the new file must not be modified. WCF configuration changes are the kind of edit that does cause assembly loading trouble later. This is the single most useful thing in the README for anyone who will use the tool more than once. Saved connections hold the endpoints you work with, and losing them on every upgrade turns a five-second tool into a re-entry exercise. ## Entra sign-in, and the two places it stops short Entitlement to read a queue is traditionally a SAS key, and a SAS key is a bearer secret that tends to end up in config files. Version 6.3.1 added interactive browser sign-in for Service Bus, described in the release notes as Microsoft Entra ID (Azure AD) authentication, alongside the same for Event Hubs. The flow is a normal connection dialog with the authentication selector switched to `Entra`. You supply the endpoint as either `sb://.servicebus.windows.net/` or the bare host name, and optionally a Tenant ID and an entity path. A saved connection then looks like this: ```text Endpoint=sb://.servicebus.windows.net/;AuthMode=AAD;TenantId=;TransportType=Amqp;EntityPath= ``` Leave the Tenant ID blank and it uses the `organizations` endpoint, which accepts work or school accounts only. Signing in with a personal Microsoft account requires entering the target tenant ID, and that account must already be a guest in the tenant holding a Service Bus data role. The README is precise about the failure mode: sign-in succeeds and then every operation is refused. Two boundaries are stated just as clearly. Interactive browser sign-in works on the public Azure cloud only, so Azure Government and Azure China are out. And Notification Hubs and Relay are not loaded when Entra is selected, which means those two entity types still need a SAS connection. Credentials are cached locally, and the `Log out from Entra` menu item clears that cache without signing you out in the browser, so a stale account can survive. ## The features that come from the 6.2.0 and 6.3.1 changes The two most recent feature releases show where the effort went. Version 6.2.0, published 2026-04-15, added a Dashboard tab with live message counts for all entities and a TreeView search or filter for queues, topics and subscriptions, along with a color threshold setting for alerts. That pair of changes is what turns the tool from an inspector into a monitoring surface. The README describes the Dashboard tab as a live overview of Active, Dead Letter, Scheduled and Total counts with auto-refresh and color-coded dead-letter alerts, and the TreeView filter is a real-time text filter reachable with Ctrl+F. Version 6.3.1, published the same day as the last push on 2026-09-15, carried further UI work: the same menu items for subscriptions as for queues, renamed dead-letter handler methods, a fix so Ctrl+F in the message text box is no longer swallowed by the TreeView filter, and a Node 24 bump in the pipelines. That last Ctrl+F fix is a small thing worth noticing, because it is the collision between a filter shortcut and a text field shortcut, the kind of bug that only surfaces once real users type in both. ## The documentation is candid about its own rough edges Two documentation details say more about the project's maturity than a feature list would. The first is a note correcting a likely mistake: the `File -> Connect to Event Grid` menu entry is for Event Grid, not Azure Service Bus, and Service Bus users should use the normal connection dialog with the authentication selector set to `Entra`. Screenshots are included for each step of the correct path, down to the authentication dropdown and the Tenant ID list in `Options | Authentication`. The second is the set of companion documents in the root: `NEWFEATURES.md`, `CHANGELOG.md`, `TESTING.md` and a separate `EventGridExplorer_README.md`. A dedicated readme for the Event Grid sibling suggests the two tools have diverged enough to need their own instructions. The repository also points at neighbouring projects rather than trying to cover them. The 6.2.0 notes changed a link to PurpleExplorer to point at an actively maintained fork, and the same release added a third-party Service Bus TUI to the tools list in the README. The 6.3.1 notes did the same for bussin. That is a maintainer telling you the edges of the territory. For a reader comparing options, the honest summary is that the Azure portal remains the place to provision namespaces, and this tool is where you go afterwards to see what the messages actually contain. ## Conclusion Service Bus Explorer earns its place on the machine of anyone debugging an Azure Service Bus namespace, because the alternatives are either portal-only or code. Its Dashboard tab with live Active, Dead Letter and Scheduled counts, plus peek and dead-letter handling, covers the questions a developer actually has when a consumer is falling behind. Three limits are worth knowing before you rely on it. It is a Windows application requiring .NET Framework 4.6.2, so it will not run natively on macOS or Linux. Interactive Entra sign-in works only on the public Azure cloud, not Azure Government or Azure China. And Notification Hubs and Relay do not load when Entra authentication is selected, so SAS connections remain necessary for those two. Follow the README's advice to set the configuration file to the user configuration file before your first run, or upgrades will overwrite your settings. ## FAQ ### What is Service Bus Explorer? It is a Windows desktop application, written in C# with Windows Forms, that connects to an Azure Service Bus namespace and lets you browse and administer queues, topics and subscriptions. It also covers Relay services, Notification Hubs and Event Hubs, and it requires Windows 10 or later with .NET Framework 4.6.2. ### How do I check Service Bus queue messages? Connect the tool to your namespace and use the peek and receive commands on the queue in the tree. The Dashboard tab added in version 6.2.0 shows live Active, Dead Letter, Scheduled and Total counts for all queues and subscriptions with auto-refresh, and the Copy message body button puts a message from the preview pane on your clipboard. ### Can Service Bus Explorer connect without a SAS key? Yes, since version 6.3.1 it supports interactive browser sign-in through Microsoft Entra ID, so the namespace can be browsed without storing SAS secrets locally. The limits are that it works on the public Azure cloud only, and Notification Hubs and Relay are not loaded when Entra authentication is selected. ## Sources - [Issues](https://github.com/paolosalvatori/ServiceBusExplorer/issues) - [License: MIT](https://github.com/paolosalvatori/ServiceBusExplorer/blob/main/LICENSE) - [paolosalvatori/ServiceBusExplorer on GitHub](https://github.com/paolosalvatori/ServiceBusExplorer) - [README](https://github.com/paolosalvatori/ServiceBusExplorer/blob/main/README.md) - [Releases](https://github.com/paolosalvatori/ServiceBusExplorer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paolosalvatori-servicebusexplorer