picking active project seems to have no effect

[ciel]

In the bottom right, there is an option to click on [C#] and a menu slides down to list all the projects in your solution with a project.json file. I obviously pick the one I expect I want to debug.

However this doesn't seem relevant. It doesn't seem to have any impact on the behavior of the intellisense, tool tips, or debugger.

For instance, I have this structure;

/
   /solution-name
         /src
               /project-1
               /project-2
               /project-3
               /project-4
               /project-5

project-5 is my executable; the others are libraries. so I obviously pick project-5. However when I go to configure launch.json...

{
    "name": ".NET Core Launch (console)",
    "type": "coreclr",
    "request": "launch",
    "preLaunchTask": "build",
    "program": "${workspaceRoot}/bin/Debug/<target-framework>/<project-name.dll>",
    "args": [],
    "cwd": "${workspaceRoot}",
    "stopAtEntry": false
},

Okay, for starters - I picked project-5, so I would expect that to be my ${workspaceRoot} - but it still treats the top level directory as the root.

Next, what's the purpose of having cwd if ${workspaceRoot} already exists? I tried changing it to something else and replacing the workspaceRoot variable in the program path - but it did nothing.

Then, <project-name.dll> doesn't work, either. Some of us have executable. Could this be changed to just <project-name> so we can write the extension appropriate for our environment?

We could really use some more variables to make this work;

${activeProject} - the path to the project.json you picked.
${activeRuntime} - this ought to relate to a runtime variable if we're using it. It could go beneath cwd easily.
${projectName} - as it sounds - the name of the folder containing the project.json you picked.

This would help greatly in making the debugging experience a lot more extensible. As it is now, I have hard-code the path from ${workspaceRoot} every time.

[gregg-miskelly]

I am not quite sure why the C# extension didn't generate you a launch.json for your project if it asks you. @DustinCampbell any idea?

For the various '<...>' items -- this is just trying to give you a hint of what you should manually enter. Neither VS Code or the debugger understand the '<..>' values. The '${...}' values are understood by VS Code. As far as I know, VS Code only understands -- workspaceRoot, and environment variables. VS Code is just an editor, so it is never going to understand concepts like 'activeRuntime', 'projectName', etc. So yes, everything else MUST be hard coded to fit within the VS Code model of the world.

[gregg-miskelly]

Oh, and I missed one of your questions - cwd = the working directory of your app when it initially starts.

[DustinCampbell]

Currently, the extension will only offer to generate a launch.json if the workspace is opened to a folder containing a project.json.

[troydai]

It would be nicer if the VS code has a concept of current project. In this case, when the focus is on a Program.cs for project-5 it is intuitive to expect when I start debugging the project the project-5 is the one selected.

[gregg-miskelly]

VS Code can't really have such a concept because VS Code doesn't have the concept of projects. Also, even VS doesn't automatically switch since just because you are editing a project, doesn't mean that is the project which should be the initial starting project - one project may well call into another.

I think the best we could do is have the C# extension generate a different entry in launch.json for all your launchable projects. But you would still need to manually change between them when you wanted to.

[DustinCampbell]

Another idea might be to provide a "startup project" picker. Switching this would auto re-generate the launch.json file. This would be useful if you open a higher-level folder with several projects in it.

[troydai]

OmniSharp-Roslyn should be able to figure out the current project base on the current cursor. A new endpoint can be added to get that information, and a launch.json can be generated dynamically.

[DustinCampbell]

And if the current file isn't in a project at all?

[troydai]

Fall back to the current launch.json. Or add a configuration in the launch.json act dynamically.

[troydai]

It is more useful in the case a test case is being debugged in VS code

[gregg-miskelly]

I can definitely see this be useful for tests. Are there other cases you would want it? I am kind of thinking we should do the moral equivalent to VS --

1. F5 always launches the startup project (in our case the thing that launch.json refers to)
2. There is some special command to debug the current test

[toptensoftware]

I'm struggling with this too but would be happy just with a work around that lets me run/debug one of the subprojects. Is there an example of how to do this somewhere?

Also is there a way to launch a project without the debugger attached?

[gregg-miskelly]

We didn't add a 'dotnet run' command to the extension. But certainly you can do that at the command line.

If you don't want to mess with tasks.json, you can always build the app on the command line (dotnet build) and then just configure launch.json to launch whatever you want. See 'Creating configuration files manually' in this section of the docs for more info.

[DustinCampbell]

We didn't add a 'dotnet run' command to the extension. But certainly you can do that at the command line.

yes 😄

[toptensoftware]

I finally figured this out. I was trying to build a sub-project by creating a tasks.json on the parent folder with "options/cwd" set like so:

{
    // See http://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "0.1.0",
    "command": "dotnet",
    "isShellCommand": true,
    "args": [],
    "options":  {
        "cwd": "./SubProject."
    },
    "tasks": [
        {
            "taskName": "build",
            "args": [ ],
            "isBuildCommand": true,
            "showOutput": "always",
            "problemMatcher": "$msCompile"
        }
    ]
}

which resulted in:

Failed to launch external program dotnet .
spawn dotnet ENOENT

Turns out that './SubProject' isn't relative to the workspace but some other folder. Fix is:

    "options":  {
        "cwd": "${workspaceRoot}/SubProject."
    },

Obviously this is a VSCode issue, but seemed relevant to this issue so posted it here.

@gregg-miskelly probably worth mentioning this in your linked article/example.

[gregg-miskelly]

Done: gregg-miskelly@c5687f0#diff-8a97611db9953e6fd0d4c8c861fc8ebe

Let me know if you have any other suggestions