MSBUILD(VS2010)在某些计算机上非常慢 [英] MSBUILD (VS2010) very slow on some machines

问题描述

我有一个很奇怪的人.

我的开发部门中大约有十二台PC，它们都遇到相同的问题: 使用msbuild4.0(VS2010)构建命令行比预期的要慢.比预期的慢4到5倍.

I have about a dozen PC's in our development department that all suffer the same issue: commandline builds using msbuild4.0 (VS2010) are way slower than should be. 4x to 5x slower as expected.

所有计算机均为HP z400工作站(四核Xeon +超线程，2.4 GHz，6GB RAM) 在Win7 X64上也可以运行Windows 7 Pro 64bit或HP Elitebook笔记本(Core-i7 4GB RAM). 如果我选择其中一个已在香草工厂中预装Win7的计算机，请安装VS2010并进行构建，它们的速度与预期的一样快.如果将它们与我们公司的标准软件映像一起安装，则在同一个VS项目中，它们的速度会慢4到5倍.

All machines are HP z400 Workstations (quad-core Xeon+hyperthreading, 2.4 GHz, 6GB RAM) running Windows 7 Pro 64bit, or HP Elitebook notebooks (Core-i7 4GB RAM) also on Win7 X64. If I take one of those with the vanilla factory pre-installed Win7, install VS2010 and do a build they are as fast as expected. If I install them with our company standard software image, they became 4x to 5x slower on the same VS project.

Lenovo笔记本电脑(Core-i5)或台式机(Core-i7)上的同一公司软件映像显示，该公司映像与出厂预装的Win7之间没有可测量的差异. 甚至更奇怪:如果我在有问题的HP系统上安装带有Win7映像的VirtualBox，则虚拟机不会有问题.

The same company software image on Lenovo laptops (Core-i5) or desktops (Core-i7) shows no measurable difference between the company image and the factory pre-installed Win7. It's even stranger: If I install VirtualBox with a Win7 image on a HP system with the problem the virtual machine DOESN'T have the problem.

我尝试过的每个基准测试工具都显示公司映像和预装的Win7之间没有可测量的差异.仅msbuild受影响，并且仅在公司映像上运行Win7的HP机器上.

Every benchmark tool I have tried shows no measurable difference between the company image and the pre-installed Win7. Only msbuild is affected and only on the HP machines running Win7 on the company image.

在您询问之前:我已禁用公司映像中的所有软件/后台进程，但这没有任何区别.显然，不是在后台运行的某种方式与msbuild进行交互.我最好的猜测是，在HP硬件上，某些设置被更改，从而影响了msbuild.在其他硬件上不会发生这种情况. (而且VS2010 GUI根本不使用/不执行.我知道，如果两个都尝试顶部访问相同的解决方案/文件，这可以与msbuild进行交互.防病毒也没有任何区别.)

Before you ask: I have disabled all software/background processes in the company image, but that doesn't make any difference. It's obviously not something running in the background that somehow interacts with msbuild. My best guess is that on the HP hardware some settings gets changed that affects msbuild. This doesn't happen on other hardware. (And the VS2010 GUI is not used/executed at all. I am aware this can interact with the msbuild if both try top access the same solution/files. Antivirus doesn't make any difference either.)

任何人都不知道有什么可能影响msbuild变慢吗? 无论有多牵强，任何建议都是值得欢迎的.

Anybody have any idea what could possible influence msbuild to slow down? Any suggestion, no matter how far-fetched, is welcome.

推荐答案

我自己回答了这个问题，因为我发现了问题. 有问题的计算机都安装了"Entrust Entelligent Security Provider"软件. (我们公司使用证书管理器来处理加密的邮件.)

Answering this myself as I have found the problem. The computers in question all have the "Entrust Entelligent Security Provider" software installed. (A certificate manager our company uses for encrypted mail handling.)

.NET4(其中编写了VS2010)和.NET4代码的编译需要大量的证书检查，并且该软件(在过程中被称为)显然在多核PC上存在问题.核心越多，事情变得越慢.

.NET4 (in which VS2010 is written) and the compilation of .NET4 code require a large amount of certificate checks and this software (which get's called in the process) apparently has issues on multi-core PC's. The more cores how slower things become.

core-i5系统也有问题，但不是很严重.它们仍然可用. i7和Xeon系统(8核)的速度变慢，几乎无法使用.

The core-i5 systems have the problem as well, but not that badly. They are still usable. The i7 and Xeon system (8 cores) slow down to the point of becoming nearly unusable.

不幸的是，我无法摆脱这个Entrust软件.它是公司强制性软件套件的一部分. 我只是希望供应商对此有解决方案.

Unfortunately I can't get rid of this Entrust software. It's part of the company mandated software suite. I just hope the supplier has a solution for this.

使用Entrust Entelligence的版本10解决了问题.默认情况下，它不再将自己设置为系统中的第一个证书处理程序.
在v9上，需要手动编辑注册表才能将MS处理程序重新设置为默认位置.
那才是真正的问题:每次证书检查首先都要通过Entrust DLL，该DLL将所有内容推送到仅由单线程/CPU清空的队列中.然后，它发现不应该处理此证书，并将其交给Microsoft处理程序.

Problem is solved with version 10 of Entrust Entelligence. It does not set itself by default as first certificate handler in the system anymore.
On v9 a manual edit of the registry is required to put the MS handler back in default position.
That was the real problem: Every certificate check went first through the Entrust DLL which pushed everything in a queue which got emptied by only a single-thread/CPU. Then it discovered it wasn't supposed to deal with this certificate and handed it of to the Microsoft handler.

这篇关于MSBUILD(VS2010)在某些计算机上非常慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！