[release/2.1] Add @(ProjectReference) items for patched projects

[dougbu]

• [release/2.1] transitive dependencies aren't lifted for tests in patch builds #29023
• ensure tests do not use baseline assemblies for projects in current patch

---

Originally was an attempt to demonstrate #29023

• showed test indirect references let most tests keep working

[dougbu]

@Tratcher I believe I've confirmed #29023 is a real issue but would appreciate your confirmation. With the current state of this PR, I'd expect some Kestrel tests (for example) to fail but all I see listed in the Tests tab are projects with direct Microsoft.AspNetCore.Http references. Do you agree many more tests should have failed❔

[Tratcher]

Lol, you intentionally broke cookies? I would not expect any kestrel tests to fail, kestrel provides values rather than consumes them. However I'm surprised I don't see any failures in Security.

[dougbu]

Lol, you intentionally broke cookies?

😏

[dougbu]

🆗 the binary log 💯% confirmed Microsoft.AspNetCore.Http.dll was resolved from the baseline package in every project except test projects containing <Reference Include="Microsoft.AspNetCore.Http" />. That isn't what we want and I'm starting work on resolving #29023.

/fyi @dotnet/aspnet-build

[dougbu]

With help from @Forgind and @yuehuang010, this new target is now working. Many thanks❕

I'm going to try out a couple of tweaks locally then back out the first two commits (i.e. don't intentionally break tests) and turn this into a real PR😃

[dougbu]

Note latest iteration failed many more tests than previous ones i.e. transitive references to the project I broke are no longer hiding the break from test projects and samples.

[dougbu]

/fyi test run with the fix failed 404 tests on Windows and 322 elsewhere while run before fix failed far fewer -- 206 tests on Windows and 103 elsewhere.

[dougbu]

This is tell-mode because it's infrastructure and the changes affect only non-implementation projects.

[dougbu]

Put another way, the Conditions here and at the end of the target use a corner case of the task batching features. Shared metadata and batching on that metadata are the keys.

[wtgodbe]

What is this condition doing exactly? Add a direct reference to the projects being patched, unless...

[dougbu]

My mental model may be wrong (@Forgind and @yuehuang010, please chime in) but https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-batching?view=vs-2019#item-and-property-mutations contains some of the information

1. The %(Filename) item metadata causes the implicit CreateItem task to be batched
2. Use of that metadata also limits the @(ResolvedCompileFileDefinitions) and @(RuntimeCopyLocalItems) item groups to the item(s) with the same %(Filename)
   • This part doesn't seem to be explicit in the documentation
3. The OR clause confirms at least one such item exists

At a higher level, this creates a @(_ProjectsToAdd) item group containing those @(_ProjectsInPatch) items that match on filename with one or more @(ResolvedCompileFileDefinitions) or @(RuntimeCopyLocalItems) items, excluding existing @(ProjectReference) items. Another way of looking at it is the created item group contains the projects in the current patch that (a) aren't referenced directly but (b) match assemblies in the current build.

[yuehuang010]

I see it used in this exampled (https://docs.microsoft.com/en-us/visualstudio/msbuild/item-metadata-in-task-batching?view=vs-2019#divide-several-item-lists-into-batches). So, it is feature name is "Divide several item lists into batches":

    <Target Name="ShowMessage">
        <Message
            Text = "Number: %(Number) -- Items in ExampColl: @(ExampColl) ExampColl2: @(ExampColl2)"/>
    </Target>

[dougbu]

Good point @yuehuang010. I'm not sure how many times I read that example without thinking "Oh, this makes intersection / subsetting dead easy"😃

[dougbu]

@wtgodbe is there a reason the aspnetcore-pr-validation-temp pipeline still exists and is still the one we require for release/2.1 merges❔ Tests failed in the first run since I got rid of the intentional break but only in that pipeline. The same tests ran fine in aspnetcore-ci.

[wtgodbe]

@wtgodbe is there a reason the aspnetcore-pr-validation-temp pipeline still exists and is still the one we require for release/2.1 merges❔ Tests failed in the first run since I got rid of the intentional break but only in that pipeline. The same tests ran fine in aspnetcore-ci.

No, I can remove the validation-temp runs

[wtgodbe]

#29731