GenerateBindings and AddBindingsToCompile are not run for a project build happening under _ResolveAssemblies causing incremental builds to break

[Youssef1313]

Android framework version

net8.0-android

Affected platform version

34.0.95

Description

pr2.zip

In this binlog, there are two builds of Uno.UI.BindingHelper.Android.netcoremobile.csproj with IDs 351 and 88.

The build for 351 is fine and correct (it's resulting from ResolveProjectReferences on SamplesApp.netcoremobile.csproj)

The build for 88 is very problematic, it's resulting from _ResolveAssemblies which sets

https://github.com/xamarin/xamarin-android/blob/b521487d0226db265baaa83f0f53e2e75497c420/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.AssemblyResolution.targets#L91

Now that this build is happening with _ComputeFilesToPublishForRuntimeIdentifiers being true, the Microsoft.Android.Sdk.BuildOrder.targets isn't imported. Then, CompileDependsOn is missing the GenerateBindings and AddBindingsToCompile targets. This causes _GenerateCompileDependencyCache to not include some files, breaking things VERY badly.

In the above binlog, _GenerateCompileDependencyCache of build 351 is run first, then that of build 88 which overwritten Uno.UI.BindingHelper.Android.netcoremobile.csproj.CoreCompileInputs.cache causing Uno.UI.BindingHelper.Android.netcoremobile to be rebuilt unnecessarily, which then causes almost everything to be rebuilt.

Steps to Reproduce

Binlog shows it all I think. If more info is needed, let me know.

Did you find any workaround?

No response

Relevant log output

No response

[dellis1972]

@Youssef1313 this all happens within Visual Studio I assume?

Do you get the same issue from the command line?

[Youssef1313]

My testing was from command-line actually. But I assume it's an issue in VS as well.

[dellis1972]

Now that I think this over AddBinginsToCompile should only be run on the outer builds. Since the source code will not change (like all the other code). So I would expect to see it run before all the abi specific inner builds run. This is all assuming its an android build of course. I guess it gets more complicated when we have multiple platforms as the outer build, then a platform specific inner build then abi specific inner inner builds.

I'm not even sure we have a unit test to cover that as integrating single projects like maui into our repo testing framework has proved very problematic since maui is always being updated and changing.

@jonathanpeppers do you have any thoughts on this one?

[Youssef1313]

Now that I think this over AddBinginsToCompile should only be run on the outer builds.

I'm not very much following on "why".

To me, not running it will simply cause _GenerateCompileDependencyCache to not have all the .cs inputs, which then causes a lot of trouble.

[jonathanpeppers]

Generally, the Android inner build only runs <ILLink/> and the AOT compiler. I don't think it even would run the C# compiler at all? Doesn't seem like AddBindingsToCompile should run in an inner build?

See this for some details:

• [question] Android's implementation of multiple $(RuntimeIdentifiers) sdk#14359

I've not had a chance to look into this one to see what might be going wrong here. I've been focusing on MAUI, unfortunately.

[Youssef1313]

Well, as part of the build happening under _ResolveAssemblies there is ResolveProjectReferences which then invokes MSBuild

https://github.com/dotnet/msbuild/blob/98c28cc33dc4671e6d502e41c80c610b54085139/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2133-L2145

[jonathanpeppers]

Ok, so maybe we need $(_ComputeFilesToPublishForRuntimeIdentifiers) to always be unset during ResolveProjectReferences. This could go wrong depending on what order projects are built.

There is a RemoveProperties argument for the <MSBuild/> task:

• https://learn.microsoft.com/visualstudio/msbuild/msbuild-task

Looking at:

https://github.com/dotnet/msbuild/blob/98c28cc33dc4671e6d502e41c80c610b54085139/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2123

I guess we could try $(_GlobalPropertiesToRemoveFromProjectReferences)? It's private...

[Youssef1313]

To me it's quite scary to rely on private properties of MSBuild, but it could work (and, well, I sometimes rely on MSBuild internals myself 😄).

[jonathanpeppers]

@Youssef1313 can you test if that works around your problem for now?

<_GlobalPropertiesToRemoveFromProjectReferences>$(_GlobalPropertiesToRemoveFromProjectReferences);_ComputeFilesToPublishForRuntimeIdentifiers</_GlobalPropertiesToRemoveFromProjectReferences

This is used in a few places:

• https://grep.app/search?q=_GlobalPropertiesToRemoveFromProjectReferences&filter[lang][0]=XML

[Youssef1313]

Sure. I'll test it and let you know.

[Youssef1313]

@jonathanpeppers Thanks. I tested it and it works. However, is it something that can be done on your side instead of consumers having to deal with it?

[jonathanpeppers]

Do you have an idea of what project/solution structure would cause this to break? I think next step would be for us to write a test to reproduce the problem.

[Youssef1313]

@jonathanpeppers Unfortunately, I have no minimal repro. But maybe the binlog in the issue could help crafting a repro?