Имя контракта WCF 'IMyService' не найдено? - PullRequest
50 голосов
/ 28 марта 2009

Имя контракта 'IMyService' не найдено в списке контрактов, реализованных службой 'MyService' .. ---> System.InvalidOperationException: имя контракта 'IMyService' не найдено в списке контрактов. реализовано сервисом «MyService».

Это сводит меня с ума. У меня есть веб-сервис WCF, который работает на моем компьютере разработчика, но когда я копирую его на виртуальную машину, которую я использую для тестирования, я получаю сообщение об ошибке, которое указывает на то, что я не реализую интерфейс, но не смысл, потому что служба работает на моем Windows XP IIS. Виртуальная машина использует Windows Server 2003 IIS. Есть идеи?

Следует отметить, что я получаю эту ошибку на своей виртуальной машине даже при попытке доступа к службе в веб-браузере в качестве клиента.

Примечание: я использую PrincipalPermissionMode = "UseWindowsGroups", но это не проблема на моей локальной машине. Я просто добавляю себя в соответствующую группу окон. Но не повезло на моей виртуальной машине.

Config:

<configuration>
    <system.serviceModel>
        <diagnostics>
            <messageLogging logEntireMessage="false" maxSizeOfMessageToLog="2147483647" />
        </diagnostics>
        <services>
            <service behaviorConfiguration="MyServiceBehaviors" name="MyService">
                <endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding"
                  name="MyService" bindingName="basicHttpBinding" bindingNamespace="http://my.test.com"
                  contract="IMyService">
                </endpoint>
            </service>
        </services>
        <bindings>
            <basicHttpBinding>
                <binding name="basicHttpBinding" maxReceivedMessageSize="2147483647">
                    <readerQuotas maxStringContentLength="2147483647" />
                    <security mode="TransportCredentialOnly">
                        <transport clientCredentialType="Windows" proxyCredentialType="None" />
                    </security>
                </binding>
            </basicHttpBinding>
            <netTcpBinding>
                <binding name="WindowsClientOverTcp" maxReceivedMessageSize="2147483647">
                    <readerQuotas maxStringContentLength="2147483647" />
                </binding>
            </netTcpBinding>
            <wsHttpBinding>
                <binding name="wsHttpBinding" maxReceivedMessageSize="2147483647">
                    <readerQuotas maxDepth="32" maxStringContentLength="2147483647"
                      maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                </binding>
            </wsHttpBinding>
        </bindings>
        <behaviors>
            <serviceBehaviors>
                <behavior name="MyServiceBehaviors">
                    <serviceMetadata httpGetEnabled="true" />
                    <serviceAuthorization principalPermissionMode="UseWindowsGroups"
                      impersonateCallerForAllOperations="false" />
                    <serviceCredentials />
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>
</configuration>

Ответы [ 14 ]

103 голосов
/ 01 апреля 2010

[ServiceContract] отсутствовал в моем случае.

32 голосов
/ 23 марта 2010

@ Гарри (немного поздно, я знаю)

Если ваш атрибут ServiceContract определяет ConfigurationName, это должно быть значение в конечной точке, а не полное имя. У меня только что была эта проблема, как описано в ОП, и это было для меня решением. Надеюсь, что это поможет кому-то еще, кто сталкивается с этим.

13 голосов
/ 02 февраля 2011

Это немного более необычное решение, которое применимо к моей ситуации с той же ошибкой:

Возможно, что пространство имен контракта может быть переопределено следующим атрибутом:

[System.ServiceModel.ServiceContractAttribute([...], ConfigurationName = "IServiceSoap")]
public interface ISomeOtherServiceName

Что потребует:

<endpoint address="" binding="basicHttpBinding" contract="IServiceSoap" />

Вместо обычного (пространство имен) .ISomeOtherServiceName .

Это может быть результатом генерации кода, в моем случае WSCFBlue

9 голосов
/ 08 февраля 2012

Ваш атрибут имени в элементе службы и атрибут контракта в элементе конечной точки неверны. Они должны быть полностью квалифицированными именами:

