Organization of debugger settings

[wesrupert]

As we start adding more configuration to the extension, it's worth looking at where we want various options to go. Currently, we're adding debugger options to the root of the launch configuration, e.g.

"configurations": [
    {
        "name": ".NET Core Launch (web)",
        "type": "coreclr",
        "request": "launch",
        "<other settings>": "...",
        "stopAtEntry": false,
        "justMyCode": false,
        "<other debugger setting>": "..."
    }
]

However, as we continue to add more features and configuration, this route will both add length to a disorganized and loosely-related list of options, but it will also negatively impact discoverability, as the current method of discovering options (reading through the intellisense) will continue to grow:

Possible improvements

1. Create a "debuggerOptions" section

"configurations": [
    {
        "name": ".NET Core Launch (web)",
        "type": "coreclr",
        "request": "launch",
        "<other settings>": "...",
        "debuggerOptions": {
            "stopAtEntry": false,
            "justMyCode": false,
            "<other debugger setting>": "..."
        }
    }
]

This allows us to group the debugger configuration in one place, making it easier to glimpse at your settings and determine how the debugger will behave during that session. This also groups debugger options in the intellisense window, like how the logging options are currently consolidated:

2. Add extension user settings

{
    "csharp.debugging.justMyCode": false,
    "csharp.debugging.<other debugger settings>": "..."
}

We currently store all of our options in the launch.json file, which means that if there's a setting that a user always wants to have a particular value that's not the default, they have to add it to every project they interact with. Some debugger options are more suited to being dependent on the user than on the project. Adding them to the user options config would allow the user to persist their debugging preferences. The Go extension, for example, saves parts of their config to the user settings.

Issues

• Either solution would add another location the user would have to look for settings, either in the user options or further in the launch.json tree (or even both).
• Whenever we decide it's worth tackling this problem it will introduce a breaking change to launch configurations, so we also need to discuss how we would make the change.

[chuckries]

I think 1. might be the way to go. I worry about it being too verbose though.

[gregg-miskelly]

For 2 - is there a good way for debug adapters to read that file?

Personally I like the fact that these options are settable from launch.json. Maybe they should also be in the user settings file though. But one thing I find annoying about VS is that if I, for example, have one project that I need to leave just my code off and another where just my code is basically always my friend I can only set them in tools options, and it would be great to be able to set some of these in both places.

[seraku24]

Adding my $0.02. I just learned there is a setting in launch.json (i.e. "internalConsoleOptions") that controls when the internal debug console shows in response to starting a debug session. There was some discussion over in microsoft/vscode#4045 that this setting might be better placed in the user's settings rather than in the project, but it looks like they ended up opting for launch.json.

Currently, the csharp extension auto-generates the launch.json without this setting, which simply results in the default behavior. As this does not work for my situation, I will need to manually make this change on any projects that I create. Assuming that this and other similar configuration settings have to live in launch.json, it could be useful to introduce some way for users to provide their own defaults to the csharp extension.

[gregg-miskelly]

@seraku24 for this particular setting, I agree with you that the default that the VS Code team choose isn't what I would pick. As of the upcoming 1.4 version of the extension, we actually generate launch.json with internalConsoleOptions -- #692.

As for some system for allowing templating of launch.json -- I can definitely see the appeal for some settings (ex: symbol paths). But the problem with that is that it will only get applied on the initial creation of launch.json. I am more inclined to think we eventually need some sort of per-user settings file to go along with launch.json. It couldn't actually work with internalConsoleOptions since that is a VS Code setting, But it could work with the set of our options where that might make sense.

[seraku24]

Thanks, @gregg-miskelly, especially for picking the option that I prefer for the debug console. (:

True, templating may have limited effectiveness. I would see it mainly helping folks like me who end up creating a fair number of small projects. Then again, I could benefit from dotnet new getting some form of templating as well.

If we can work towards giving user-centric and project-centric settings their proper homes, that would be ideal. I wonder whether extensions can party on the same system that VS Code uses for its settings, which already supports global user settings with per-workspace overrides.

[gregg-miskelly]

At this point, I can't see us reorganizing all of our options, so I am going to close this.