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

Why propose debugging C++ code with Visual Studio, but it also works with VS Code? #11661

Open
1 task
Gustl22 opened this issue Feb 1, 2025 · 5 comments
Open
1 task
Labels
e2-days Effort: < 5 days from.page-issue Reported in a reader-filed concern p2-medium Necessary but not urgent concern. Resolve when possible.

Comments

@Gustl22
Copy link
Contributor

Gustl22 commented Feb 1, 2025

Page URL

https://docs.flutter.dev/testing/native-debugging/

Page source

https://docs.flutter.dev/testing/native-debugging#debug-dart-and-cplusplus-code-using-visual-studio

Describe the problem

One can easily add a windows process to VS Code, after starting a Flutter app, also in VSCode, just with:

launch.json

        {
            "name": "Attach (Windows)",
            "type": "cppvsdbg",
            "request": "attach",
            "processId": "${command:pickProcess}",
        }

So I would propose to engage using just one IDE (here: VSCode) for developing on Windows instead of proposing to install Visual Studio.

This has the following advantages:

  • Using less storage (as no Visual Studio is needed)
  • Using less memory during development
  • No need to learn multiple IDEs
  • Debug in the same IDE (no need to switch between windows and breakpoints)

And no: one doesn't need to install Visual Studio (which requires at minimum than 20GB) vs "Visual Studio Build Tools" only (https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022) in order to develop Windows apps.

Search request for "Visual Studio 2022" where we also should engage using only the "Visual Studio Build Tools" instead of the full blown setup (but this might be another topic):
https://github.com/search?q=repo%3Aflutter%2Fwebsite+%22visual+studio+2022%22&type=code

Expected fix

Engage to use VSCode as default debugging tool for native code instead of "Visual Studio"

Additional context

I can try to rewrite the docs, but first I want your opinion, if that is something Flutter wants to engage.

I would like to fix this problem.

  • I will try and fix this problem on docs.flutter.dev.
@Gustl22 Gustl22 added the from.page-issue Reported in a reader-filed concern label Feb 1, 2025
@sfshaza2
Copy link
Contributor

sfshaza2 commented Feb 4, 2025

@DanTup, is the following section still correct? That you need both VS Code and Visual Studio to debug? https://docs.flutter.dev/testing/native-debugging#debug-dart-and-cplusplus-code-using-visual-studio

@sfshaza2 sfshaza2 added p2-medium Necessary but not urgent concern. Resolve when possible. e2-days Effort: < 5 days labels Feb 4, 2025
@DanTup
Copy link
Contributor

DanTup commented Feb 5, 2025

Unfortunately I'm not familiar enough with debugging C++ in either editor to know if there's a significant difference between these. If VS Code does work, it might not have the same features so Visual Studio might still be recommended - I would defer to someone more familiar with debugging native code than I (@stuartmorgan is this something in your area, or do you know who might be best placed to answer this? thanks!).

@stuartmorgan
Copy link
Contributor

  • Using less storage (as no Visual Studio is needed)

Not telling people to install Visual Studio would require replacement workflows for everything, not just that page. Notably this would need rewriting as well.

Is there a fully featured VS Code-based replacement for that section that isn't much more complicated and/or a worse developer experience? Important factors would be:

  • Full code completion for plugin development, including of Flutter symbols
  • A build/debug cycle that works for both application and plugin code
  • Ability to launch under the native debugger (ideally without having to manually configure a long and arcane JSON config)

Search request for "Visual Studio 2022" where we also should engage using only the "Visual Studio Build Tools" instead of the full blown setup (but this might be another topic)

I would not view it as another topic; the goal of tool instructions is to provide a simple and easily understandable path to get all the tools they need to follow our instructions, not necessarily to minimize the install footprint. If we tell people to install Build Tools, then the first time they try to follow any of our docs that tell them to open the solution in VS they will be confused, and then have to figure out what to do; this is undesirable. So actively telling people to install something other than VS would need us to rewrite anything that assumes they have VS.

Similarly, making just the change proposed here, in isolation, without reworking the other content assuming VS, is probably not something we would want to do, because otherwise we have to make this page more complex, by telling people to install and configure additional things (e.g., the C++ extension) rather than using the tool they have almost certainly already installed.

If we can provide a good end-to-end story with VS Code, however, that's definitely something that seems worth considering.

And no: one doesn't need to install Visual Studio (which requires at minimum than 20GB) vs "Visual Studio Build Tools" only

To whom is this "and no" addressed? The Flutter team is aware—as you know from your prior related PR—that Build Tools is enough to build. Has someone argued otherwise?

@sfshaza2
Copy link
Contributor

sfshaza2 commented Feb 5, 2025

Hi @stuartmorgan, all I know is encapsulated here. It sounds like I should close this issue. Thanks for you input!

@stuartmorgan
Copy link
Contributor

Not necessarily; as I said above:

If we can provide a good end-to-end story with VS Code, however, that's definitely something that seems worth considering.

I don't know if we can or not; investigating that wasn't ever a priority. I think we could leave this open so that others could investigate it and potentially put together a proposal that covers the rest of the use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
e2-days Effort: < 5 days from.page-issue Reported in a reader-filed concern p2-medium Necessary but not urgent concern. Resolve when possible.
Projects
None yet
Development

No branches or pull requests

4 participants