Remove System.IO.Pipelines from ASP.NET Core shared framework

[davidfowl]

It's now in Microsoft.NETCore.App with this PR dotnet/runtime#39524

[dougbu]

I'm pretty sure removal will be automatic but we'll need to adjust our shared Fx and targeting pack tests in whatever dependency PR gets the updated runtime bits. Basically, this issue is something to keep in mind for our ops-on-call person (currently @wtgodbe).

@ericstj will System.IO.Pipelines.dll show up in Microsoft.NETCore.App.Ref as well as Microsoft.NETCore.App.Runtime.* packages❔

[JunTaoLuo]

We might need to update some of files though. I think we would no longer need this: https://github.com/dotnet/aspnetcore/blob/master/eng/Dependencies.props#L68. This can be done by ops during rotation where we get the dependency update.

[dougbu]

Agreed @JunTaoLuo though that line might not break the dependency PR's build -- as the list of expected content in our tests will.

We probably won't need https://github.com/dotnet/aspnetcore/blob/master/eng/SharedFramework.External.props#L43 either unless this turns out to be one of the oddities included in Microsoft.NETCore.App.Runtime.* but not Microsoft.NETCore.App.Ref.

[ericstj]

@ericstj will System.IO.Pipelines.dll show up in Microsoft.NETCore.App.Ref as well as Microsoft.NETCore.App.Runtime.* packages

It should. I also noticed a packaging problem in that PR that needs to be corrected, so be on the lookout for that.

[davidfowl]

Is this solved now?

[wtgodbe]

@captainsafia did this get fixed during your ops duty? CC @dougbu

[dougbu]

I don't think #24496 needed to change the shared Fx tests and that indicates we either don't have recent-enough runtime dependencies (surprisingly) or changes mentioned above are needed to remove duplicate copies of the assembly. So, the question is really whether we see System.IO.Pipelines.dll in both Microsoft.NETCore.App.Runtime and Microsoft.AspNetCore.App.Runtime packages. If yes, we're up-to-date and need to remove that duplication.

[davidfowl]

Who is doing this work?

[davidfowl]

Can somebody direct on how to do this?

[wtgodbe]

I can take a look Monday

[dougbu]

@pranavkm fixed this in 56be06b aka "Update test runner to 2.4.3 (#24685)". We just forgot to close the issue.

[davidfowl]

I don't see it in the latest builds. When I install RC1 I still see pipelines

[dougbu]

@davidfowl that likely means our builds w/ 56be06b in them are not yet part of the installer you tried. But, our tests focus in the *.nupkg assets and don't double-check e.g. the Zip files.

@wtgodbe can you please download the shared Fx and targeting pack outputs from a recent official build of 'master' to confirm none contain System.IO.Pipelines❔ Reopen this issue if we missed something.

[davidfowl]

The installer is what matters. It should be trivial to check if it's up to date with ASP.NET right?

[dougbu]

I shouldn't have used the word "likely". I'd already checked the staleness and dotnet/installer is 10 days or 35 builds behind dotnet/aspnetcore. That's much older than @pranavkm's changes.

My question to @wtgodbe was about confirming things will work correctly when dotnet/installer catches up.

[davidfowl]

Why is it so far behind...

[dougbu]

I think the hold-up is mostly around ingesting dotnet/sdk into dotnet/installer. See discussions in dotnet/installer#8129

dotnet/sdk is at least caught up to our builds from 4 days ago.