Try out BuildProjectReferences=false in Components

[BrennanConroy]

Same change as #34137 which was made to try and reduce build flakiness.
https://github.com/dotnet/aspnetcore-internal/issues/3915#issuecomment-928011626 for more info

[BrennanConroy]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[dougbu]

GitHub and AzDO are very confused: GitHub tried to cancel previous build for this PR but a few jobs are still running☹️

🤞 AzDO and GitHub eventually catch up (and that this change works 😃)

[BrennanConroy]

GitHub and AzDO are very confused

That's what I get for doing manual builds before opening a PR :D

[dougbu]

WFM though I'm surprised this doesn't cause new and different ordering issues e.g. Wasm.Prerendered.Server.csproj dependencies not being ready when Microsoft.AspNetCore.Components.E2ETests.csproj asks Wasm.Prerendered.Server.csproj to build.

[dougbu]

That's what I get for doing manual builds before opening a PR :D

Recommend draft PRs unless you need to test things w/ internal builds.

[SteveSandersonMS]

WFM though I'm surprised this doesn't cause new and different ordering issues e.g. Wasm.Prerendered.Server.csproj dependencies not being ready when Microsoft.AspNetCore.Components.E2ETests.csproj asks Wasm.Prerendered.Server.csproj to build.

Yes, I wondered too. Does this change mean we're just hoping the build ordering/parallelism happens to work out OK, or is there anything that ensures it? I'd be concerned if we're merging this on the basis that it happens to pass in CI by chance.

Also when building the E2ETests project locally, does it mean it no longer rebuilds any dependencies that have been changed? Because if so that would harm productivity for us and contributors. Update: not really an issue because this change doesn't apply to debug builds.

[pranavkm]

Isn't this problematic? If there's a reference that is unique to one of these projects, it'll never get built?

[dougbu]

@pranavkm that part I get 😄 The item group @BrennanConroy is changing is only used on the CI or when building the Release configuration. See

• aspnetcore/src/Components/test/E2ETest/Microsoft.AspNetCore.Components.E2ETests.csproj

  Lines 28 to 29 in 87a22b5

  	<TestTrimmedApps Condition="'$(ContinuousIntegrationBuild)' == 'true'">true</TestTrimmedApps>
  	<TestTrimmedApps Condition="'$(Configuration)' == 'Release'">true</TestTrimmedApps>

• aspnetcore/src/Components/test/E2ETest/Microsoft.AspNetCore.Components.E2ETests.csproj

  Line 58 in 87a22b5

  <ItemGroup Condition="'$(TestTrimmedApps)' == 'true'">

[BrennanConroy]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[BrennanConroy]

Running again for sanity, planning on merging if it passes again.

[SteveSandersonMS]

Running again for sanity, planning on merging if it passes again.

Asking again, with this change, is there anything that causes the build ordering/parallelism to be valid, or does it just happen to work by chance?

[BrennanConroy]

is there anything that causes the build ordering/parallelism to be valid, or does it just happen to work by chance?

Components being near the end of the stack is probably why this just works. I understand your ordering concerns but I'd rather try this out to see if the 'file in use' issues stop happening and revert/file an issue if we see ordering issues. Right now we have little to no information about the build problems we've been seeing and this PR will hopefully give us some info.

Plus, Components already has this change for another of the project references so build ordering isn't a new problem here, it just might be more likely now.

[dougbu]

is there anything that causes the build ordering/parallelism to be valid, or does it just happen to work by chance?

The changed project also has a lot of dependencies, likely covering (almost❔) everything the few dependencies passed $(BuildProjectReferences) need. Those dependencies also appear at the end of the item group and will be processed last.

[SteveSandersonMS]

OK, sounds reasonable! We'll have to see how this turns out in practice.

[wtgodbe]

/backport to release/6.0

[github-actions]

Started backporting to release/6.0: https://github.com/dotnet/aspnetcore/actions/runs/1292816098