Cannot connect NamedPipeClientStream later when constructing it with an existing pipe handle

[carlossanlop]

Closely related to #83072, additional context in that issue.

When constructing a NamedPipeClientStream instance using the constructor that takes a SafePipeHandle, if you set the isConnected argument to false, then call client.Connect(), instead of reusing the pipe handle that was passed in the constructor, the Connect method attempts to create another pipe handle using the same name that was already used by the existing handle, which ends up throwing.

I have a working example here: https://github.com/carlossanlop/experiments/tree/NamedPipeClientStream_ReadMode

SafePipeHandle safePipeHandle = ConstructAPipeHandleWithoutConnectingIt();

NamedPipeClientStream client = new(
            direction,
            isAsync,
            isConnected: false, // Don't connect it yet
            safePipeHandle);

client.Connect(); // this throws

If you test the working example by changing this isConnected argument to false, and then add a client.Connect() invocation right after constructing the stream (somewhere here), the method will throw.

If there is a way to connect an existing pipe handle to the server (I suspect via WaitNamedPipe like in here), then we could detect if the user created the current client stream instance by passing a pipe handle, in which case, we should skip all the creation code in TryConnect and skip directly to attempting to connect it.

[ghost]

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

Issue Details

---

Closely related to #83072, additional context in that issue.

When constructing a NamedPipeClientStream instance using the constructor that takes a SafePipeHandle, if you set the isConnected argument to false, then call client.Connect(), instead of reusing the pipe handle that was passed in the constructor, the Connect method attempts to create another pipe handle using the same name that was already used by the existing handle, which ends up throwing.

I have a working example here: https://github.com/carlossanlop/experiments/tree/NamedPipeClientStream_ReadMode

SafePipeHandle safePipeHandle = ConstructAPipeHandleWithoutConnectingIt();

NamedPipeClientStream client = new(
            direction,
            isAsync,
            isConnected: false, // Don't connect it yet
            safePipeHandle);

client.Connect(); // this throws

If you test the working example by changing this isConnected argument to false, and then add a client.Connect() invocation right after constructing the stream (somewhere here), the method will throw.

If there is a way to connect an existing pipe handle to the server (I suspect via WaitNamedPipe like in here), then we could detect if the user created the current client stream instance by passing a pipe handle, in which case, we should skip all the creation code in TryConnect and skip directly to attempting to connect it.

Author:	carlossanlop
Assignees:	-
Labels:	area-System.IO
Milestone:	-