Simplify generated launch.json

[isidorn]

Hey,

VSCode dev here. This milestone I am looking into simplifing generated launch.json for various extensions microsoft/vscode#62851

The launch.json that C# generates is attached at the end. This is far too complex for the avarage user. I suggest to simplify it the following way:

• DebugConfigurationProvider should use the quickPick to ask the user if he would like to debug the console or a web app or to attach. After that it should ask what is the target framework and what is the project name if he did not choose attach. Optimally it should be able to detect those things on its own, but if not possible use quickPick to ask the user.
• Remove default fields which are not necessery like internalConsoleOptions, args, cwd
• Do users ever change anything in the launchBrowser, env and sourceFileMap properties. If no than these properties should be append in the resolveConfiguraiton calls. That way the user will not see any of this and there will be far less clutter
• You are already contributing configuraitonSnippets which is great. However these snippets also need to be simplified. I suggest to remove all attributes that have the default value. Example: stopAtEntry, cwd, args

If you agree with the suggestions I am making here I am also here to help with any potential questions you might have. The changes should not require a lot of work but will simplify the flow a lot imho. It should be much less complex and not too much like a wizard experience

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/<insert-target-framework-here>/<insert-project-name-here>.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "console": "internalConsole",
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart"
        },
        {
            "name": ".NET Core Launch (web)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/<insert-target-framework-here>/<insert-project-name-here>.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart",
            "launchBrowser": {
                "enabled": true,
                "args": "${auto-detect-url}",
                "windows": {
                    "command": "cmd.exe",
                    "args": "/C start ${auto-detect-url}"
                },
                "osx": {
                    "command": "open"
                },
                "linux": {
                    "command": "xdg-open"
                }
            },
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "sourceFileMap": {
                "/Views": "${workspaceFolder}/Views"
            }
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        }
    ]
}

[gregg-miskelly]

Hi Isidor,

First, we would generally like it if this template wasn't used - we really want users to let the C# extension generate a launch.json/tasks.json for them. The template is is only needed for folks with complicated projects that OmniSharp can't understand what they want to launch.

For your feedback:

DebugConfigurationProvider should use the quickPick to ask the user if he would like to debug the console or a web app or to attach.

Sounds reasonable.

After that it should ask what is the target framework and what is the project name if he did not choose attach.

I don't think I like this idea. I think the right way to improve this experience is microsoft/vscode#5202.

Remove default fields which are not necessery like internalConsoleOptions, args, cwd

I don't think it is a good idea to remove any of these from the template. internalConsoleOptions needs to be set so that it has the value 'openOnSessionStart' since that isn't the default value for VS Code. args should be there because that is probably the most common thing for folks to want to change. cwd needs to be there because in the more typical case it isn't actually set to the work space root, but rather the path to the project's folder. This is the default CWD set in full VS scenarios, and so I don't think we would want to omit this.

Do users ever change anything in the launchBrowser, env and sourceFileMap properties. If no than these properties should be append in the resolveConfiguraiton calls. That way the user will not see any of this and there will be far less clutter

env and sourceFileMap need to stay. I could imagine simplifying launchBrowser so the the default template just has the following, and the launch commands can go.

    "launchBrowser": {
        "enabled": true
    }

[isidorn]

Gregg thanks for the fast reply,

Can you please share some launch.json configurations which the C# extensions generates for the user. So we also check if something can be simplified there. If it just works that is awesome, but having a cleaner launch.json imho is always good, since users might want to customise things still.

Great for quickPick to ask the user in first step. Should be fairly simple, here's a simple example.

For the project name: can you not infer this from the project file and automatically fill this in? I do not understand why the user has to be involved here. Please note that I do not know a lot about C# :)

internalConsoleOptions: I suggest the following: do not set it, but in the resolve call if the user explicitly did not set it set it to openOnSessionStart. That way you are just changing the default value for your extensions without bothering the user.

args being there makes sense if the users change it a lot

cwd can you not infer this automatically from your project files somehow? And the user should never set this. E.g it should be hidden in the resolveConfiguration always fill it in based on project

Cool for simplifying launchBrowser. Why is that not the default? Why does it have to be in the launch.json. Do users change this often?

[isidorn]

