Sdk: MSBUILD : error MSB1006: Property is not valid. Switch: /m:1

[stephentoub]

Using a .NET 6 SDK I installed this morning (6.0.100-alpha.1.20574.4):

dotnet new console
dotnet restore /p:DebugType=portable /p:UseSharedCompilation=false /p:BuildInParallel=false /m:1 /p:Deterministic=true /p:Optimize=true

results in:

MSBUILD : error MSB1006: Property is not valid.
Switch: /m:1

For switch syntax, type "MSBuild -help"

If the /m:1 is moved to the beginning of the options:

dotnet new console
dotnet restore /m:1 /p:DebugType=portable /p:UseSharedCompilation=false /p:BuildInParallel=false /p:Deterministic=true /p:Optimize=true

then it succeeds.

This is breaking benchmark.net.

cc: @adamsitnik

[adamsitnik]

@sfoslund can it be related to https://github.com/dotnet/sdk/pull/14379 ?

[sfoslund]

can it be related to #14379 ?

That's definitely possible, I'm looking into this now.

[sfoslund]

This is another instance of https://github.com/dotnet/command-line-api/issues/1077, which I have a PR out on system.commandline to fix. The /m:1 token is being treated as another argument to the property option, which is incorrect.

[billwert]

@sfoslund looks like the system.commandline PR has been pending for a long time. Is there a workaround you could apply to the SDK repo? Fixing Benchmark.NET to work around this is fairly involved. This is also blocking the perf lab.

[sfoslund]

Is there a workaround you could apply to the SDK repo?

I've been pushing to get the System.commandline PR in today, so hopefully a work around won't be needed. Are you unable to reorder the arguments for now? If that PR continues to be blocked I can look at adding a work around but I don't think there will be a simple way to do it on our end.

[billwert]

Are you unable to reorder the arguments for now?

I don't think we have an easy way to do that. The challenge is that Benchmark.NET autogenerates projects which it then compiles, and that generated command line is the thing that is failing. To fix it we'd need to make a fix in BDN, get it through their PR process, then pull that PR into the perf lab. @adamsitnik there's not another easier way around it is there?

[sfoslund]

The system.commandline change was merged and I have a PR out to fix this behavior: https://github.com/dotnet/sdk/pull/14701

[adamsitnik]

there's not another easier way around it is there?

@billwert There is no easier way. The value comes from a local const: https://github.com/dotnet/BenchmarkDotNet/blob/10abc4f4daa5142f0257c9d512a38afc2ab28be1/src/BenchmarkDotNet/Toolchains/DotNetCli/DotNetCliCommand.cs#L189

so we can't add any hack using reflection to mutate it ;(

BTW the value is set on purpose to ensure that MSBuild does not create any long-living processes that could outlive BDN work (and create issues like file in use etc).

I've tried to find a clean workaround that would allows us to achieve the same effect and used the long name version of the MSBuild argument (/maxCpuCount:1), but it also fails (I was hoping it's a matter of single char):

C:\Users\adsitnik\Downloads\dotnet-sdk-6.0.100-alpha.1.20574.5-win-x64> .\dotnet.exe restore /p:DebugType=portable /p:UseSharedCompilation=false /p:BuildInParallel=false /maxCpuCount:1 /p:Deterministic=true /p:Optimize=true
MSBUILD : error MSB1006: Property is not valid.
Switch: /maxCpuCount:1

For switch syntax, type "MSBuild -help"

Then I've tried to find a corresponding MSBuild Property (not an Argument) and I found it but it's Reserved and can not be set via /p:MSBuildNodeCount=1 and env var:

Reserved properties cannot be overridden, but well-known properties can be overridden by using identically named environment properties, global properties, or properties that are declared in the project file.

What is suprising is that when I pass the Reserved property via dotnet restore /p:MSBuildNodeCount=1, the dotnet cli gives me not output and most probably silently fails ;)

[billwert]

@sfoslund I'm still seeing this error in version 6.0.100-alpha.1.20574.5 from dotnet/installer. Here is a helix log from this afternoon. Presumably this fix should have flowed into installer by now?

[sfoslund]

Actually it looks like we haven't had a SDK-> installer insertion since Tuesday. This PR should fix that, I'll try to get it unstuck: https://github.com/dotnet/installer/pull/9172