Ошибка запуска службы WCF «Эта коллекция уже содержит адрес со схемой http»

Я создал веб-приложение, содержащее контракт службы WCF и элемент управления Silverlight, который выполняет вызовы этой службы WCF. На моих серверах разработки и тестирования это прекрасно работает.

При развертывании на нашем работающем сервере и запуске приложения я получаю исключение типа, в System.ServiceModel.ServiceActivationExceptionкотором говорится, что служба не может быть активирована из-за исключения во время компиляции. Исключение составляет:

Эта коллекция уже содержит адрес со схемой http. В этой коллекции может быть не более одного адреса на схему.

Я читал, что это исключение может быть сгенерировано, если у веб-сайта есть более одного заголовка узла, что верно для нашего живого сервера. Очевидно, службы WCF, размещенные в IIS, могут иметь только один базовый адрес. Как я могу обойти эту проблему?

В .Net 4 вы можете использовать multipleSiteBindingsEnabledопцию:

<system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true">
    </serviceHostingEnvironment>
</system.serviceModel>

Тогда вам не нужно будет указывать каждый адрес.

http://msdn.microsoft.com/en-us/library/system.servicemodel.servicehostingenvironment.multiplesitebindingsenabled.aspx

Резюме,

Кодовое решение: здесь

Конфигурационные решения: здесь

С помощью Майка Чалий я нашел несколько решений о том, как сделать это с помощью кода. Поскольку эта проблема затронет почти все проекты, которые мы развертываем в реальной среде, я придерживался чисто конфигурационного решения. В конце концов я нашел один, который подробно, как это сделать в .net 3.0 и .net 3.5.

Ниже приведен пример того, как изменить веб-конфигурацию ваших приложений:

<system.serviceModel>
    <serviceHostingEnvironment>
        <baseAddressPrefixFilters>
            <add prefix="net.tcp://payroll.myorg.com:8000"/>
            <add prefix="http://shipping.myorg.com:9000"/>
        </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
</system.serviceModel>

В приведенном выше примере net.tcp: //payroll.myorg.com: 8000 и http://shipping.myorg.com:9000 являются единственными базовыми адресами для их соответствующих схем, через которые будет разрешено проходить. BaseAddressPrefixFilter не поддерживает подстановочные знаки.

BaseAddress, предоставляемые IIS, могут иметь адреса, связанные с другими схемами, отсутствующими в списке baseAddressPrefixFilter. Эти адреса не будут отфильтрованы.

Решение DNS (не проверено): Я думаю, что если бы вы создали новую запись DNS, специфичную для вашего веб-приложения, добавили новый веб-сайт и дали ему один заголовок узла, соответствующий записи DNS, вы бы полностью решили эту проблему и не стали бы необходимо написать собственный код или добавить префиксы в ваш файл web.config.

Вы видели это - http://kb.discountasp.net/KB/a799/error-accessing-wcf-service-this-collection-already.aspx

Вы можете устранить эту ошибку, изменив файл web.config.

С ASP.NET 4.0 добавьте следующие строки в ваш web.config:

<system.serviceModel> 
     <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
</system.serviceModel> 

С ASP.NET 2.0 / 3.0 / 3.5 добавьте следующие строки в ваш web.config:

<system.serviceModel> 
     <serviceHostingEnvironment> 
          <baseAddressPrefixFilters> 
               <add prefix="http://www.YourHostedDomainName.com"/> 
          </baseAddressPrefixFilters> 
     </serviceHostingEnvironment> 
</system.serviceModel> 

В моем случае основной причиной этой проблемы было несколько http-привязок, определенных на родительском веб-сайте, т.е. InetMgr-> Sites-> Mysite-> properties-> EditBindings. Я удалил одну http-привязку, которая не требовалась, и проблема была решена.

И в моем случае все было просто: я использовал мастер добавления службы WCF в Visual Studio, который автоматически создавал соответствующие разделы в app.config. Затем я прочитал « Как разместить службу WCF в управляемом приложении» . Проблема была: мне не нужно было указывать URL для запуска веб-сервиса.

Заменить:

using (ServiceHost host = new ServiceHost(typeof(HelloWorldService), baseAddress))

С участием:

using (ServiceHost host = new ServiceHost(typeof(HelloWorldService))

И ошибка ушла.

Общая идея: если вы предоставляете базовый адрес в качестве параметра и указываете его в конфигурации, вы получите эту ошибку. Скорее всего, это не единственный способ получить ошибку, ты.

У меня была эта проблема, и причина была довольно глупой. Я пробовал демонстрацию Microsoft относительно запуска ServiceHost из исполняемого файла командной строки. Я следовал инструкциям, в том числе там, где сказано добавить соответствующий сервис (и интерфейс). Но я получил вышеуказанную ошибку.

Оказывается, когда я добавил класс обслуживания, VS автоматически добавил конфигурацию в app.config. И демо тоже пыталось добавить эту информацию. Так как это было уже в конфиге, я удалил демо-часть, и это сработало.

Я пришел с той же ошибкой на старом сервере Exchange 2010. Служба (служба репликации почтовых ящиков Exchange) выдавала вышеуказанную ошибку, и процесс миграции не может быть продолжен. Ища через интернет, я пришел по этой ссылке, которая указала ниже:

Не удается открыть Exchange GRE при первой установке или при внесении каких-либо изменений в сервер IIS. Он завершается с ошибкой оснастки, и при попытке открыть страницу оснастки отображается следующее содержимое:

This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'."

Причина . Эта ошибка возникает из-за того, что http-порт 443 уже используется другим приложением, а сервер IIS не настроен для обработки нескольких привязок к одному и тому же порту.

Решение . Настройте сервер IIS для обработки привязок нескольких портов. Обратитесь к поставщику (Microsoft), чтобы настроить его.

Поскольку эти услуги предлагались с веб-сервера IIS, проверка привязок на корневом сайте устранила проблему. Кто-то испортил привязки сайтов, определив правила, которые накладывались друг на друга и испортили сервисы.

Исправление правильных привязок решило проблему, в моем случае, и мне не пришлось настраивать Web.Config.