VBCSCompiler.exe 的多次实例
Numerous instances of VBCSCompiler.exe
我最近刚刚下载并安装了 Visual Studio Professional 2015 (14.0.23107.0)。我第一次打开我们的解决方案（28 个项目）并执行 Build -> Rebuild Solution 时，我的开发机器完全崩溃了。 CPU 已达到 100% 的最大值，并且构建从未完成 - 即使在超过 10 分钟后也是如此。
我打开 Windows 任务管理器并注意到：> 10 VBCSCompiler.exe 个任务 运行。合并后，这些任务发送了 CPU > 90%。
知道为什么有这么多任务 运行 吗？有什么办法可以阻止这种情况发生吗？
这是我能找到的与遇到同样问题的其他人最接近的事情：https://github.com/dotnet/roslyn/issues/2790
更新 (8/7)
-Hans Passant，伟大的思想。我的经理向我提供了此版本 (14.0.23107.0)。这是 "official release" 的正确版本吗？我没有故意安装任何 Visual Studio 2015 的每个发行版本。我认为周围没有任何测试版。
-Kyle Trauberman，我对 Visual Studio 上下文中的环境变量不太熟悉；但是，我在 VS（和 MSBuild）命令提示符 Window 中天真地 运行 set DisableRosyln=true。这似乎没有任何影响。 VBCSCompiler.exe 即使在重新启动 VS2015 后也显示正确的备份。
我修复了 VS2015 安装并重新启动。这没有帮助。
更新第 2 部分 (8/7)
-Hans Passant，写得令人印象深刻！！虽然这次没有出现问题，但是我看了你描述的内容：
就用 VBCSCompiler.exe 加载的模块而言，这是我拥有的：
有趣的是，我们的 .NET 核心程序集有不同的版本。你在 4.06.79 而我在 4.06.81.
我的 "client side dlls"（位于 C:\Program Files (x86)\MSBuild.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 看起来是什么）
有关详细信息，请参阅 http://blog.slaks.net/2014-05-21/exploring-roslyn-part-2-inside-end-user-preview/。
请注意，上面的 link 是预览图，但我无法想象从那时到现在它会有多大变化。
嗯，没有明显的重现情况，也没有其他人抱怨这个。您的解决方案一点也不奇怪。将 cpu 固定到 100% 并让 VBCSCompiler 进程吞下 ~1.5 GB 在大型项目上并不是很难，但当我看我的项目时它非常干净。
第一个可能的故障场景是您周围有一些未安装的测试版位，这是一个非常常见的问题。使用调试器有一个look-see。使用 Debug > Attach to Process 并选择 运行 个实例之一。然后 Debug > Break All 和 Debug > View > Modules。注意版本号和时间戳，它们应该是这样的：
请注意，有意隐藏了一些列以保持其可读性。时间戳是 CST 时区。
那是服务器端。存在您发现的错误的客户端位于 C:\Program Files (x86)\MSBuild.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll。看看它的属性，我的是 85,192 字节，创建于 2015 年 6 月 21 日星期日，下午 7:06:54，文件版本号 1.0.0.50618。您可以使用 Reflector 或 ILSpy 等反编译器查看该文件，导航至 BuildClient.TryAllProcesses()。错误修复的相关行是：
for (int i = 1; File.Exists(string.Format(@"\.\pipe\{0}", pipeName)); i++)
缺少有问题的版本 \.\pipe\。
请注意，由于多种原因，File.Exists() returns false 上面的代码片段中的错误检查非常不充分。这也是该错误未及早发现的基本原因。这会启用几种可能的故障模式，如果您的机器被程序员自愿安装的典型 shrinked-wrapped 恶意软件感染，就会启用这种模式。服务器和客户端代码通过具有特殊名称的命名管道相互连接。您可以在任务管理器的“进程”选项卡中看到的内容。使用 View > Select Columns (Win8 and up: right-click a column header) 并勾选 "Command line" 选项：
注意 -pipename 参数。如果 File.Exists() 调用 returns false，则 MSBuild 将再次启动 VBCSCompiler.exe。如果您看到所有这些实例 运行 相同的 -pipename 参数，那么您的计算机上的软件 运行 正在干扰正常的命名管道使用。那么您首先要考虑的是寻找一个不太激进的 anti-malware 解决方案。您可以编写一个使用 System.IO.Pipes 命名空间的小测试程序来获得更好的异常消息。
Any idea why there are so many of these tasks running?
Roslyn 使用共享编译器进程，将编译后的代码保存在内存中，以便在后续编译中重用。所以第二次编译会更快，但正如您所见，存在内存开销。
Any way to stop this from happening?
是的。来自 here there's a property of the compile task in msbuild that turns off the shared compiler, and it's set to true by default.
因此，在每个项目中，您都必须将此 属性 添加到项目文件中。或者在 Visual Studio 2015 中现在有共享项目，您可以在其中将此 属性 添加到共享项目，然后将该共享项目包含在需要此设置的所有其他项目中。
<PropertyGroup>
<UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>
截至 2015 年 11 月 22 日，我在 Visual Studio 2015 社区版中仍然遇到此问题。我的笔记本电脑开始兼作 space 加热器，所有 VBCSCompiler 运行 实例全开。
唯一对我有用的修复方法是在 Web 应用程序的 /bin/roslyn 目录中找到文件 VBCSCompiler.exe，然后 更改安全权限 .
您需要拒绝 读取和执行您的网络应用 运行 所在的 AppPool 的权限。
您还可以更改 VBCSCompiler 的 "keep alive" 选项，以便在执行后立即关闭它...
您需要修改 "VBCSCompiler.exe.config" 文件 ("C:\Program Files (x86)\MSBuild.0\Bin\VBCSCompiler.exe.config") 并以秒为单位设置所需的值（默认为 600）。
Visual Studio Enterprise 2015 Update 1 也遇到了这个问题。
该问题已通过升级到更新 2 解决。
我发现在应用程序池高级设置中将身份更改为 'NetworkService' 解决了我的问题。
我最近刚刚下载并安装了 Visual Studio Professional 2015 (14.0.23107.0)。我第一次打开我们的解决方案（28 个项目）并执行 Build -> Rebuild Solution 时，我的开发机器完全崩溃了。 CPU 已达到 100% 的最大值，并且构建从未完成 - 即使在超过 10 分钟后也是如此。
我打开 Windows 任务管理器并注意到：> 10 VBCSCompiler.exe 个任务 运行。合并后，这些任务发送了 CPU > 90%。
知道为什么有这么多任务 运行 吗？有什么办法可以阻止这种情况发生吗？
这是我能找到的与遇到同样问题的其他人最接近的事情：https://github.com/dotnet/roslyn/issues/2790
更新 (8/7)
-Hans Passant，伟大的思想。我的经理向我提供了此版本 (14.0.23107.0)。这是 "official release" 的正确版本吗？我没有故意安装任何 Visual Studio 2015 的每个发行版本。我认为周围没有任何测试版。
-Kyle Trauberman，我对 Visual Studio 上下文中的环境变量不太熟悉；但是，我在 VS（和 MSBuild）命令提示符 Window 中天真地 运行 set DisableRosyln=true。这似乎没有任何影响。 VBCSCompiler.exe 即使在重新启动 VS2015 后也显示正确的备份。
我修复了 VS2015 安装并重新启动。这没有帮助。
更新第 2 部分 (8/7) -Hans Passant，写得令人印象深刻！！虽然这次没有出现问题，但是我看了你描述的内容：
就用 VBCSCompiler.exe 加载的模块而言，这是我拥有的：
有趣的是，我们的 .NET 核心程序集有不同的版本。你在 4.06.79 而我在 4.06.81.
我的 "client side dlls"（位于 C:\Program Files (x86)\MSBuild.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.
有关详细信息，请参阅 http://blog.slaks.net/2014-05-21/exploring-roslyn-part-2-inside-end-user-preview/。
请注意，上面的 link 是预览图，但我无法想象从那时到现在它会有多大变化。
嗯，没有明显的重现情况，也没有其他人抱怨这个。您的解决方案一点也不奇怪。将 cpu 固定到 100% 并让 VBCSCompiler 进程吞下 ~1.5 GB 在大型项目上并不是很难，但当我看我的项目时它非常干净。
第一个可能的故障场景是您周围有一些未安装的测试版位，这是一个非常常见的问题。使用调试器有一个look-see。使用 Debug > Attach to Process 并选择 运行 个实例之一。然后 Debug > Break All 和 Debug > View > Modules。注意版本号和时间戳，它们应该是这样的：
请注意，有意隐藏了一些列以保持其可读性。时间戳是 CST 时区。
那是服务器端。存在您发现的错误的客户端位于 C:\Program Files (x86)\MSBuild.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll。看看它的属性，我的是 85,192 字节，创建于 2015 年 6 月 21 日星期日，下午 7:06:54，文件版本号 1.0.0.50618。您可以使用 Reflector 或 ILSpy 等反编译器查看该文件，导航至 BuildClient.TryAllProcesses()。错误修复的相关行是：
for (int i = 1; File.Exists(string.Format(@"\.\pipe\{0}", pipeName)); i++)
缺少有问题的版本 \.\pipe\。
请注意，由于多种原因，File.Exists() returns false 上面的代码片段中的错误检查非常不充分。这也是该错误未及早发现的基本原因。这会启用几种可能的故障模式，如果您的机器被程序员自愿安装的典型 shrinked-wrapped 恶意软件感染，就会启用这种模式。服务器和客户端代码通过具有特殊名称的命名管道相互连接。您可以在任务管理器的“进程”选项卡中看到的内容。使用 View > Select Columns (Win8 and up: right-click a column header) 并勾选 "Command line" 选项：
注意 -pipename 参数。如果 File.Exists() 调用 returns false，则 MSBuild 将再次启动 VBCSCompiler.exe。如果您看到所有这些实例 运行 相同的 -pipename 参数，那么您的计算机上的软件 运行 正在干扰正常的命名管道使用。那么您首先要考虑的是寻找一个不太激进的 anti-malware 解决方案。您可以编写一个使用 System.IO.Pipes 命名空间的小测试程序来获得更好的异常消息。
Any idea why there are so many of these tasks running?
Roslyn 使用共享编译器进程，将编译后的代码保存在内存中，以便在后续编译中重用。所以第二次编译会更快，但正如您所见，存在内存开销。
Any way to stop this from happening?
是的。来自 here there's a property of the compile task in msbuild that turns off the shared compiler, and it's set to true by default.
因此，在每个项目中，您都必须将此 属性 添加到项目文件中。或者在 Visual Studio 2015 中现在有共享项目，您可以在其中将此 属性 添加到共享项目，然后将该共享项目包含在需要此设置的所有其他项目中。
<PropertyGroup>
<UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>
截至 2015 年 11 月 22 日，我在 Visual Studio 2015 社区版中仍然遇到此问题。我的笔记本电脑开始兼作 space 加热器，所有 VBCSCompiler 运行 实例全开。
唯一对我有用的修复方法是在 Web 应用程序的 /bin/roslyn 目录中找到文件 VBCSCompiler.exe，然后 更改安全权限 .
您需要拒绝 读取和执行您的网络应用 运行 所在的 AppPool 的权限。
您还可以更改 VBCSCompiler 的 "keep alive" 选项，以便在执行后立即关闭它... 您需要修改 "VBCSCompiler.exe.config" 文件 ("C:\Program Files (x86)\MSBuild.0\Bin\VBCSCompiler.exe.config") 并以秒为单位设置所需的值（默认为 600）。
Visual Studio Enterprise 2015 Update 1 也遇到了这个问题。 该问题已通过升级到更新 2 解决。
我发现在应用程序池高级设置中将身份更改为 'NetworkService' 解决了我的问题。