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?

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

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

Additional information found during testing of the latest 8.1-rc.

It's worth noting that when consuming the nuget packages, installing the Media package doesn't automatically reference the transitive dependency on Animations, and this behavior is unexpected.

In order to reproduce any sample code from the Media component in our gallery, an end user application needs to install both Media and Behaviors, with Behaviors providing a transient dependency on Animations, but not Media. The transient dependency in Media on Animations is not picked up when Media is used via the NuGet package.

This is doubly unexpected because in the OP, we found that installing only Behaviors doesn't provide a transient dependency to Animations, contradicting what happened here (installing Behaviors did add a transient dependency to Animations). Possibly the fault of the Animations component and not the component that references it?

Worth noting our use of InternalsVisibleTo are using or being used by same set of components that keep appearing in these issues-- Behaviors, Animations, Media and Extensions.

If our use of InternalsVisibleTo is indeed related to our AoT issues on Wasdk as well as what we've seen here regarding transient dependencies, it might be highlighting a deeper issue with how we've set up these libraries.

We might want to go through and see if we can remove the need for these InternalsVisibleTo, it looks like at least a few are just to avoid helper duplication. If it fixes any of the issues we've listed throughout this ticket, we've narrowed the scope of our search down considerably.

Considering InternalsVisibleTo being involved, possibly related to #404

This seems to be a general issue with non-sdk style projects, which is what our UWP head uses. The issue was reported by a member of the Windows App Community here and a full, minimal repro (without the toolkit) was uploaded to GitHub here.

Until there's a clear path forward for resolving this for non-sdk style projects, I'm moving this back to "blocked".