AddBindingsToCompile is sometimes not run, breaking _GenerateCompileDependencyCache and incremental builds

[Youssef1313]

Android application type

.NET Android (net7.0-android, net8.0-android, etc.)

Affected platform version

MSBuild 17.7

Description

msbuild.zip

In the above binlog, see the build for Uno.UI.BindingHelper.Android.netcoremobile.csproj (ID 1387).

Here, some generated files (e.g, Java.Interop.__TypeRegistrations) aren't included in the hash.

And, for some reason, ResolveReferences is run, but GenerateBindings and AddBindingsToCompile are not.

Steps to Reproduce

Did you find any workaround?

No response

Relevant log output

No response

[Youssef1313]

@dellis1972 Do you think this is related to #8706 ? The version I'm running on doesn't seem to have this fix.

[dellis1972]

Probably, the issue is probably that the .cs files in the generated folder are missing, so they never get included.

[Youssef1313]

@dellis1972 Assuming that PR fixes it, could it be backported?

and which .NET 8 SDK contains the fix (if released already)?

[dellis1972]

Looks like its been back ported to 8.0.2 via 20d9605. Note sure the release date for 8.0.2 though.

[Youssef1313]

Regarding backporting, I meant to 7.x, if possible

[dellis1972]

I don't think we can, according to https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core. 7 is going out of support in a month.

[jpobst]

Seems like this is fixed in supported versions (.NET 8+).

[Youssef1313]

@jpobst It's still an issue for me. What I found so far is that AddBindingsToCompile and GenerateBindings are not run because _ComputeFilesToPublishForRuntimeIdentifiers is true in the specific broken build, causing Microsoft.Android.Sdk.BuildOrder.targets to not be imported. Still not sure if it's an issue in our side or on your side though.

[dellis1972]

Hmm this might be an inner build issue then. Afaik _ComputeFilesToPublishForRuntimeIdentifiers is only set when we do an inner build to collect outputs, it should not be running targets which delete files.

cc @jonathanpeppers what do you think?

[Youssef1313]

I opened #9007 with binlog and all info I could find.