-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need more instructions on scenarios of connecting to existing resources #2359
Comments
@IEvangelist we should have a blurb like this https://learn.microsoft.com/en-us/dotnet/aspire/azure/integrations-overview?tabs=dotnet-cli#add-connection-to-existing-azure-resources closer to where people are using integrations. We could consider a better page rather than external parameters for this information https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/external-parameters#connection-string-values It's really hard to connect the dots here. |
I think it'd be more clear to have a dedicated section to cover the scenario of working with existing resources, including knowledge of what we can/can't do with existing resources in .NET Aspire. |
Can you be more specific? Share an example of what you would prefer to see and in what section of the docs. |
That's a great top level article idea. Some of that information is scattered all over the place but I like the idea of a dedicated tutorial to aggregate and link to existing content. To brain dump here on some of the answer to your questions: External resources are ones that are managed outside of aspire but are modeled into the application. If you look at this picture https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/integrations-overview#relationship-between-hosting-and-client-integrations, you see that hosting integrations can "provision" a resource and then get configuration from it and set that as an environment variable. The connection string resource skips the "provision" step as it assumes the user has already done it and just acts like a pre configured hosting integration.
Telemetry that shows up in aspire comes from the client integration, not the hosting integration. One thing that is a limitation today is that we don't show these resources in the dashboard's resources view. That means when telemetry shows up it'll show up as if it's going an an external resource (there's UX for that in the trace view).
No, you've declared it as externally managed so control rest is up to you, not aspire. That's what an externally managed resource does.
The main benefits are the ability to model the configuration across multiple projects in a single place. It means when you deploy, the tool can prompt or ask for the parameter and then flow it into all of the right places. Telling the application model about the resource means tools can do more with it at both runtime and deployment time. If you don't tell aspire about it and put it directly in the app's config then it's your responsibility to flow it into all of the right places. |
Thanks for the explanation which helps a lot. I guess an example of the aforementioned benefits would be really great. |
Type of issue
Missing information
Description
When connecting to existing resources, e.g. external mysql or redis containers running on the internet but not necessarily on Azure, just plain self-hosted containers, there's no complete sample nor even instruction on how we should configure the app host project to let it know of this project structure.
Page URL
https://learn.microsoft.com/en-us/dotnet/aspire/database/mysql-entity-framework-integration?tabs=dotnet-cli
Content source URL
https://github.com/dotnet/docs-aspire/blob/main/docs/database/mysql-entity-framework-integration.md
Document Version Independent Id
25f99b8a-bf6f-6f40-492b-fc43cb4e069b
Article author
@IEvangelist
Related Issues
The text was updated successfully, but these errors were encountered: