msbuild构建步骤_使用并行构建和多核CPU的MSBuild进行更快的构建

msbuild构建步骤

UPDATE: I've written an UPDATE on how to get MSBuild building using multiple cores from within Visual Studio. You might check that out when you're done here.

更新：我已经编写了有关如何从Visual Studio中使用多个内核来构建MSBuild的更新。 完成后，您可以检查一下。

Jeff asked the question "Should All Developers Have Manycore CPUs?" this week. There are number of things in his post I disagree with.

Jeff本周问了一个问题：“所有开发人员都应该拥有Manycore CPU吗？ ”。 我不同意他职务中的许多内容。

First, "dual-core CPUs protect you from badly written software" is just a specious statement as it's the OS's job to protect you, it shouldn't matter how many cores there are.

首先，“双核CPU保护您免受编写错误的软件的侵扰”只是一个似是而非的陈述，因为保护您的操作系统是操作系统的工作，无论有多少个内核都无关紧要。

Second, "In my opinion, quad-core CPUs are still a waste of electricity unless you're putting them in a server" is also silly. Considering that modern CPUs slow down when not being used, and use minimal electricity when compared to your desk lamp and monitors, I can't see not buying the best (and most) processors) that I can afford. The same goes with memory. Buy as much as you can comfortably afford. No one ever regretted having more memory, a faster CPU and a large hard drive.

其次，“我认为，除非将四核CPU放入服务器中，否则仍然会浪费电力” 也很傻。 考虑到现代CPU在不使用时会变慢，并且与台灯和显示器相比耗电最少，因此我看不到没有买得起的最好的(也是大多数)处理器。 内存也一样。 尽可能多地买得起。 没有人会后悔拥有更多的内存，更快的CPU和更大的硬盘驱动器。

Third he says,"there are only a handful of applications that can truly benefit from more than 2 CPU cores" but of course, if you're running a handful of applications, you can benefit even if they are not multi-threaded. Just yesterday I was rendering a DVD, watching Arrested Development, compiling an application, reading email while my system was being backed up by Home Server. This isn't an unreasonable amount of multitasking, IMHO, and this is why I have a quad-proc machine.

第三，他说：“只有少数几个应用程序才能真正受益于2个以上的CPU内核”，但是，当然，如果您运行的是少数几个应用程序，即使它们不是多线程的，您也可以从中受益。 就在昨天，当我的系统由Home Server备份时，我正在渲染DVD，观看Arrested Development ，编译应用程序，阅读电子邮件。 恕我直言，这不是不合理的多任务处理量，这就是为什么我有一台四进程机器的原因。

That said, the limits to which a machine can multi-task are often limited to the bottleneck that sits between the chair and keyboard. Jeff, of course, must realize this, so I'm just taking issue with his phrasing more than anything.

也就是说，一台机器可以执行多任务的限制通常仅限于椅子和键盘之间的瓶颈。 Jeff当然必须意识到这一点，所以我对他的措辞的质疑比什么都重要。

He does add the disclaimer, which is totally valid: "All I wanted to do here is encourage people to make an informed decision in selecting a CPU" and that can't be a bad thing.

他确实添加了免责声明，它是完全有效的： “我在这里要做的就是鼓励人们在选择CPU时做出明智的决定” ，这不是一件坏事。

MSBuild (MSBuild)

Now, enough picking on Jeff, let's talk about my reality as a .NET Developer and a concrete reason I care about multi-core CPUs. Jeff compiled SharpDevelop using 2 cores and said "I see nothing here that indicates any kind of possible managed code compilation time performance improvement from moving to more than 2 cores."

现在，有足够的关于Jeff的信息，让我们谈谈我作为.NET Developer的现实，以及我关心多核CPU的具体原因。 Jeff使用2个内核编译了SharpDevelop，并说：“我看不到任何迹象表明从迁移到2个以上内核，任何可能的托管代码编译时间性能都会得到改善。”

