Skip to content
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

Unable to debug AppHost #247

Closed
cecilphillip opened this issue Sep 11, 2024 · 7 comments · Fixed by #257
Closed

Unable to debug AppHost #247

cecilphillip opened this issue Sep 11, 2024 · 7 comments · Fixed by #257
Assignees
Labels
bug Something isn't working

Comments

@cecilphillip
Copy link

Describe the bug
I am able to debug other projects in the solution but breakpoints don't get trigger in the AppHost.
This happens when using the AppHost configuration, but breakpoints get trigger when I use the ".NET Launch settings profile" instead

To Reproduce

  • Create a new Aspire starter application
  • Set a breakpoint in the appHost Program.cs

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

Reproducing sample
Link to a test project to reproduce the bug.

System information:

  • OS: MacOS
  • .NET version: 8
  • JetBrains Rider version: 2024.2.3
  • Aspire plugin version: 1.3.0
  • Aspire workload version: 8.2.0
@cecilphillip cecilphillip added the bug Something isn't working label Sep 11, 2024
@rafaelldi rafaelldi self-assigned this Sep 16, 2024
@rafaelldi
Copy link
Collaborator

@cecilphillip Thank you for the feedback. Actually, "it's not a bug, it's a feature". I intentionally run the Host project without a debugger attached to simplify the user experience. From what I understand, Host project is more like docker-compose.yml with the dependencies described, and you probably don't need to debug it. What are your thoughts on this? Do you have scenarios where the debugger is necessary?

@rafaelldi rafaelldi added the waiting-for-info Further information is requested from the issue reporter label Sep 16, 2024
@cecilphillip
Copy link
Author

Hi @rafaelldi. Thanks for an explanation. That makes total sense now that you say it.

I was working on some custom resources and wasn't understanding why my break points were not getting hit. Honestly I thought I was doing something wrong 😂.

My assumption was that the experience would be the same for both, with regards to debugging the app host.

Maybe there could be a small section in the plugin documentation that talks about this.

@gabynevada
Copy link

@cecilphillip Thank you for the feedback. Actually, "it's not a bug, it's a feature". I intentionally run the Host project without a debugger attached to simplify the user experience. From what I understand, Host project is more like docker-compose.yml with the dependencies described, and you probably don't need to debug it. What are your thoughts on this? Do you have scenarios where the debugger is necessary?

A very common use case would be to debug your 'composing' process, over time it will very likely get complex enough that a debugger would be helpful.

@rafaelldi rafaelldi removed the waiting-for-info Further information is requested from the issue reporter label Sep 16, 2024
@rafaelldi
Copy link
Collaborator

Thank you! I'll consider to support debugging

@ForNeVeR
Copy link

In other Rider configurations (without Aspire), Multilaunch configs allow the user to choose what they want and what they don't want to debug.

Perhaps we can add a checkbox to the Aspire configuration (unchecked by default if we consider it a better choice), to create a separate debug session for the Host projects?

@rafaelldi
Copy link
Collaborator

Nice idea!

@rafaelldi
Copy link
Collaborator

I decided to keep it simple. Just enable host debugging if it's a debugging session. I think this is the clearest option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants