Move repo to 8.0.100-rtm build - #4
Merged
Merged
Conversation
Damian Edwards (DamianEdwards)
force-pushed
the
8.0.100-rtm
branch
from
October 6, 2023 18:38
ea96af5 to
1a57e51
Compare
Dan Moseley (danmoseley)
added
NO-MERGE
Damian Edwards (DamianEdwards)
force-pushed
the
8.0.100-rtm
branch
from
October 12, 2023 17:39
1a57e51 to
e8fef82
Compare
Dan Moseley (danmoseley)
added
the
area-engineering-systems
Damian Edwards (DamianEdwards)
removed
the
NO-MERGE
Damian Edwards (DamianEdwards)
enabled auto-merge (squash)
October 12, 2023 18:41
Gerald Versluis (jfversluis)
added a commit
that referenced
this pull request
Mar 4, 2026
Fix #1: Drain stdout/stderr tasks in a finally block so they are always awaited, even when WaitForExitAsync throws on cancellation. PipeOutputAsync now catches OperationCanceledException internally. Fix #2: Resolve build configuration from the AppHost's AssemblyConfigurationAttribute (same as DcpExecutor) and pass it to MauiBuildInfoAnnotation, so the pre-build and DCP's Run target use the same configuration and MSBuild's incremental build is effective. Fix #3: Add 10-minute build timeout via CancellationTokenSource so a hung dotnet build process cannot block the semaphore forever. BuildTimeout is an internal settable property for testability. Fix #4: Add tests for MauiBuildInfoAnnotation (properties, nullable), missing MauiBuildQueueAnnotation (skip), resource restart (build same resource twice), and unexpected exception types (semaphore release). Total: 90 tests passing (18 build queue + 72 existing). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adam Ratzman (adamint)
added a commit
to ellahathaway/aspire
that referenced
this pull request
May 30, 2026
Fix microsoft#1: Rename command IDs in package.json menus and walkthrough so they target the new aspire-vscode.runAppHostCommand and aspire-vscode.debugAppHostCommand registrations introduced in this PR. Without this the editor title bar, explorer context menu, and Get Started walkthrough Run/Debug buttons silently no-op. Fix microsoft#2: Wrap vscode.debug.startDebugging in try/catch in AppHostLaunchService.launch so a 'false' return value (debug adapter rejected) or thrown error clears the launching state. Otherwise the tree item is stuck showing the 'Starting...' spinner forever and the user cannot retry. Fix microsoft#3: Make AspireAppHostTreeProvider.runAppHost async and await launch so launch failures surface via showErrorMessage instead of being dropped as unhandled promise rejections. Fix microsoft#4: In workspace mode with multiple candidate AppHost paths, match running AppHosts to candidates by directory equivalence (isMatchingAppHostPath) rather than exact path. This is the same matching used elsewhere in AppHostDataRepository when correlating 'aspire ps' output to candidate paths, so canonicalization differences (case, separators, trailing slashes) no longer cause a running AppHost to display as idle. Fix microsoft#5: Introduce aspire.noRunningAppHosts context key so the Open Dashboard palette command is only enabled when at least one AppHost is actually running. Previously the palette appeared when only idle candidates were known and then silently no-oped. Fix microsoft#6: Widen the workspaceResources contextValue regex in package.json so the read-only 'Open AppHost Source' and 'Copy AppHost Path' actions appear on bare 'workspaceResources' items, not only on 'workspaceResources:hasAppHost'. The destructive 'Stop AppHost' menu remains gated on :hasAppHost. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adam Ratzman (adamint)
added a commit
that referenced
this pull request
May 30, 2026
* Show idle AppHosts in Aspire pane with Run/Debug context menu * Rename view ID from runningAppHosts to appHosts * Rename context key from noRunningAppHosts to noAppHosts * Keep panel visible when stopped AppHost has workspace candidates When an AppHost stops, the noAppHosts context key now considers workspace candidates. This ensures the panel shows idle AppHosts instead of the empty welcome view after a running AppHost is stopped. * Fix noAppHosts assertions: workspace candidates keep panel visible The _updateWorkspaceContext change (0e312f9) added !hasWorkspaceCandidates to the noAppHosts condition, meaning the panel stays visible when idle AppHosts are discovered. Two tests asserted noAppHosts=true after describe exit, but the legacy format candidate is treated as buildable (toAppHostCandidate defaults null status to 'buildable'), so workspace candidates persist and noAppHosts is correctly false. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Make workspace AppHosts expandable with launch actions * Address review feedback for PR #17506 Fix #1: Rename command IDs in package.json menus and walkthrough so they target the new aspire-vscode.runAppHostCommand and aspire-vscode.debugAppHostCommand registrations introduced in this PR. Without this the editor title bar, explorer context menu, and Get Started walkthrough Run/Debug buttons silently no-op. Fix #2: Wrap vscode.debug.startDebugging in try/catch in AppHostLaunchService.launch so a 'false' return value (debug adapter rejected) or thrown error clears the launching state. Otherwise the tree item is stuck showing the 'Starting...' spinner forever and the user cannot retry. Fix #3: Make AspireAppHostTreeProvider.runAppHost async and await launch so launch failures surface via showErrorMessage instead of being dropped as unhandled promise rejections. Fix #4: In workspace mode with multiple candidate AppHost paths, match running AppHosts to candidates by directory equivalence (isMatchingAppHostPath) rather than exact path. This is the same matching used elsewhere in AppHostDataRepository when correlating 'aspire ps' output to candidate paths, so canonicalization differences (case, separators, trailing slashes) no longer cause a running AppHost to display as idle. Fix #5: Introduce aspire.noRunningAppHosts context key so the Open Dashboard palette command is only enabled when at least one AppHost is actually running. Previously the palette appeared when only idle candidates were known and then silently no-oped. Fix #6: Widen the workspaceResources contextValue regex in package.json so the read-only 'Open AppHost Source' and 'Copy AppHost Path' actions appear on bare 'workspaceResources' items, not only on 'workspaceResources:hasAppHost'. The destructive 'Stop AppHost' menu remains gated on :hasAppHost. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Adam Ratzman <adam@adamratzman.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently blocked by regression in Blazor form handling that breaks the sample's add to cart feature dotnet/aspnetcore#50882CLI build should now be working. We're only blocked now by a Razor compiler regression that's waiting on code flow to VS to unblock building the Blazor apps in VS (Dashboard, Frontend, etc.)Related: dotnet/razor#9342Ready to go!