在本地WCF命名管道上可能导致EndpointNotFoundException的原因
本文关键字:EndpointNotFoundException WCF 管道 | 更新日期: 2023-09-27 18:09:11
我已经设置了一个系统,让工作进程做一些工作,并与GUI进程和工作进程之间的命名管道进行协调。我在这里启动工作进程:
this.pipeGuidString = Guid.NewGuid().ToString();
var startInfo = new ProcessStartInfo(
"VidCoderWorker.exe",
Process.GetCurrentProcess().Id.ToString(CultureInfo.InvariantCulture) + " " + this.pipeGuidString);
startInfo.RedirectStandardOutput = true;
startInfo.UseShellExecute = false;
startInfo.CreateNoWindow = true;
this.worker = Process.Start(startInfo);
// When the process writes out a line, its pipe server is ready and can be contacted for
// work. Reading line blocks until this happens.
this.logger.Log("Worker ready: " + this.worker.StandardOutput.ReadLine());
bool connectionSucceeded = false;
this.logger.Log("Connecting to process " + this.worker.Id + " on pipe " + this.pipeGuidString);
var binding = new NetNamedPipeBinding
{
OpenTimeout = TimeSpan.FromSeconds(10),
CloseTimeout = TimeSpan.FromSeconds(10),
SendTimeout = TimeSpan.FromSeconds(10),
ReceiveTimeout = TimeSpan.FromSeconds(10)
};
this.pipeFactory = new DuplexChannelFactory<IHandBrakeEncoder>(
this,
binding,
new EndpointAddress("net.pipe://localhost/" + pipeGuid + "/VidCoder"));
this.channel = this.pipeFactory.CreateChannel();
this.channel.Ping();
然后在工作进程中:
host = new ServiceHost(
typeof (HandBrakeEncoder),
new Uri[]
{
new Uri("net.pipe://localhost/" + PipeGuidString)
});
host.AddServiceEndpoint(
typeof (IHandBrakeEncoder),
new NetNamedPipeBinding(),
"VidCoder");
host.Open();
encodeComplete = new ManualResetEventSlim(false);
Console.WriteLine("Service state is " + host.State + " on pipe " + PipeGuidString);
encodeComplete.Wait();
host.Close();
对大多数人(包括我)来说,它100%有效。但是一个用户报告说,当试图连接工作进程时,主机进程总是得到一个EndpointNotFoundException,即使有日志表明双方的GUID是相同的,并且工作进程的状态是打开的。
我想他的系统一定有什么问题导致了故障,我想知道是什么问题。
- 我试过通过远程桌面连接,这仍然适用于我。
- 我没有更改任何进程的强制完整性级别
- 我读了这个答案,所以我要求用户运行
net localgroup "NETWORK USERS"
,但组不存在 - (编辑)。管道监听器适配器服务已为用户禁用,但在用户启用并启动后它仍然不能工作。
还有其他关于为什么会发生这种情况的想法吗?我读了一些关于本地与全局命名管道的东西,但由于我在本地通信并在本地生成进程,因此它似乎不应该是一个问题。
(edit2)用户居然能得到一个WCF跟踪:http://engy.us/misc/TracesWithNetPipeStarted.svclog
(edit3)它显然在以管理员身份运行主机进程时有效。在这种情况下,管道通信的某些部分是否需要这些特权?我如何设置管道通道,使其永远不需要管理?
看一下这个SOA问答,它详细解释了一个WCF NetNamedPipeBinding服务是如何被全局发布的一个不相关的应用程序阻塞的,如果后者的服务URL被粗心地选择了。
对于你所描述的情况,这似乎是一个很合理的解释。我可以确认安装Garmin Express会干扰Named Pipes。例如,试图在VS中以非管理模式运行单元测试会导致测试运行器挂起。卸载Garmin Express可解决此问题。