Future of System.IO.Pipes.AccessControl Package.

[Anipik]

We bought back this package here #38177 to expose some apis.
This package has a dependency on the implementation assembly on System.IO.Pipes which is part of shared framework.

Currently to unblock #44373 we harvested the 5.0 and added 6.0 tfm in the package.
Some other options here are

• Deadend the package if dont meant to expose any apis cc @carlossanlop do u know if we intend to do that.
• Take a dependency on a net5.0 runtimepack and then adding a manual reference to system.io.pipes

cc @ViktorHofer @ericstj @safern

[ViktorHofer]

Unless we start producing targeting packs for previous .NETCoreApp versions I assume the latter option wouldn't work with source build. I believe we don't yet build anything else than $(NetCoreAppCurrent) in source build but it came up in the past.

[Anipik]

yeah sourcebuild was the reason @ericstj suggested to not do this, but we should expore some optons here to avoid harvesting

[ViktorHofer]

Yeah I agree with that we shouldn't use harvesting here as it would suggest to use it as a fallback when an asset isn't buildable anymore.

[carlossanlop]

Deadend the package if dont meant to expose any apis cc @carlossanlop do u know if we intend to do that.

I recently added these APIs to System.IO.Pipes.AccessControl for 5.0:

runtime/src/libraries/System.IO.Pipes.AccessControl/ref/System.IO.Pipes.AccessControl.cs

Lines 69 to 77 in 6072e4d

	public static class AnonymousPipeServerStreamAcl
	{
	public static System.IO.Pipes.AnonymousPipeServerStream Create(System.IO.Pipes.PipeDirection direction, System.IO.HandleInheritability inheritability, int bufferSize, System.IO.Pipes.PipeSecurity? pipeSecurity) { throw null; }
	}
	public static class NamedPipeServerStreamAcl
	{
	public static System.IO.Pipes.NamedPipeServerStream Create(string pipeName, System.IO.Pipes.PipeDirection direction, int maxNumberOfServerInstances, System.IO.Pipes.PipeTransmissionMode transmissionMode, System.IO.Pipes.PipeOptions options, int inBufferSize, int outBufferSize, System.IO.Pipes.PipeSecurity? pipeSecurity, System.IO.HandleInheritability inheritability = System.IO.HandleInheritability.None, System.IO.Pipes.PipeAccessRights additionalAccessRights = default) { throw null; }
	}

Does that answer the question, @Anipik ?

[ViktorHofer]

@carlossanlop to rephrase the question, do we expect the package to be updated again in this release cycle?

[safern]

@carlossanlop to rephrase the question, do we expect the package to be updated again in this release cycle?

To rephrase this, do we expect new APIs? Cause if there is a bug fix we can always do it in the release/5.0 branch, right?

[ViktorHofer]

Caution: 5.0 isn't LTS. Bugfixes could only be done in 5.0 for a year.

[carlossanlop]

Right now, we don't have any open issues or API proposals related to System.IO.Pipes.AccessControl. And I think we have already ported all the essential Windows-specific APIs from .NET Framework, so I don't expect any new API proposals in this area.

If we ever have to fix bugs in the Windows-specific APIs, the actual source code is in System.IO.Pipes. For example:

• runtime/src/libraries/System.IO.Pipes/src/System/IO/Pipes/AnonymousPipeServerStreamAcl.cs

• runtime/src/libraries/System.IO.Pipes/src/System/IO/Pipes/NamedPipeServerStreamAcl.cs

[ViktorHofer]

Thanks Carlos, that helps in the decision making process. Ideally we would not resort to any of these hacks but make the net5.0 asset buildable. I don't know what that would involve (API shifting?). @ericstj and I talked about this briefly.

[ericstj]

Cause if there is a bug fix we can always do it in the release/5.0 branch, right?

Caution: 5.0 isn't LTS. Bugfixes could only be done in 5.0 for a year.

What bug fix would we do? I think this package only ships a reference assembly and a full facade.

[ViktorHofer]

What bug fix would we do? I think this package only ships a reference assembly and a full facade.

I didn't know that, great. Sounds to me that removing the package should be considered.

[carlossanlop]

What does it mean to remove the package? What are the consequences? If we do that, and someone wants to invoke System.IO.Pipes.AccessControl.NamedPipeServerStreamAcl.Create(...), how would they do that from now on?

[ViktorHofer]

We are about removing the infrastructure to produce a package for System.IO.Pipes.AccessControl in this repo's master branch, not removing the package from nuget.org.

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We bought back this package here #38177 to expose some apis.
This package has a dependency on the implementation assembly on System.IO.Pipes which is part of shared framework.

Currently to unblock #44373 we harvested the 5.0 and added 6.0 tfm in the package.
Some other options here are

• Deadend the package if dont meant to expose any apis cc @carlossanlop do u know if we intend to do that.
• Take a dependency on a net5.0 runtimepack and then adding a manual reference to system.io.pipes

cc @ViktorHofer @ericstj @safern

Author:	Anipik
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[safern]

@ViktorHofer I believe this can be closed as it is covered by: #47530 ?