AppFabric自动启动与名为管道端点的wcf服务冲突 [英] AppFabric Auto-Start conflicts with wcf services named pipe endpoints

查看:89
本文介绍了AppFabric自动启动与名为管道端点的wcf服务冲突的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个带有WCF服务的应用程序,每个服务都有netNamedPipe端点。

I have an Application with WCF services, each one of them have netNamedPipe endpoint.

当我启用自动启动时,端点不可用(超时)。

When I enable Auto-Start, the endpoints are not available (timeout).

当我禁用自动启动时,一切正常。

When I disable Auto-Start, everything works fine.

我知道自动启动使用命名管道来启动服务。但是为什么这与常规的命名管道端点冲突?

I understand that Auto-Start uses named pipes to start services. But why does that conflict with regular named pipe endpoints?

如何避免这种冲突(仍然可以使用自动启动和命名管道端点)?

How can I avoid thoses conflicts (and still can use both Auto-Start and named pipe endpoints)?

推荐答案

我认为这是因为通过自动启动管理端点并使用网络命名管道绑定。我试图思考这个场景几次,并且想知道你是否可以从你的服务公开多个基地址,然后用
然后使用一个地址用于自动启动请求而另一个地址用于常规服务请求。

I think this is because with auto start the management of the endpoints uses the net named pipe binding. I tried to think through this scenario a couple times and was wondering if you could expose more than one base address from your service and then use one address for auto start requests and the other for regular service requests.

如果您创建了自定义工作流程服务主机,则可以更灵活地选择使用哪些地址进行自动启动管理。以下示例为您提供了一个起点:$ b​​ $ b http://code.msdn.microsoft.com/Windows -Workflow-6b4ffbe8。

If you created a custom workflow service host you could be more selective in choosing which addresses are used for auto start management. The following sample gives you a starting point: http://code.msdn.microsoft.com/Windows-Workflow-6b4ffbe8.

谢谢,


这篇关于AppFabric自动启动与名为管道端点的wcf服务冲突的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