aspire
aspire copied to clipboard
dotnet
SQL Server Endpoint string in Resources list is unusable.
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
- Show the IP address.
- 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
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.
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.
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.
@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
Waiting on https://github.com/dotnet/aspire/pull/5380 so we can show secrets in properties
