The type or namespace name 'Pipelines' does not exist in the namespace 'System.IO'

[TaiNguyen2406]

I got this error after upgrade to .NET Core SDK 3.1.102 and I do not see anything about this changing in doc

[mkArtakMSFT]

Thanks for contacting us. Can you please share a sample repro project, where you observe this issue.
@anurse I'm not certain about the area-label for this one. Can you please adjust? Thanks!

[TaiNguyen2406]

here are screenshots of 2 version that I installed in my PC

[stevejgordon]

I am hitting this issue also. I have an XUnit integration test project defined which is failing with...

error CS0234: The type or namespace name 'Pipelines' does not exist in the namespace 'System.IO' (are you missing an assembly reference?) 
error CS0246: The type or namespace name 'PipeWriter' could not be found (are you missing a using directive or an assembly reference?) 

Curiously, this only seems to be a problem when running the tests as part of my Docker (Debian) build. Running the same tests directly on my Windows PC via VS and CLI and they seem to pass!

I have code in my API project which accepts the PipeWriter (BodyWriter) from the HttpContext.

[stevejgordon]

@mkArtakMSFT Minimal reproduction

Build using DockerfileOld works fine, but DockerfileNew fails. The only difference is the SDK and runtime image versions.

[benaadams]

Looks like its busted for .NET Core as well as ASP.NET Core https://twitter.com/gcaughey/status/1230107136493072384

[Drawaes]

We are having the same issue. Worked before update, doesn't find pipelines after update.

[jzabroski]

Ceci n'est pas une pipe :(

Also see this.

[Drawaes]

If you add the System.IO.Pipelines package directly to your project it should work for now (until the framework ref is fixed).

[Pilchie]

Tagging @wtgodbe who just mentioned this elsewhere. It looks like the things that are packages built out of dotnet/corefx but part of the "Microsoft.AspNetCore.App" Shared Framework aren't in the ref pack in 3.1.2. The workaround above is the right one for now, and we'll look at fixing this in the next patch :(

[leecow]

@rbhanda so that we can capture this in the release known issues doc.

[wtgodbe]

Yes, this was an unfortunate mistake ☹️. Based on my current understanding of the problem, we'll have similar issues for all of the following packages:

• System.Diagnostics.EventLog
• System.IO.Pipelines
• System.Security.AccessControl
• System.Security.Cryptography.Cng
• System.Security.Cryptography.Xml
• System.Security.Permissions
• System.Security.Principal.Windows
• System.Windows.Extensions
• Microsoft.Win32.Registry

[benaadams]

and we'll look at fixing this in the next patch

Is that a soon patch or next month patch? (Since last month's was also broken #18334 and this was meant to be the fix for it); just seems a bad look to go for 2 months where creating a vanilla project (file new, or dotnet new) is broken.

[Pilchie]

We're still investigating what a fix looks like, but it's unlikely to be sooner than next month - we've already merged the rest of the fixes for next month's patch to begin validation, and our infrastructure is not well suited to releasing a one-off like this right now, though that is something that we are improving in .NET 5.