为何dotnet run启动两个进程？如何解决VS2017调试重附加问题？

我之前帮不少开发者处理过这个问题，其实这是.NET Core 2.x里dotnet run命令的设计机制导致的，咱们一步步拆解：

为什么会出现两个dotnet进程？ #

当你在PowerShell里执行dotnet run时，会启动两个进程：

• 第一个是dotnet CLI宿主进程：这个进程负责解析你的命令行参数、检查项目是否需要编译、处理依赖加载等前置工作。
• 第二个是你的应用实际运行进程：CLI宿主进程完成准备工作后，会单独启动另一个dotnet.exe进程，用来加载并执行你的应用程序集（比如YourApp.dll）。

这种设计是为了让CLI和应用运行环境隔离，方便快速重启、编译更新等场景，但也确实会给调试带来困扰——VS2017里两个同名进程会让你分不清该附加哪一个，尤其是重新调试时容易出错。

解决办法 #

这里有几个实用的方案，你可以根据自己的场景选择：

1. 跳过dotnet run，直接运行应用程序集 #

先手动编译项目，再直接启动应用进程：

• 执行dotnet build完成编译
• 进入项目的输出目录（通常是bin\Debug\netcoreapp2.x）
• 运行dotnet YourApp.dll

这样只会启动一个dotnet进程，就是你的应用本身，调试时直接附加这个进程即可。

2. 在Visual Studio 2017中直接调试 #

如果是在VS里开发，完全不用手动执行dotnet run：

• 直接按F5启动调试，VS会直接启动你的应用进程，不会经过CLI宿主进程，全程只有一个dotnet进程，重新调试也不会有混淆的问题。

3. 区分进程的小技巧（必须用dotnet run时） #

如果因为某些场景必须用dotnet run，可以通过任务管理器区分两个进程：

• 打开任务管理器，切换到“详细信息”标签
• 找到两个dotnet.exe进程，查看它们的“命令行”列：
  • CLI宿主进程的命令行是dotnet run ...
  • 应用进程的命令行是dotnet YourApp.dll
    调试时选择后者附加即可。

4. 尝试使用--no-build参数 #

如果已经提前编译过项目，执行dotnet run --no-build可以跳过编译步骤，虽然不一定能完全消除双进程，但能减少CLI宿主进程的额外工作，有时候也能让进程状态更清晰。

内容的提问来源于stack exchange，提问作者PeterFromCologne