Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix underlying bug in Named Pipes preventing setting ReadMode after creation #98060

Closed
carlossanlop opened this issue Feb 6, 2024 · 2 comments

Comments

@carlossanlop
Copy link
Member

Follow up of the discussion in this API proposal (please read it for context): #83072

We need to match the behavior of both .NET Framework and Linux. Porting the constructor is not the only answer or even the best answer.

The alternatives are:

Fix the bug in the existing APIs

This is the ideal scenario and the most straightforward, and the one this issue intends to address.

Merge assemblies

Additional separate scenario.

We originally created all the System.*.AccessControl assemblies because we didn't want to mix OS-specific APIs. But we now have the SupportedOSPlatform attribute, which allows having OS-specific APIs in the same assembly. In other words, we could merge the AccessControl assemblies with the base assembly they were extending.

Port all the missing constructors

Additional separate scenario.

No point in porting only one missing .NET Framework constructor that we didn't add to .NET Core+. If we are doing the effort for one, let's just do the same for all.

@carlossanlop carlossanlop added area-System.IO untriaged New issue has not been triaged by the area owner labels Feb 6, 2024
@ghost
Copy link

ghost commented Feb 6, 2024

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

Follow up of the discussion in this API proposal (please read it for context): #83072

We need to match the behavior of both .NET Framework and Linux. Porting the constructor is not the only answer or even the best answer.

The alternatives are:

Fix the bug in the existing APIs

This is the ideal scenario and the most straightforward, and the one this issue intends to address.

Merge assemblies

Additional separate scenario.

We originally created all the System.*.AccessControl assemblies because we didn't want to mix OS-specific APIs. But we now have the SupportedOSPlatform attribute, which allows having OS-specific APIs in the same assembly. In other words, we could merge the AccessControl assemblies with the base assembly they were extending.

Port all the missing constructors

Additional separate scenario.

No point in porting only one missing .NET Framework constructor that we didn't add to .NET Core+. If we are doing the effort for one, let's just do the same for all.

Author: carlossanlop
Assignees: -
Labels:

area-System.IO, untriaged

Milestone: -

@ericstj
Copy link
Member

ericstj commented Feb 6, 2024

I don't think we need this. I've clarified the API request. I'll give that one more attempt at getting approved.

@ericstj ericstj closed this as completed Feb 6, 2024
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Feb 6, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Mar 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants