SQL Server Endpoint string in Resources list is unusable.

[JerryNixon]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

When a SQL Server reports something along the lines of tcp://localhost:1234 it is accurately indicating information about the sever, but it is not indicating valuable information to the developer because connection to the server requires the IP address and a comma, like 127.0.0.1,1234 which they would use in SSMS, or ADS, or VSCode, or Visual Studio SQL Server Object Explorer. Should they instead use the provided string, to novice developers this will appear correct, but will fail on them every single time.

When this is a web site or web API, the text becomes a link which can be clicked. How amazing would it be if this became a link here too - but for SQL server launching any of the tools or a simple web interface to interrogate the schema. Or even set this value programmatically when I create a SqlServer in AppHost. Sorry. I realize I just leaned into a second or even third issue. Please disregard this paragraph.

Solution

1. Show the IP address.
2. Replace the colon with a comma.

Goal

Make it so developers have it easier.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

[samsp-msft]

AFAIK this is the data that we get from DCP for the container, and don't know whether its SQL or some other component. It will probably need coordination between:

• App model to know the specifics about how an endpoint should be presented to the user for the specific service
• DCP to supply that information to the dashboard via the gRPC interface
• Dashboard to display it.

@mitchdenny @karolz-ms @drewnoakes for their respective parts of the problem.

[drewnoakes]

The resource service exposes a set of Urls with the following properties:

https://github.com/dotnet/aspire/blob/df935f4ee2e76d088235ea0fe91a0b61405cb3fe/src/Aspire.Hosting/Dashboard/proto/resource_service.proto#L113-L121

The protocol, as written, assumes that the full_url value is a valid RFC 1738 URL.

We may be able to provide a "display value" for these URLs, where some component close to DCP or the app model produces that optional display value when a different, non-URL form is required.

[karolz-ms]

DCP does not really "know" it is dealing with a SQL Server. It only understands fairly low-level objects: containers, executables, IP addresses, ports, and the like.

What does know is the SQL Server Aspire hosting package. It could collaborate with the dashboard to turn the raw (IP address:port) information into something more useful. For example, we could introduce a notion of "endpoint formatter annotation" to the Aspire model, with various formatters for different types of resources. For SQL Server, a SQL Server endpoint formatter would be able to turn raw SQL Server endpoint into a database connection string, or URL to administrative interface. And the dashboard protocol could be enhanced to decorate vanilla endpoints with these other ways of display endpoint information (produced by endpoint formatters) and expose them to users. Waving my hands a lot here, but hopefully pointing in the right direction.

[mitchdenny]

@drewnoakes this is actually an example of a context-menu extensibility scenario where someone might want to copy the SQLMS connection string from the row in the dashboard. I wish there was a good defacto web-based replacement for SQLMS that we could just host in a container like we do with PgAdmin etc