Cannot connect NamedPipeClientStream later when constructing it with an existing pipe handle
#83.073 aberto em 7 de mar. de 2023
Métricas do repositório
- Stars
- (17.886 stars)
- Métricas de merge de PR
- (Mesclagem média 12d 11h) (661 fundiu PRs em 30d)
Description
Closely related to https://github.com/dotnet/runtime/issues/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.