File looks great. Filed dotnet/sdk#2937 to consume it.

Per @pakrym's suggestion, switched this to use ReferencePath instead. This should better align with what RAR does.

Result:
Microsoft.AspNetCore.App.PackageOverrides.txt

Doesn't this version assume all package references you have are 1:1 with assemblies? Is that guaranteed by anything?

It only makes that assumption for assemblies which build in this repo. And for this subset of stuff, yes, package id == assembly name.

Worth noting - this list includes package IDs for assemblies we shipped as OOB packages in 2.x, but have dropped in 3.0. For instance, Microsoft.AspNetCore.Mvc.Razor|3.0.0-preview3-t000. We haven't, and never plan to, ship Microsoft.AspNetCore.Mvc.Razor for 3.0.

I'm seeing stuff that is not in the repo in the generated file. Isn't it the project references that are in this repo?

Unless I'm misunderstanding, this would generate dupes if a package had more than one assembly:

 <_AspNetCoreAppPackageOverrides Include="@(ReferencePath->'%(NuGetPackageId)|%(NuGetPackageVersion)')" Condition=" '%(ReferencePath.NuGetPackageId)' != 'Microsoft.NETCore.App' AND '%(ReferencePath.NuGetSourceType)' == 'Package' " />

Not sure there are any such packages today or if dupes will break anything, but it seems like something I'd question if I ever had to revisit this code.

Worth noting - this list includes package IDs for assemblies we shipped as OOB packages in 2.x, but have dropped in 3.0. For instance, Microsoft.AspNetCore.Mvc.Razor|3.0.0-preview3-t000. We haven't, and never plan to, ship Microsoft.AspNetCore.Mvc.Razor for 3.0.

I think this is fine. This says that anything less than that version is overridden by this package, which is true.

@natemcmaster We're thinking that data files for targeting and runtime packs should go in the data/ folder of the package. So I'd suggest that the path for this file in the package should be data/PackageOverrides.txt.

I'm seeing stuff that is not in the repo in the generated file.

That's intentional. We include some assemblies like System.IO.Pipelines in the aspnet targeting pack. They are built by corefx, but for reasons, they didn't want it in microsoft.netcore.app.

My point is that it looks like you are assuming things outside this repo have 1 package:1 assembly. I doubt that will change in practice. But that was my point. (It was in response to the statement about the assumption being about things in this repo, not a statement that it's wrong for these to be in the file.)

Makes sense. So far, this assumption has been correct for all assemblies currently in the targeting pack. We don't really have a good way to test this, so it could break at some point 😬

Per your request, I've updated the PR to put the manifest in data/PackageOverrides.txt