Microsoft.AspNetCore.Connections.Abstractions referenced version mismatch to System.IO.Pipelines

[Kaelum]

Simply upgrading from SDK 3.1.101 to SDK 3.1.102 causes the following build error in an ASP.NET Core application subassembly:

CSC : error CS1705: Assembly 'Microsoft.AspNetCore.Connections.Abstractions' with identity 'Microsoft.AspNetCore.Connections.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' uses 'System.IO.Pipelines, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.IO.Pipelines' with identity 'System.IO.Pipelines, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

The application has a dual HTTP/TCP interface, where a custom middleware class manages the HTTP interface, and a custom ConnectionHandler manages the TCP interface (directly accessing the pipelines). For now, I'm using a global.json file to force the use of SDK 3.1.101.

[javiercn]

@Kaelum thanks for contacting us.

I believe we had an issue here with the 3.1.102 release but that it got fixed. @halter73 can you confirm/give steps to fix it?

[Tratcher]

@dotnet/aspnet-build

[Pilchie]

@Kaelum do you have an explicit package reference to System.IO.Pipelines?

[Kaelum]

@Pilchie no, I didn't have an explicit reference, and I was hesitant to add one due to an issue in the past that was made worse by doing so. Since it was an issue of not being able to find the correct version of the library, as opposed to finding the library at all, I didn't think that would work.

Anywho, I added an explicit reference to the project that wasn't building, and it seems to be working now. I'll need to remember to remove the reference, once the Runtime/SDK packages are fixed.

Thanks

[Kaelum]

Reopening this for those who have the same issue, until this is actually fixed in the packaging.

[analogrelay]

I believe this is the same root cause as #19133 (does that sound right @Pilchie ?)

[dougbu]

Well, it sounds right to me 😈

[Pilchie]

I'm not sure it is. In #19133, the C# compiler ends up with no references to System.IO.Pipelines because it's not in the ref pack. Here, the C# compiler seems to end up with 2 references of different versions. @Kaelum do you have a project you can share that exhibits this?

[Kaelum]

@Pilchie I was in the process of trying to create an application that exhibits the behavior, and I wasn't having any luck. So, I decided to open the Object Browser to see where the 4.0.0.0 version was being referenced, and saw that it is coming from a .NET Standard 1.3 library of ours. The v3.1.2 package is requiring System.IO.Pipelines [4.0.2.0], doesn't have it, and found System.IO.Pipelines [4.0.0.0] in the .NET Standard 1.3 package.

[Pilchie]

@ericstj - any ideas about the packaging of System.IO.Pipelines here?

[ericstj]

So just trying to read through the original scenario.

This is an app referencing Microsoft.AspNetCore.Connections.Abstractions which references System.IO.Pipelines 4.0.2.0. That's the version we built in 3.1.0 https://github.com/dotnet/corefx/blob/0f7f38c4fd323b26da10cce95f857f77f0f09b48/src/System.IO.Pipelines/Directory.Build.props#L4. The reference is coming from ASP.NET's ref pack, so it's expecting to have that version of Pipelines. Unfortunately ASP.NET's ref pack had a bug and dropped that assembly so the reference is dangling.

The app also references some other package which brings in a lower version of System.IO.Pipelines. Since ASP.NET's ref pack was missing its copy, this older package's copy makes it to the compiler.

Here, the C# compiler seems to end up with 2 references of different versions.

It actually looks to me like the compiler sees an indirect reference to a higher version, and a direct reference to the lower version.

This should be fixed when you bring System.IO.Pipelines back into the refpack: #19133

To workaround the bug add a direct reference to System.IO.Pipelines 4.7.0 or newer to your project.

[analogrelay]

Ok, so it sounds like it is the same root cause and we can probably close this as a duplicate of #19133

[analogrelay]

Closing as a duplicate of the other issue.