Posting this after reading https://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx. Either this is clear as mud or I am just plain stupid.
I have always ran msbuild.exe on the command line with /m without any /p:BuildInParallel=true and it always spawned the expected number of msbuild nodes (12 on my desktop, 4 on my laptop) and built the solution projects what the respective degree of concurrency (12 or 4 at a time most of the time).
On the other hand, when I called the MSBuild task from my targets filed and passed it more than one project (or a solution file), I have always set the BuildInParallel property of the MSBuild task. Because this is how you build projects in parallel using the MSBuild task, right?
Note, that this is a property of the MSBuild task, not a build property (like Configuration) passed in MSBuild.Properties.
The article suggests that there is actually a build property under the same name - BuildInParallel and that it compliments the /m switch, which is complete news to me. I searched all the *.targets files under *c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild* and the only mentioning of it is in the following context:
- If the property value is nil - set it to
true - Pass its value to the
MSBuild.BuildInParallelproperty. - Hard coded pass
falsewhen building Silverlight projects. (We still have these and I can concur - they are always built sequentially :-()
My conclusion - the article is misleading with respect to passing BuildInParallel to msbuild.exe, because it is of no significance, unless we pass false there. Which is also not needed, just do not pass /m.
But there is always a chance I am missing something here, so my question - what do I loose when running msbuild.exe /m without /p:BuildInParallel=true ?
(I think I know the answer - absolutely nothing, but just in case)