C# VBCSCompiler.exe的许多实例

我最近刚刚下载并安装了Visual Studio Professional 2015（14.0.23107.0）。当我第一次打开我们的解决方案（28个项目）并执行Build->Rebuild解决方案时，我的开发机器完全陷入了爬行状态。CPU以100%的速度耗尽，构建从未完成-即使在>10分钟之后

我打开Windows任务管理器并注意到：>10个VBCSCompiler.exe任务正在运行。当这些任务组合在一起时，CPU的发送率>90%

知道为什么有这么多这样的任务在运行吗？有没有办法阻止这种事情发生

这是我能找到的最接近其他遇到相同问题的人的东西：

更新（8/7）

-汉斯·帕桑，伟大的思想。我的经理向我提供了此版本（14.0.23107.0）。这是“官方发布”的正确版本吗？？我没有故意安装任何Visual Studio 2015的每个发行版本。我不认为有任何测试版存在

-Kyle Trauberman，我不太熟悉VisualStudio环境中的环境变量；但是，我天真地在VS（和MSBuild）命令提示符窗口中运行了

set DisableRosyln=true

。这似乎没有任何影响。即使在重新启动VS2015后，VBCSCompiler.exe仍显示正确的备份

我修复了VS2015安装并重新启动。这没有帮助

更新第2部分（8/7） -汉斯·帕桑，写得很好！！虽然这一次问题没有发生，但我看了一下您描述的情况：

对于使用VBCSCompiler.exe加载的模块，我有以下内容：

有趣的是，我们的.NET核心程序集有不同的版本。你是4.06.79，而我是4.06.81

我的“客户端dll”（位于C:\Program Files（x86）\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll）的版本和时间戳与您的相同：

奇怪的是，当我查看ILSpy中的代码时，我看到了一些稍有不同的东西——也许是优化

    private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancellationToken, out string newPipeName)
{
    string str = pipeName;
    int num = 1;
    while (File.Exists(string.Format("\\\\.\\pipe\\{0}", pipeName)))
    {
        NamedPipeClientStream result;
        if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancellationToken)) != null)
        {
            newPipeName = pipeName;
            return result;
        }
        pipeName = str + "." + num.ToString(CultureInfo.InvariantCulture);
        num++;
    }
    newPipeName = pipeName;
    return null;
}

---

**让我回到传递给VBCSCompiler.exe实例的特定pipname参数。我将不得不等待，直到它再次发生。

根据Slaks，您可以通过将

DisableRoslyn

环境变量设置为

true

来禁用roslyn（这就是VBCSCompiler.exe的外观）

有关更多信息，请参阅

---

请注意，上面的链接是用于预览的，但我无法想象从那时到现在它会有多大变化。

嗯，没有明显的重做场景，也没有其他人对此抱怨。你的解决方案一点也不奇怪。将cpu固定在100%并让VBCSCompiler进程吞下~1.5 GB对于大型项目来说并不难，但当我看我的项目时，它是非常干净的

第一个可能的失败场景是，您有一些未安装的beta位，这是一个非常常见的问题。使用调试器查看。使用“调试>附加到进程”并选择一个正在运行的实例。然后调试>全部中断并调试>查看>模块。请注意版本号和时间戳，它们应该如下所示：

请注意，故意隐藏了一些列以保持可读性。时间戳是CST时区

---

那是服务器端。发现错误的客户端位于C:\Program Files（x86）\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll中。看看它的属性，我的是85192字节，创建于周日，‎六月‎21, ‎2015, ‏‎下午7:06:54，文件版本号1.0.0.50618。您可以使用反编译器（如Reflector或ILSpy）查看该文件，导航到BuildClient.TryAllProcesses（）。与bug修复相关的行是：

for (int i = 1; File.Exists(string.Format(@"\\.\pipe\{0}", pipeName)); i++)

错误版本丢失。

\.\pipe\

---

请注意，在上面的代码段中，错误检查非常不充分，File.Exists（）返回false的原因很多。这也是早期没有发现bug的基本原因。这会启用几种可能的故障模式，如果您的机器感染了程序员自愿安装的典型收缩包装恶意软件，则会启用这种模式。服务器和客户机代码通过具有特殊名称的命名管道相互连接。您可以在任务管理器的“流程”选项卡中看到。使用查看>选择列（Win8及以上版本：右键单击列标题）并勾选“命令行”选项：

请注意

-pipename

参数。如果File.Exists（）调用返回false，则MSBuild将再次启动VBCSCompiler.exe。如果您看到所有这些实例都使用相同的-pipename参数运行，那么您的计算机上运行的软件会干扰正常的命名管道使用。首先你要考虑的是寻找一个攻击性较小的反恶意软件解决方案。您可以编写一个使用System.IO.Pipes命名空间的小测试程序，以获得更好的异常消息

知道为什么有这么多这样的任务在运行吗

Roslyn使用一个共享的编译器进程，将编译后的代码保存在内存中，以便在后续编译中重用。因此，第二次编译会更快，但正如您所看到的，会有内存开销

有没有办法阻止这种事情发生

对。从中，msbuild中的compile任务的一个属性关闭了共享编译器，并由设置为true

因此，在每个项目中，都必须将此属性添加到项目文件中。或者，在Visual Studio 2015中，现在有了共享项目，您可以将此属性添加到共享项目中，然后将该共享项目包括在需要此设置的所有其他项目中

<PropertyGroup>
  <UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>

假的

截至2015年11月22日，Visual Studio 2015社区版中的这个问题仍在发生。我的笔记本电脑开始兼作空间加热器，所有VBCSCompiler实例都在全速运行

唯一能解决这个问题的办法