Replace deprecated wmic with MSBuild parallelism properties

[Copilot]

wmic is deprecated and missing on newer Windows builds. The build scripts used it to detect processor cores for CL parallelism tuning via CL_MPCount.

Changes:

• Remove wmic cpu get NumberOfCores detection from src/coreclr/build-runtime.cmd and src/tests/build.cmd
• Remove CL_MPCount property from src/coreclr/Directory.Build.props
• Add MSBuild properties in root Directory.Build.props to control build parallelism:
  • UseMultiToolTask=true
  • EnforceProcessCountAcrossBuilds=true
  • EnableClServerMode=true

The MSBuild properties are set globally in the root Directory.Build.props file (in a separate PropertyGroup right after the Arcade SDK import) so they apply to all projects in the repository.

This follows Microsoft's recommended approach for C++ build parallelism on modern systems.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>wmic deprecated/missing on newer builds of windows</issue_title>
<issue_description>We should find an alternative

runtime/src/coreclr/build-runtime.cmd

Line 276 in ac764af

'wmic cpu get NumberOfCores /value ^| find "=" 2^>NUL'

https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmic</issue_description>

Comments on the Issue (you are @copilot in this section)

@jkotas This was introduced by https://github.com/dotnet/runtime/commit/ac172ef854429dd68b4aa30e8020827cbf2630cf .

Is this workaround for a buggy parallelism still needed?</comment_new>
<comment_new>@akoeplinger

runtime/src/tests/build.cmd

Line 277 in 8dbca2c

'wmic cpu get NumberOfCores /value ^| find "=" 2^>NUL'

is another instance</comment_new>
<comment_new>@akoeplinger
Judging from https://devblogs.microsoft.com/cppblog/cpp-build-throughput-investigation-and-tune-up/#3.-tune-build-options-for-better-parallelism. I think we can just use:

set UseMultiToolTask=true
set EnforceProcessCountAcrossBuilds=true
set EnableClServerMode=true

instead of setting NumberOfCores

this means we can also stop setting CL_MPCount in src/coreclr/Directory.Build.props which was being set to NumberOfCores</comment_new>

• Fixes wmic deprecated/missing on newer builds of windows #118223

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[akoeplinger]

I tested building clr.runtime and it's the same as before, i.e. all cores are used.

[Copilot]

Pull request overview

This PR replaces deprecated wmic usage with modern MSBuild environment variables for controlling C++ build parallelism on Windows. The change addresses issues on newer Windows builds where wmic is no longer available.

• Removes wmic cpu get NumberOfCores detection logic from both CoreCLR and test build scripts
• Implements Microsoft's recommended MSBuild parallelism settings via environment variables
• Cleans up the now-unused CL_MPCount property from CoreCLR build configuration

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/tests/build.cmd	Replaces wmic-based core detection with MSBuild parallelism environment variables
src/coreclr/build-runtime.cmd	Replaces wmic-based core detection with MSBuild parallelism environment variables
src/coreclr/Directory.Build.props	Removes obsolete CL_MPCount property that was derived from NumberOfCores

---

The changes look good overall. The implementation correctly follows Microsoft's recommended approach for C++ build parallelism. The removal of wmic usage is complete, and the new MSBuild environment variables (UseMultiToolTask, EnforceProcessCountAcrossBuilds, and EnableClServerMode) are set appropriately in both affected build scripts. All references to NumberOfCores, wmic, and CL_MPCount have been properly removed from the codebase.

[jkotas]

I tested building clr.runtime and it's the same as before, i.e. all cores are used.

The intent of CL_MPCount was to avoid oversubscribing the machine. I expect that you will see all cores used even without it being set, except the build is going to slower since there will be more processes running in parallel than the machine can handle.

The metric to measure is the build wallclock time. The build wallclock time is very noisy. I usually do these kind of experiments by running the build in a loop overnight and computing average time.

I tested building clr.runtime and it's the same as before,

build.cmd without -msbuild argument is going to use ninja. Do all these env. variables have effect when building using ninja?

[jkotas]

Could you please validate that building (with msbuild) is about as fast as before?

LGTM otherwise

[akoeplinger]

I've validated that the build times are basically the same on my 16 core devbox (old: 11m7s, new: 10m51s) when using -msbuild on a restored repo.