-
Notifications
You must be signed in to change notification settings - Fork 2
Add .NET Aspire integration for simplified local development #106
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
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Jawz84 <26464885+Jawz84@users.noreply.github.com>
Co-authored-by: Jawz84 <26464885+Jawz84@users.noreply.github.com>
|
@copilot Seeing this, I wonder.. the current setup in main uses func core tools, dotnet 10 sdk, and vscode with azurite, and c# extension to run and debug the project. Needing docker for azurite in a container seems like more overhead than the previous setup currently in main. |
Co-authored-by: Jawz84 <26464885+Jawz84@users.noreply.github.com>
Good point. I've updated the Aspire setup to use the VS Code Azurite extension (same as the current main setup) instead of Docker containers. Both development options now have the same prerequisites: .NET 10 SDK, PowerShell 7.4+, Azure Functions Core Tools v4, and VS Code with Azurite extension. No Docker required. (8af586b) |
|
@copilot Is Aspire a good fit for deployment too? I have a few resources in Azure (like a Foundry environment and a CDN and Frontdoor for domain name registration). These are not defined in infra as code (even though i'd like that). The filosophy with Aspire is that local and deployed envs work the same, right? This is not the case here, because we already have deployment pipelines and github actions to run them. And deploying the project through Aspire would result in a separate deployment in Azure I think? Can we reason about this a bit before changing the pull request much further? |
You're right to pause and think about this. Aspire's deployment story (azd/Aspir8) is designed for greenfield deployments and would create separate infrastructure, which conflicts with your existing Azure resources (Foundry, CDN, Frontdoor) and GitHub Actions pipelines. However, Aspire can be used purely for local development orchestration without affecting deployment. The current PR uses Aspire only for:
Your existing deployment pipelines remain unchanged - they still use the individual projects directly, not the AppHost. So the question becomes: Is the local dev experience improvement worth adding Aspire projects to the repo? The trade-offs are:
If the current VS Code tasks/launch configs work well enough for your workflow, Aspire may be overkill. Happy to revert this PR if you'd prefer to keep things simple, or we can discuss further. |
Replaces the abandoned devcontainer setup with .NET Aspire orchestration. Single command starts all services using the existing VS Code Azurite extension.
Changes
AppHost project (
explainpowershell.apphost/)AddAzureFunctionsProjectwith connection string to existing Azurite instanceServiceDefaults project (
explainpowershell.servicedefaults/)README.md - Documents both Aspire (recommended) and traditional workflows
launchSettings.json fix -
dotnetRunMessagesstring→boolean for Aspire compatUsage
Aspire dashboard provides unified logs/traces/metrics across all services.
Prerequisites
.NET 10 SDK, PowerShell 7.4+, Azure Functions Core Tools v4, VS Code with Azurite extension
No Docker required - uses the same Azurite setup as the traditional workflow.
Original prompt
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.