Open JerryNixon opened 1 month ago
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:
@mitchdenny @karolz-ms @drewnoakes for their respective parts of the problem.
The resource service exposes a set of Url
s with the following properties:
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
Is there an existing issue for this?
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, like127.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
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