Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 30, 2025

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/)

    • Orchestrates Azure Functions backend and Blazor WASM frontend
    • Uses AddAzureFunctionsProject with connection string to existing Azurite instance
  • ServiceDefaults project (explainpowershell.servicedefaults/)

    • OpenTelemetry, health checks, service discovery, HTTP resilience
  • README.md - Documents both Aspire (recommended) and traditional workflows

  • launchSettings.json fix - dotnetRunMessages string→boolean for Aspire compat

Usage

./bootstrap.ps1  # First-time setup
# Start Azurite via VS Code: "Azurite: Start Table Service"
dotnet run --project explainpowershell.apphost  # Start everything

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

I'd like to investigate if using Aspire is a good fit for the Explainpowershell project. I originally had a dev ontainer setup, the idea being that anyone could easily spin up a dev env that just worked. Spoiler, it didn't really work that smoothly. Mostly overhead in terms of updates, downloads. Would Aspire be a good fit instead? It needs to provide ease of use, little overhead, and result in an easy to set up dev environment.


💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Copilot AI and others added 2 commits November 30, 2025 18:01
Co-authored-by: Jawz84 <26464885+Jawz84@users.noreply.github.com>
Co-authored-by: Jawz84 <26464885+Jawz84@users.noreply.github.com>
Copilot AI changed the title [WIP] Investigate Aspire for Explainpowershell dev environment Add .NET Aspire integration for simplified local development Nov 30, 2025
Copilot AI requested a review from Jawz84 November 30, 2025 18:08
@Jawz84
Copy link
Owner

Jawz84 commented Nov 30, 2025

@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>
Copy link
Contributor Author

Copilot AI commented Nov 30, 2025

@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 ...

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)

@Jawz84
Copy link
Owner

Jawz84 commented Nov 30, 2025

@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?

Copy link
Contributor Author

Copilot AI commented Nov 30, 2025

@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 c...

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:

  • Single-command startup of backend + frontend
  • Unified dashboard for logs/traces/metrics during development
  • Service discovery between projects

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:

  • Pro: Single command to start everything, nice dashboard
  • Con: Additional projects to maintain, Aspire version updates

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants