Transitive dependency issues in single-component UWP head

[Arlodotexe]

Problem

Single-component solutions are facing a transitive dependency issue on UWP heads. It can be fixed by making the transitive dependency an explicit dependency, but not all transitive dependencies are problematic. This ticket serves to investigate why this is happening, and what we can do about it.

Findings

Behaviors.Uwp.csproj project requires an explicit reference to the Animations project to build successfully, even though Animations is a transitive dependency. This behavior is not observed in the SettingsControls.Uwp.csproj project.

1. Dependency Chains:
   • Behaviors: Uwp -> Behaviors -> Animations -> Extensions. Had to manually add a direct reference from Uwp to Animations (but not Extensions for some reason) to fix the build issue.
   • SettingsControls: Uwp -> SettingsControl -> Triggers -> Helpers -> Extensions. No issue building.

2. Task Analysis:

   • Comprehensive comparison of all tasks in both binlogs was performed.
   • The sequence of task execution was analyzed for both projects.
   • Minor discrepancies such as the presence of the Touch task (related to file timestamp updates) in SettingsControls.Uwp.csproj and not in Behaviors.Uwp.csproj were noted, but aren't relevant to the issue.

3. MSBuild Task Parameters:

   • Parameters for MSBuild tasks were extracted and compared between the two components.
   • No significant discrepancies were found in the parameters.

4. Hypotheses and Proposed Experiments:

   • Depth of Dependency Chain: The additional intermediate project layer (Helpers) in the SettingsControls chain might influence transitive dependency resolution.
   • Multiple transitive references: The Behaviors source project has two dependencies that should be available transiently to the Uwp head, while the SettingsControls source project only has one. It's possible that the reference from Behaviors.Uwp to Animations was needed but the reference to Extensions wasn't because it can only resolve one transient reference.
   • Explicit vs. Transitive References: Making all dependencies explicit in the Behaviors component resolves the issue. As one possible workaround, we could build a way to detect and add these to the UWP head automatically. Not recommended.

Recommendations

We'll need to finish investigation to find out why the transitive dependencies are working fine in SettingsControls but not Behaviors. If we adjust the Behaviors project reference structure to match certain characteristics of the SettingsControls project graph, it may yield the information needed to file a proper bug report and create a workaround.

### Possible next steps:
- [ ] Introduce an intermediate project layer in the Behaviors component, similar to the `Helpers` layer in SettingsControls, and test the build. See what new information it yields.
- [ ] Introduce a second transient reference to `SettingsControls` to test if having multiple transitive references at the same level is the issue.
- [ ] Test with a minimal UWP project with similar nested dependencies to reproduce the issue outside of the current context.
- [ ] If all else fails, we'll build a way to autodetect transitive project references and add them to the head automatically.

[michael-hawker]

Wondering if it's because Behaviors directly references Extensions (which is also needed by the app) vs. the transitive inclusion of it elsewhere? That could be something to investigate with the all the issues we've had with duplicate ProjectReferences...

I also saw that if I only added Animations as a reference in Behaviors, instead of also re-adding Extensions and the HeaderedControls in the VS Project Reference dialog that I got this message:

3>"H:\code\CommunityToolkitWindows\components\Behaviors\heads\Uwp\Behaviors.Uwp.csproj" (Build;BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;DebugSymbolsProjectOutputGroup;DebugSymbolsProjectOutputGroupDependencies;DocumentationProjectOutputGroup;DocumentationProjectOutputGroupDependencies;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies;SGenFilesOutputGroup;SGenFilesOutputGroupDependencies target) (1) ->
3>(_WireUpCoreRuntime target) -> 
3>  C:\Users\mhawker\.nuget\packages\microsoft.net.uwpcoreruntimesdk\2.2.12\tools\CoreRuntime\Microsoft.Net.CoreRuntime.targets(238,5): error : CopyWin32Resources failed with exit code 701

Which I hadn't seen before, so not sure if that's also something related or not to maybe the underlying issue of what's happening here? It definitely seems related to UWP and the old-project style vs. new.

Maybe we should investigate upgrading MSBuildExtras?

Or at least if we can repro it outside as a minimal repro we can compare with and without it to see if that's a starting point?

[michael-hawker]

The test UWP head has the same issue as well... however, adding the references manually doesn't seem to be helping...

5>"H:\code\CommunityToolkitWindows\components\Behaviors\heads\Tests.Uwp\Behaviors.Tests.Uwp.csproj" (Build;BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;DebugSymbolsProjectOutputGroup;DebugSymbolsProjectOutputGroupDependencies;DocumentationProjectOutputGroup;DocumentationProjectOutputGroupDependencies;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies;SGenFilesOutputGroup;SGenFilesOutputGroupDependencies target) (1) ->
5>(_WireUpCoreRuntime target) -> 
5>  C:\Users\mhawker\.nuget\packages\microsoft.net.uwpcoreruntimesdk\2.2.12\tools\CoreRuntime\Microsoft.Net.CoreRuntime.targets(238,5): error : CopyWin32Resources failed with exit code 500

[niels9001]

Hitting this exact problem with SettingsControls/UWP as well, caused by the Triggers reference