When I compiled SharpDevelop via "MSBuild SharpDevelop.sln" (which uses one core) it took 11 seconds:

当我通过“ MSBuild SharpDevelop.sln”(使用一个内核)编译SharpDevelop时，花了11秒：

TotalMilliseconds : 11207.7979

毫秒：11207.7979

Adding the /m:2 parameter to MSBuild yielded a 35% speed up:

将/ m：2参数添加到MSBuild可使速度提高35％：

TotalMilliseconds : 7190.3041

总毫秒数：7190.3041

And adding /m:4 yielded (from 1 core) a a 59% speed up:

加上/ m：4可从1个内核中获得59％的加速：

TotalMilliseconds : 4581.4157

总毫秒数：4581.4157

Certainly when doing a command line build, why WOULDN'T I want to use all my CPUs? I can detect how many there are using an Environment Variable that is set automatically:

当然，在执行命令行构建时，为什么我不想使用所有CPU？ 我可以使用自动设置的环境变量来检测有多少：

C:>echo %NUMBER_OF_PROCESSORS%
4

C：>回声％NUMBER_OF_PROCESSORS％ 4

But if I just say /m to MSBuild like

但是，如果我只是对MSBuild说/ m

MSBuild /m

MSBuild /米

It will automatically use all the cores on the system to create that many MSBuild processes in a pool as seen in this Task Manager screenshot:

它将自动使用系统上的所有核心在一个池中创建许多MSBuild进程，如以下任务管理器屏幕截图所示：

The MSBuild team calls these "nodes" because they are cooperating and act as a pool, building projects as fast as they can to the point of being I/O bound. You'll notice that their PIDs (Process IDs) won't change while they are living in memory. This means they are recycled, saving startup time over running MSBuild over and over (which you wouldn't want to do, but I've seen in the wild.)

MSBuild团队将这些节点称为“节点”，是因为它们相互协作并充当池，从而以最快的速度构建项目，直至受I / O约束。 您会注意到，当它们驻留在内存中时，它们的PID(进程ID)不会改变。 这意味着它们被回收了，从而一遍又一遍地运行MSBuild节省了启动时间(您不想这样做，但是我在野外见过。)

You might wonder, why do we not just use one multithreaded process for MSBuild? Because each building project wants its own current directory (and potentially custom tasks expect this) and each PROCESS can only have one current directory, no matter how many threads exist.

您可能想知道，为什么我们不只对MSBuild使用一个多线程进程？ 因为每个建筑项目都需要自己的当前目录(并且可能需要自定义任务)，并且每个PROCESS只能有一个当前目录，而不管存在多少线程。

When you run MSBuild on a SLN (Solution File) (which is NOT an MSBuild file) then MSBuild will create a "sln.cache" file that IS an MSBuild file.

当您在SLN(解决方案文件)(不是MSBuild文件)上运行MSBuild时， MSBuild将创建一个为MSBuild文件的“ sln.cache”文件。

Some folks like to custom craft their MSBuild files and others like to get the auto-generate one. Regardless, when you're calling an MSBuild task, one of the options that gets set is (from an auto-generated file):

一些人喜欢自定义其MSBuild文件，而另一些人喜欢获得自动生成的文件。 无论如何，当您调用MSBuild任务时，设置的选项之一是(来自自动生成的文件)：

<MSBuild Condition="@(BuildLevel1) != ''" Projects="@(BuildLevel1)" Properties="Configuration=%(Configuration); Platform=%(Platform); ...snip... BuildInParallel="true" UnloadProjectsOnCompletion="$(UnloadProjectsOnCompletion)" UseResultsCache="$(UseResultsCache)"> ...

<MSBuild Condition =“ @(BuildLevel1)！=''”项目=“ @(BuildLevel1)” Properties =“ Configuration =％(Configuration); Platform =％(Platform); ... snip ... BuildInParallel =” true “ UnloadProjectsOnCompletion =” $(UnloadProjectsOnCompletion)“ UseResultsCache =” $(UseResultsCache)“> ...

