dotnet/runtime

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

Open

#83,073 创建于 2023年3月7日

在 GitHub 查看
 (1 评论) (2 反应) (0 负责人)C# (5,445 fork)batch import
area-System.IOhelp wanted

仓库指标

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.

贡献者指南