控制台程序调用MSBuildWorkspace.OpenSolutionAsync()时进程意外退出求助

听起来你已经做了超细致的对比工作，这种明明示例能跑、自己的代码却直接崩溃的情况确实让人头大。结合你提到的在WorkspaceService第97行退出的信息，给你几个具体的排查方向：

1. 捕获未处理的异步异常 #

控制台应用里如果存在未捕获的异步异常，很可能直接导致进程静默退出，连错误提示都没有。建议你给调用OpenSolutionAsync的代码加上完整的异常捕获，同时确保Main方法正确处理异步操作：

static void Main(string[] args)
{
    try
    {
        // 初始化服务的代码
        var workspaceService = new WorkspaceService(...);
        workspaceService.OpenSolutionAsync(solutionPath).GetAwaiter().GetResult();
    }
    catch (Exception ex)
    {
        Console.WriteLine($"崩溃原因：{ex.Message}\n详细堆栈：{ex.StackTrace}");
        Console.ReadLine(); // 防止程序直接退出，方便查看错误
    }
}

如果你的项目支持C# 7.1及以上，也可以把Main改成异步版本：

static async Task Main(string[] args)
{
    try
    {
        var workspaceService = new WorkspaceService(...);
        await workspaceService.OpenSolutionAsync(solutionPath);
    }
    catch (Exception ex)
    {
        Console.WriteLine($"崩溃原因：{ex.Message}\n详细堆栈：{ex.StackTrace}");
        Console.ReadLine();
    }
}

这一步大概率能帮你找到具体的崩溃原因——比如某个依赖缺失、权限不足或者参数错误。

2. 检查MSBuild环境依赖 #

Roslyn的Workspace依赖MSBuild来加载解决方案，虽然你复制了MSBuildService，但你的控制台应用可能没有正确找到MSBuild的安装路径。SolutionExplorer示例因为在VS环境下运行，会自动继承VS的MSBuild环境，而独立的控制台应用可能需要显式指定MSBuild路径：

你可以尝试在初始化MSBuildService时，手动指定MSBuild的安装目录（比如从VS的安装路径中获取，通常是C:\Program Files (x86)\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin，根据你的VS版本调整）。

3. 临时恢复原日志逻辑 #

你提到修改了日志行为，有可能是日志输出的异步操作引发了线程问题，导致进程崩溃。可以暂时把日志逻辑恢复成和SolutionExplorer示例完全一致，看看是否还会出现退出的情况，排除日志代码的影响。

4. 直接调试定位问题 #

既然已经知道崩溃发生在WorkspaceService第97行，建议你在该行前后添加详细的日志输出，或者用Visual Studio附加到控制台进程进行调试：

• 在第96行添加Console.WriteLine("准备执行第97行操作");
• 在第97行执行后添加Console.WriteLine("第97行操作执行完成");
  这样可以确定是该行代码执行时崩溃，还是后续的异步回调导致的问题。如果用调试的话，记得开启“捕获所有异常”（调试 -> Windows -> 异常设置），这样能看到所有抛出的异常，包括被内部代码吞掉的。

5. 检查权限与文件锁定 #

确认你的控制台应用有解决方案文件夹的读写权限，特别是如果解决方案路径在受保护的目录（比如C:\Program Files）下，可能需要以管理员身份运行程序。另外，检查解决方案中的文件是否被其他进程锁定（比如VS已经打开了该解决方案），这也可能导致加载失败。

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