VS Code Setup for Multi Root Workspace with Different Environments

When using VS Code for Developing an App that is made up of Two Separate Apps, for example :

.Net API Server

/dev/apiServer/ApiServer.csproj

NodeJs ReactJs Web Ui

/dev/webUi/package.json

I am able to add both directories to the VS Code Workspace, but the way that it works is very mysterious to me.

In the Solution Explorer it automatically added the .Net Solution, so I can Run the Debugger for the ApiServer.csproj (no idea how it does this).

I was just wondering if there was a way to Run the Debugger for the NodeJs App. It seems like there's things running automatically that lock it into one Framework (in my case .Net).

Sorry if I'm not making much sense, VS Code is very mysterious to me, I'm just used to using Sublime and Terminals

Please see the discussion in the comments. The problem to be solved is two or more projects, depending on each other, launched in parallel.

Basically, VSCode documentation shows two alternative approaches: one is based on a preLaunchTask specified for one of the configurations of some launch.json file, and another one is the compounds approach. Everything is described here: https://code.visualstudio.com/docs/debugtest/debugging-configuration, see also the compound launch configuration.

Everything, but not everything. I also had to figure out the path and location issues with a multi-root workspaces.

The compound configuration always works in a single-root workspace. For the multi-root configuration, you need a place for the single launch.json file. If your just placed the .vscode directory it in the workspace root, it would not be visible. You need to place it as a sub-directory of one of the roots listed in your main workspace file.

Just for simplicity and the symmetricity, I created an additional root just for the compound launch.json, so my file structure looks like this:

Multi-root-workspace-directory\
   Compound\
      .vscode\
         launch.json
   projectOne\
   projectTwo\
   multi.code-workspace

I listed all three sub-directories as multiple roots in the file multi.code-workspace:

{
  "folders": [
    { "path": "Compound" },
    { "path": "projectOne" },
    { "path": "projectTwo" }
  ],
  "settings": {}
}

I use the path "Compound" only to make the file launch.json visible and operational, that's the only purpose. You can place your launch.json in any other path listed in "folders".

The content of launch.json is:

{
    "version": "0.2.0",
    "configurations": [
        {
            "...": "...".
            "name": "One",
        },
        {
            "type": "chrome",
            "request": "launch",
            "name": "Two",
            "file": "${workspaceFolder}/../projectTwo/index.html"
        },
    ],
    "compounds": [
        {
            "name": "Compound",
            "configurations": [
                "One", "Two",
            ]
        }
    ]
}

I have defined the projectTwo as a Chrome configuration just to illustrate the path settings: the directory ${workspaceFolder} is the parent root of Compound\. Therefore, we need /.. for the paths relative to the directory Compound.

Everything is started in the order shown in compounds/configuration: One, and then Two.

Now, I found one limitation specific to the chrome configurations: you can have only one in the compounds. In you have two or more chrome configurations in the compounds, you have the Unable to attach to browser error message. This problem does not exist for firefox configuration: when, in the launch.json shown above, one or all of the configurations are firefox, they all can be launched in parallel.

This limitation is not actual if your first configuration is some service not running a browser.

And not forget about the preLaunchTask option: it could simplify things for you, compared to the compound approach.

Added:

I forgot to add one more option: you can create two separate single-root workspaces. The will allow you to start two instances of VSCode. If you have two different launch configurations in them, you can launch your codes in parallel in any order and use stepwise debugging in both instances. This approach always works and is the most universal. Everything else is a matter of convenience.