Just a ping reminder for my questions here.
Thanks!

[gregg-miskelly]

Can you please share some launch.json configurations which the C# extensions generates for the user.

Here are the differences between the generated launch.json and what you posted:

• It will not add both the 'console' and 'web' version, but rather it will add whichever is appropriate for the startup project
• program will be filled in
• It will have comments
• cwd will be filled in with the path to the project's directory relative to the workspace folder root (ex: ${workspace}/MyStartupProjectsFolder)

RE: internalConsoleOptions - sounds reasonable

cwd can you not infer this automatically from your project files somehow?

No, because we don't know what the project is anymore at resolve time. We have talked about changing our launch.json format a bit to optionally have a project instead of a program (so the user would need to set one or the other -- see #1876). If we did this, I think we could remove cwd from the template. But so far at least, this hasn't been high enough priority to implement.

Cool for simplifying launchBrowser. Why is that not the default?

Do you mean why is launchBrowser enable=true not the default? Well, because it only makes sense for ASP.NET projects. Even for ASP.NET projects, I would expect it to be a common feature to toggle or change. Browser selection UI is given pretty prominent placement in VS for this reason.

[isidorn]

Great, thanks for the explanations.
I am just trying to give some suggestions on how to simplify this, in the end you know much better what would lead to a better c# debugging experience. So let me know if there is something on the vscode side which we could do to improve this.

[guidobouman]

Hi there,

I work at a tech agency (Q42) with rotating teams on different projects. We build anything connected to the internet, but mainly web services. Some of the web services are dotnet core, others are node or whatever stack we like to work with at that time.

Developers are free to choose their editors, and we notice that more and more developers are using VS Code. For our dotnet projects we have configured launch.json files so the developer can check out a project, build it, run it and not worry about anything. This greatly increases the onboarding experience for the dotnet core teams.

When maintaining these projects we would love the launch.json to not be concerned about the target framework. Becasue we've failed multiple times when updating the target-framework, to also test in each and every editor in use. In this case VS Code is the only odd one out. (VS & Rider both use launchSettings)

Also, my two cents regarding a launchBrowser setting: We have it disabled by default, because different developers use different browsers and VS Code does not always get the browser right. On top of that not all developers like a new tab whenever they relaunch a project. Instead a developer can see the launchSettings.json in any editor they work with, and "just" go to the url described in that file. That approach works for every editor, on every OS, with every browser.

[guidobouman]

Our usual Project launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "[PROJECT NAME] WEB",
      "type": "coreclr",
      "request": "launch",
      "program":
        "${workspaceRoot}/src/[WEB PROJECT ID]/bin/Debug/netcoreapp2.1/[WEB PROJECT ID].dll",
      "cwd": "${workspaceRoot}/src/[WEB PROJECT ID]"
    },
    {
      "name": "[PROJECT NAME] API",
      "type": "coreclr",
      "request": "launch",
      "program":
        "${workspaceRoot}/src/[API PROJECT ID]/bin/Debug/netcoreapp2.1/[API PROJECT ID].dll",
      "cwd": "${workspaceRoot}/src/[API PROJECT ID]"
    },
    {
      "name": "[PROJECT NAME] CMS",
      "type": "coreclr",
      "request": "launch",
      "program":
        "${workspaceRoot}/src/[CMS PROJECT ID]/bin/Debug/netcoreapp2.1/[CMS PROJECT ID].dll",
      "cwd": "${workspaceRoot}/src/[CMS PROJECT ID]"
    },
    {
      "name": ".NET Core Attach",
      "type": "coreclr",
      "request": "attach",
      "processId": "${command:pickProcess}"
    }
  ],
  "compounds": [
    {
      "name": "[PROJECT NAME] ALL",
      "configurations": [
        "[PROJECT NAME] Web",
        "[PROJECT NAME] API",
        "[PROJECT NAME] CMS"
      ]
    }
  ]
}

This has taken some iterations, and builds upon the defaults being picked up from the launchSettings.json files. I think this is quite minimal, and works rather well.

Builds are bing triggered separately by the developer to prevent slow launches because of forced builds before launch. (Front-enders often relaunch, but don't often rebuild)

Our front-end is run separately in the integrated terminal.