.NET 10: odd `<ItemGroup>` behavior if directory that has parenthesis

[jonathanpeppers]

Issue Description

We're trying to get on .NET 10 here:

• [main] Update dependencies from dotnet/sdk android#9395

We are currently blocked on this <ItemGroup> not working as expected:

https://github.com/dotnet/sdk/blob/e847db398b6ffcbaa94ea85dee7a84c6480d3da5/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.props#L82-L90

Which results in this value missing a %(RuntimePackLabels) item metadata, even though $(UseMonoRuntime) is true:

However, if I add a log message, such as:

<_Logging Include="UseMonoRuntime=$(UseMonoRuntime);_TargetFrameworkVersionWithoutV=$(_TargetFrameworkVersionWithoutV)" />

It prints values as expected:

Steps to Reproduce

I am unable to make a small repro, this example works fine:

<Project>
  <PropertyGroup>
    <_DotNetSdk>D:\dotnet-sdk-10.0.100-alpha.1.25056.1-win-x64\sdk\10.0.100-alpha.1.25056.1\</_DotNetSdk>
    <TargetFramework>net10.0</TargetFramework>
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v10.0</TargetFrameworkVersion>
    <_TargetFrameworkVersionWithoutV>$(TargetFrameworkVersion.TrimStart('vV'))</_TargetFrameworkVersionWithoutV>
  </PropertyGroup>
  <Import Project="$(_DotNetSdk)Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.props" />
  <Target Name="Print">
    <Message Text="%(FrameworkReference.Identity) RuntimePackLabels=%(FrameworkReference.RuntimePackLabels)" Importance="High" />
  </Target>
  <PropertyGroup>
    <UseMonoRuntime>true</UseMonoRuntime>
  </PropertyGroup>
</Project>

> & "D:\dotnet-sdk-10.0.100-alpha.1.25056.1-win-x64\dotnet.exe" build foo.targets -tl:off -bl -t:Print
  Microsoft.NETCore.App RuntimePackLabels=Mono

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.05

So, it must be related to a larger build with lots of item groups?

Best repro I have, is to build an Android project on the PR above...

Expected Behavior

After project evaluation, we should have an item like:

<FrameworkReference Include="Microsoft.NETCore.App" RuntimePackLabels="Mono" />

Actual Behavior

After project evaluation, we are missing %(RuntimePackLabels) for:

<FrameworkReference Include="Microsoft.NETCore.App" />

Analysis

Here is an example .binlog, if you search for FrameworkReference:

build.zip

I made these changes in this log:

    <!-- Allow opt-in to Mono runtime pack for .NET 6.0 or higher -->
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimePackLabels="Mono"
--                      Condition="'$(UseMonoRuntime)' == 'true' And ('$(_TargetFrameworkVersionWithoutV)' != '') And ('$(_TargetFrameworkVersionWithoutV)' >= '6.0')"
                         />
++<_Logging Include="UseMonoRuntime=$(UseMonoRuntime);_TargetFrameworkVersionWithoutV=$(_TargetFrameworkVersionWithoutV)" />

Versions & Configurations

We've seen this behavior with the following .NET SDKs:

• 10.0.100-alpha.1.25056.1
• 10.0.100-alpha.1.24573.1

On both Windows and macOS, local and CI.

[Forgind]

I'm not sure how to verify this from the binlog, but I suspect it's doing a string comparison with this condition:
('$(_TargetFrameworkVersionWithoutV)' >= '6.0')

And 10.0 < 6.0 because 1 < 6.

I'll try to reproduce this as described then see if I can figure out how to modify your code to use the version comparison function built into MSBuild and see if it starts working.

/cc: @akoeplinger as he mentioned this being a blocker for a PR that I want in 🙂

[Forgind]

Actually, since the first condition (including that it was > 3.0) was true, I think I was probably wrong.

[akoeplinger]

Yeah that's unrelated. In the binlog from @jonathanpeppers you can see that the condition was removed completely, yet it still didn't work so somehow Update is broken.

[rmarinho]

this is holding Android, and holding MAUI, do we have a workaround or something that Android can use to get builds flowing to other repos?

[jonathanpeppers]

@akoeplinger discovered something odd about the issue, if we move the project directory from:

• bin\TestDebug\temp\CheckSignApk(True,True)

To:

• bin\TestDebug\temp\CheckSignApkTrueTrue

Then this problem goes away.

Trying this out on CI, but we might still have other failures in integration tests that specifically use characters like ( and ).

[akoeplinger]

@Forgind I reduced it down to this sample project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <UseMonoRuntime>true</UseMonoRuntime>
  </PropertyGroup>

  <Target Name="Foo" BeforeTargets="Build">
    <Message Text="Labels: @(FrameworkReference->Metadata('RuntimePackLabels'))" Importance="High" />
  </Target>

</Project>

Run this with dotnet build -tl:off and it will print

Labels: Mono

Run it in a directory that has parenthesis and it will print:

Labels:

[Forgind]

I managed to get it to not need the mono runtime and gave the Item we're looking for a more pointed description.

Apparently it has nothing to do with Update or Metadata, either, as I was able to reproduce the same problem with just Include.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Itezfz Include="Program.cs" />
  </ItemGroup>

  <Target Name="Foo" BeforeTargets="Build">
    <Message Text="Labels: @(Itezfz)" Importance="High" />
  </Target>

</Project>

[Forgind]

It isn't even showing up in the binlog, nor is it throwing an exception:

[Forgind]

I found that the LazyItemEvaluator.IncludeOperation was being created and added to a list of operations to eventually evaluate properly. Inspecting it at that point, it looked right/similar to other operations. I then tried to find it when it actually evaluated the operations, and it was mysteriously missing (or my debugger failed to break on my conditional breakpoint when it showed up, at least). All this happened without any user-visible errors.

[Forgind]

Also, just one parenthesis suffices in the path.