Skip to content

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

Open

Description

@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

Activity

  1. added
    Area: App+Library BuildIssues when building Library projects or Application projects.
    and removed
    needs-triageIssues that need to be assigned.
    on Jun 6, 2024
  2. dellis1972 commented on Jun 6, 2024

    @dellis1972
    Contributor

    @Youssef1313 this all happens within Visual Studio I assume?

    Do you get the same issue from the command line?

  3. Youssef1313 commented on Jun 6, 2024

    @Youssef1313
    MemberAuthor

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

  4. removed their assignment
    on Jun 6, 2024
  5. dellis1972 commented on Jun 7, 2024

    @dellis1972
    Contributor

    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?

  6. Youssef1313 commented on Jun 7, 2024

    @Youssef1313
    MemberAuthor

    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.

  7. jonathanpeppers commented on Jun 7, 2024

    @jonathanpeppers
    Member

    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:

    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.

  8. Youssef1313 commented on Jun 7, 2024

    @Youssef1313
    MemberAuthor

    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

  9. jonathanpeppers commented on Jun 7, 2024

    @jonathanpeppers
    Member

    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:

    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...

  10. Youssef1313 commented on Jun 7, 2024

    @Youssef1313
    MemberAuthor

    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 😄).

  11. jonathanpeppers commented on Jun 7, 2024

    @jonathanpeppers
    Member

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

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

    This is used in a few places:

  12. Youssef1313 commented on Jun 7, 2024

    @Youssef1313
    MemberAuthor

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

  13. Youssef1313 commented on Jun 10, 2024

    @Youssef1313
    MemberAuthor

    @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?

  14. jonathanpeppers commented on Jun 18, 2024

    @jonathanpeppers
    Member

    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.

  15. Youssef1313 commented on Jun 18, 2024

    @Youssef1313
    MemberAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area: App+Library BuildIssues when building Library projects or Application projects.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions