-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET 10: odd <ItemGroup>
behavior
#11237
Comments
I'm not sure how to verify this from the binlog, but I suspect it's doing a string comparison with this condition: 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 🙂 |
Actually, since the first condition (including that it was > 3.0) was true, I think I was probably wrong. |
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 |
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? |
@akoeplinger discovered something odd about the issue, if we move the project directory from:
To:
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 |
@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
Run it in a directory that has parenthesis and it will print:
|
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> |
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. |
Also, just one parenthesis suffices in the path. |
Issue Description
We're trying to get on .NET 10 here:
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)
istrue
:However, if I add a log message, such as:
It prints values as expected:
Steps to Reproduce
I am unable to make a small repro, this example works fine:
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:
Actual Behavior
After project evaluation, we are missing
%(RuntimePackLabels)
for:Analysis
Here is an example
.binlog
, if you search forFrameworkReference
:build.zip
I made these changes in this log:
Versions & Configurations
We've seen this behavior with the following .NET SDKs:
On both Windows and macOS, local and CI.
The text was updated successfully, but these errors were encountered: