Если у вас есть одна услуга (я предполагаю, что вы имеете в виду один контракт на обслуживание), и вы хотите выставить две конечные точки, то ваш вариант №2 должен быть тем, который нужно использовать.
Тем не менее, я вижу несколько проблем с вашей конфигурацией:
<service name="MyWcfService.MyService"
behaviorConfiguration="MyWcfService.HttpBehavior">
Что включает в себя «MyWcfService.HttpBehavior» ?? Что-нибудь, что может вызвать проблемы с конечными точками net.Tcp ??
<endpoint name="ApplicationHttp"
address="http://localhost:8731/MyWcfService/Application"
binding="basicHttpBinding"
bindingConfiguration="HttpBinding"
contract="MyWcfService.Interfaces.IMyService" />
<endpoint name="Application"
address="net.tcp://localhost:49153/MyWcfService/Application"
binding="netTcpBinding"
bindingConfiguration="SecuredByWindows"
contract="EmsHistorianService.Interfaces.IApplicationHistorianService" />
Если у вас одна услуга - один контракт на обслуживание, - атрибут contract=
обеих конечных точек приложения должен быть одинаковым.
Либо это первая (contract="MyWcfService.Interfaces.IMyService"
), либо вторая (contract="EmsHistorianService.Interfaces.IApplicationHistorianService"
) - я не знаю - но она должна быть одинаковой для обеих <endpoint>
записей, наверняка.
UPDATE:
@Sean: вы можете неправильно понимать механизм MEX: tcpMexBinding будет , а не отображать только привязки netTcp - и это полностью задумано и задумано. Привязки MEX представляют собой механизм, позволяющий получать метаданные о службе и всех ее конечных точках. Конечно, обе конечные точки MEX покажут все конечные точки приложения - в этом вся их цель. Конечные точки MEX предоставляют запрашивающему клиенту ( полные и нефильтрованные ) метаданные об услуге. Затем клиент сам решает, к какой конечной точке он может и хочет подключиться.