When you indicate BuildInParallel you're asking for parallelism in building your Projects. It doesn't cause Task-level parallelism as that would require a task dependency tree and you could get some tricky problems as copies, etc, happened simultaneously.

当您指定BuildInParallel时，您是在构建项目时要求并行性。 它不会导致任务级并行性，因为这将需要任务依赖关系树，并且由于副本等同时发生，您可能会遇到一些棘手的问题。

However, Projects DO often have dependency on each other and the SLN file captures that. If you're using a Visual Studio Solution and you've used Project References, you've already given the system enough information to know which projects to build first, and which to wait on.

但是，Projects经常彼此依赖，而SLN文件会捕获它们。 如果您使用的是Visual Studio解决方案，并且已经使用过“项目引用”，那么您已经为系统提供了足够的信息，可以知道首先要构建哪些项目以及要等待哪些项目。

更高的粒度(如果需要) (More Granularity (if needed))

If you are custom-crafting your MSBuild files, you could turn off parallelism on just certain MSBuild tasks by adding:

如果您要定制MSBuild文件，则可以通过添加以下命令来关闭某些MSBuild任务的并行性：

BuildInParallel=$(BuildInParallel)

BuildInParallel = $(BuildInParallel)

to specific MSBuild Tasks and then just those sub-projects wouldn't build in parallel if you passed in a property from the command line:

到特定的MSBuild任务，如果从命令行传递属性，则仅那些子项目不会并行构建：

MSBuild /m:4 /p:BuildInParallel=false

MSBuild / m：4 / p：BuildInParallel = false

But this an edge case as far as I'm concerned.

但是就我而言，这是一个边缘案例。

BuildInParallel与MSBuild / m开关有何关系？ (How does BuildInParallel relate to the MSBuild /m Switch?)

Certainly, if you've got a lot of projects that are mostly independent of each other, you'll get more speed up than if your solution's dependency graph is just a queue of one project depending on another all the way down the line.

当然，如果您有很多彼此独立的项目，那么与解决方案的依赖关系图只是一个项目的队列(取决于整个项目中的另一个项目)相比，您将获得更快的速度。

In conclusion, BuildInParallel allows the MSBuild task to process the list of projects which were passed to it in a parallel fashion, while /m tells MSBuild how many processes it is allowed to start.

总之， BuildInParallel允许MSBuild任务以并行方式处理传递给它的项目列表，而/ m告诉MSBuild允许启动多少个进程。

If you have multiple cores, you should be using this feature on big builds from the command line and on your build servers.

如果您有多个内核，则应该在命令行的大型构建以及构建服务器上使用此功能。

Thanks to Chris Mann and Dan Mosley for their help and corrections.

感谢克里斯·曼(Chris Mann)和丹·莫斯利(Dan Mosley)的帮助和纠正。

Related Links

相关链接

• MSBuild Blog - The MSBuild team's blog.

  MSBuild博客-MSBuild团队的博客。

• MSBuild Sidekick v2 - A visual editor, ala NantPad, for MSBuild files.

  MSBuild Sidekick v2-可视编辑器ala NantPad，用于MSBuild文件。

• MSBuild Visualizer - An old project of Mitch Denny's trying to make large MSBuild files easier to visualize.

  MSBuild Visualizer - Mitch Denny的一个旧项目，试图使大型MSBuild文件更易于可视化。

• How to get MSBuild building using multiple cores from within Visual Studio

  如何在Visual Studio中使用多个内核进行MSBuild构建

MSBuild, MSBuild ， C#, C＃ ， VB VB

翻译自: https://www.hanselman.com/blog/faster-builds-with-msbuild-using-parallel-builds-and-multicore-cpus

msbuild构建步骤