<service name="namespace.MyService">
      <endpoint contract="namespace.IMyService" >

Как только вы измените значения на полные имена, которые должны устранить вашу ошибку.

8 голосов
/ 18 мая 2009

Разве атрибут контракта на конечной точке не должен быть полностью определенным пространством имен?

6 голосов
/ 19 мая 2009

да @ Гарри, ты прав. контракт в конечной точке должен быть полностью квалифицированным именем

<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding"      name="MyService" bindingName="basicHttpBinding" bindingNamespace="http://my.test.com"  contract="Namespace.IMyService">
3 голосов
/ 08 февраля 2012

У меня есть привычка делать это ...

<system.serviceModel>
    <services>
      <service name="Service" behaviorConfiguration="wsHttpBehaviour">
        <endpoint 
            binding="wsHttpBinding" 
            contract="IService" 
            bindingConfiguration="wsHttpBinding" 
            />
        <endpoint contract="IService" binding="mexHttpBinding" address="mex" />
      </service>

когда я должен это сделать ...

<system.serviceModel>
    <services>
      <service name="namespace.Service" behaviorConfiguration="wsHttpBehaviour">
        <endpoint 
            binding="wsHttpBinding" 
            contract="namespace.IService" 
            bindingConfiguration="wsHttpBinding" 
            />
        <endpoint contract="namespace.IService" binding="mexHttpBinding" address="mex" />
      </service>

Посмотри, что я имею в виду ... Это самая глупая вещь в мире (особенно когда приложение содержит только 1 или 2 элемента), но «полностью определенное» имя класса, кажется, имеет значение.

1 голос
/ 15 сентября 2014

Используя пункт меню «Добавить» -> «Сервис» в Visual Studio 2013, я создал разделы веб-конфигурации для меня, но с «конечной точкой» «контракт» установлено имя конкретного класса, а не интерфейса.

Как только я исправил, все начало работать.

1 голос
/ 21 февраля 2012

В моем случае проблема заключалась в неправильном названии пространства имен. НТН

1 голос
/ 10 августа 2011

У меня была та же ошибка, но источник проблемы был другим. Я учился по ходу дела и сначала создал службу с использованием службы WCF с поддержкой Silverlight из шаблонов Silverlight в Visual Studio. Я назвал это TerritoryService. Когда вы создаете сервис таким способом, web.config изменяется, как показано ниже:

 <services>
      <service name="Services.TerritoryService">
        <endpoint address="" binding="customBinding" bindingConfiguration="Services.TerritoryService.customBinding0"
          contract="Services.TerritoryService" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>

Примеры, над которыми я работаю, используют DomainServices.i.e. при их использовании вы наследуетесь от DomainService. Поэтому я удалил созданный мною TerritoryService, а затем создал класс DomainService из шаблона из меню веб-шаблонов в Visual Studio. Я продолжал работать, и все собрано просто отлично. Но когда я запустил его, я получил ошибку в соответствии с названием этого вопроса.

Проблема заключается в том, что при наследовании от службы домена такая запись не создается в файле web.config. Это не нужно. Но при удалении службы, созданной с помощью веб-службы с поддержкой Silverlight, она НЕ удаляет запись в файле web.config.

Так как я назвал обе службы TerritoryService, когда служба вызывалась, запись в web.config была включена в игру, и сервер начал искать службу, определенную таким образом, которую он не смог найти, потому что я удалил это.

Таким образом, решение состояло в том, чтобы просто удалить заглушки ввода, как описано выше, которые были автоматически созданы Visual Studio в файле конфигурации, но не были автоматически удалены Visual Studio, когда я удалил службу. Как только я это сделал, проблема была решена.

Мне потребовалось полчаса, чтобы разобраться с этим из-за именования "конфликт". Он «выглядел» очень правильно и соответствовал многим примерам. Так что, если вы наследуете от класса обслуживания домена, вам не нужно / не должно быть записи в файле конфигурации, как при создании службы wcf.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...