Cannot connect NamedPipeClientStream later when constructing it with an existing pipe handle
#83,073 创建于 2023年3月7日
仓库指标
- Star
- (17,886 star)
- PR 合并指标
- (平均合并 12天 11小时) (30 天内合并 661 个 PR)
描述
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.