VSCode项目启动与调试配置

不同于VS的摇篮式可视化项目管理，VSCode通过两个特殊的配置文件launch.json和tasks.json来管理启动和调试功能，下面让我们具体来看一下。

在我们打开一个项目文件夹后，如果没有经过手动配置，直接“运行→启动调试”，可以启动自动配置流程，VSCode首先会让我们选择运行环境：

然后列出文件夹下的所有项目供选择，选择一个启动项目：

VSCode会自动生成一个名为.vscode的配置文件夹，里面包含我们的主角：launch.json和tasks.json文件

launch.json
允许我们配置和保存调试设置的详细信息，在launch.json里每配置好一个启动项，在运行和调试下拉列表里就可以选择启动：
tasks.json
允许我们定义一些自动执行的诸如构建，打包，测试或部署软件系统之类的任务。

"启动"与"附加"
在VS Code中，有两种核心调试模式，即"启动"和"附加"，它们处理两种不同的工作流和开发人员。
如果你是来自浏览器背景的前端开发人员，则可能不习惯"从工具启动"，因为你的浏览器实例已打开。当你打开 DevTools 时，只需将 DevTools附加到打开的浏览器选项卡即可。另一方面，如果你是来自服务器或桌面的开发背景，则让编辑器为您启动进程是很正常的，编辑器会自动将其调试器附加到新启动的进程。

下面让我们以启动一个asp.net core的webapi项目为例，先来看一下VSCode自动帮我们生成的配置，每一项的说明我都添加在注释里。

launch.json文件：

{
	//配置器的版本信息
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PPAPI",//自定义的易读名称
            "type": "coreclr",//用于本配置的调试器类型
            "request": "launch",//本配置的请求类型
			//重要！如果要在调试会话开始前，启动一项任务（比如重新生成以保持最新），请将此属性设置为tasks.json中指定的任务的名称
            "preLaunchTask": "build",
			//启动调试器时的执行文件
            "program": "${workspaceFolder}/src/Services/XXX/bin/Debug/net6.0/XXX.dll",
			//传递给程序进行调试的参数
            "args": [],
			//当前工作目录，用于查找依赖项和其他文件
            "cwd": "${workspaceFolder}/src/Services/XXX",
			//程序启动时立即中断
            "stopAtEntry": false,
			//如果要在调试下的程序向调试控制台或集成终端输出特定消息时在 Web 浏览器中打开 URL
            "serverReadyAction": {
                "action": "openExternally",
                "pattern": "\\bNow listening on:\\s+(https?://\\S+)"
            },
			//环境变量
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "sourceFileMap": {
                "/Views": "${workspaceFolder}/Views"
            }
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach"
        }
    ]
}

可以看到除了版本信息外，最主要的是configurations节点，如果要添加多个启动项目，那就在configurations节点数组里添加一个大括号{}包裹的新的配置对象。

如果要进行多目标调试
对于涉及多个进程（例如，客户端和服务器）的复杂方案，VS Code 支持多目标调试。
使用多目标调试非常简单：启动第一个调试会话后，只需启动另一个会话即可。一旦第二个会话启动并运行，VS Code UI 就会切换到多目标模式

tasks.json文件：

{
    "version": "2.0.0",
    "tasks": [
        {
			//用户使用时调用的标签
            "label": "build",
			//要执行的实际命令
            "command": "dotnet",
			//任务的类型。对于自定义任务，这可以是shell或process。如果指定shell，则该命令被解释为 shell 命令（例如：bash、cmd 或 PowerShell）。如果指定process，则该命令被解释为要执行的进程。
            "type": "process",
            "args": [
                "build",
                "${workspaceFolder}/src/Services/XXX/XXX.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },
        {
            "label": "publish",
            "command": "dotnet",
            "type": "process",
            "args": [
                "publish",
                "${workspaceFolder}/src/Services/XXX/XXX.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },
        {
            "label": "watch",
            "command": "dotnet",
            "type": "process",
            "args": [
                "watch",
                "run",
                "${workspaceFolder}/src/Services/XXX/XXX.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        }
    ]
}

这里同样除了版本号，就是一个tasks的任务集合，可以在这里添加多个任务，比如上面自动生成了“构建”“发布”“监视”三个任务，每个任务都有自己的标识lable，在上面launch.json文件中，我们使用了"preLaunchTask": "build"来调用了tasks.json文件里定义的build任务，保证了在启动项目前，项目得到了重新生成。

了解了这些，我们就可以灵活使用这两个文件进行启动和调试了，但这两个文件的扩展性远不止这些，利用它们，我们可以实现特定于平台的属性、全局启动配置等等需求，此处不再赘述。