У меня есть служба WCF, которая отлично работает в локальной сети, но при попытке получить к ней доступ извне ссылка на службу выходит из строя.
Моя служба WCF размещается в окне win2k3, которое использует статический IP-адрес без домена.
У меня есть служба WCF, которая отлично работает в локальной сети, но при попытке получить к ней доступ извне ссылка на службу выходит из строя.
Моя служба WCF размещается в окне win2k3, которое использует статический IP-адрес без домена.
Я нашел ответ на этот вопрос после некоторого рытья - вот что я нашел, надеюсь, он может сэкономить кому-то еще некоторое время и беспокоиться.
1.) Добавьте IP-адрес к адресу конечной точки и добавьте имя узла с базовым IP-адресом, например:
<endpoint
address="http://xx.xx.xx.xx/ServiceApp/Service.svc"
binding="basicHttpBinding" contract="IService">
</endpoint>
<host>
<baseAddresses>
<add baseAddress="http://xx.xx.xx.xx/ServiceApp/" />
</baseAddresses>
</host>
Этого было достаточно, чтобы сделать мою справочную службу службы, но файл disco начал возвращаться с именем компьютера вместо ip (я думаю, это было после обновления до .NET 4.0).
2.) Если у вас есть доменное имя (www.myDomain.com), добавьте его в заголовок хоста в IIS.
3.) Добавьте IP-адрес и имя компьютера в файл хостов клиентов (легко исправить не всегда можно, чтобы все ваши клиенты добавили это в свой файл хоста)
4.) ЛУЧШЕЕ РЕШЕНИЕ, которое я нашел, это реализовать атрибут ServiceHosts Factory согласно сообщению "Timetheos" здесь: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c7fd51a2-773e-41d4-95a0-244e925597fe
Это сработало для меня, так как я мог тестировать локализацию и отладки моей библиотеки сервисов локально, а затем использовать служебное приложение для развертывания службы на своем dev-сервере и не должен был менять какие-либо файлы конфигурации после ее публикации.
Весь этот процесс был полным кошмаром, и я бы не пожелал этого никому, поэтому, если вы находитесь в той же ситуации и вам больше нужна информация о вышеуказанных моментах, просто свяжитесь с нами!
Это то, что сработало для меня. В файле конфигурации
< serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
< / system.serviceModel >
Если установлено значение false, я получаю эту сумасшедшую замену имени пользователя.
multipleSiteBindingsEnabled="true"
похоже, все, что я должен сделать для этого, чтобы он работал так, как должен.
Я искал подход к повторному использованию заголовка хоста из HTTP-запроса. По-моему, это должно работать в развитии, как в производстве.
Оказывается, это легко:
<behaviors>
<serviceBehaviors>
<behavior name="...">
...
<useRequestHeadersForMetadataAddress />
</behavior>
</serviceBehaviors>
</behaviors>
Таким образом, если конечная точка WSDL доступна клиенту, это гарантирует, что все связанные ресурсы wsdl/xsd будут доступны с одним и тем же базовым url.
Вы можете использовать звездочку * (подстановочный знак) вместо LocalHost или имя машины в базовом url, например:
<add baseAddress="net.tcp://*:4502/WxWcfService_01" />
Задайте конечную точку службы и httpgeturl следующим образом.
<services>
<service behaviorConfiguration="serviceBehaviour" name="Demo.Service.MultiEndPointsService">
<endpoint address="http://192.168.1.2/Demo.Service/MultiEndPointsService.svc/basic" binding="basicHttpBinding" bindingConfiguration="basicBinding" contract="Demo.Service.MultiEndPointsService" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehaviour">
<serviceMetadata httpGetEnabled="true" httpGetUrl="http://192.168.1.2/Demo.Service/MultiEndPointsService.svc/basic"/>
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>