Błąd uruchamiania usługi WCF „Ta kolekcja zawiera już adres ze schematem http”

Zbudowałem aplikację internetową zawierającą umowę serwisową WCF i kontrolkę Silverlight, która wykonuje połączenia z tą usługą WCF. Na moich serwerach programistycznych i testowych działa świetnie.

Po wdrożeniu na naszym serwerze na żywo i uruchomieniu aplikacji otrzymuję wyjątek typu, System.ServiceModel.ServiceActivationExceptionktóry stwierdza, że ​​usługa nie może zostać aktywowana z powodu wyjątku podczas kompilacji. Wyjątkiem jest:

Ta kolekcja zawiera już adres ze schematem http. W tej kolekcji może znajdować się maksymalnie jeden adres na schemat.

Przeczytałem, że ten wyjątek może zostać zgłoszony, jeśli strona internetowa ma więcej niż jeden nagłówek hosta, co jest prawdą na naszym serwerze na żywo. Najwyraźniej usługi WCF hostowane w IIS mogą mieć tylko jeden adres podstawowy. Jak mogę obejść ten problem?

W .Net 4 możesz użyć multipleSiteBindingsEnabledopcji:

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

Wówczas nie będziesz musiał podawać każdego adresu.

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

Podsumowanie,

Rozwiązanie kodu: tutaj

Rozwiązania konfiguracyjne: tutaj

Z pomocą Mike'a Chaliy znalazłem rozwiązania, jak to zrobić za pomocą kodu. Ponieważ problem ten wpłynie prawie na wszystkie projekty, które wdrażamy w środowisku na żywo, wyróżniłem się rozwiązaniem czysto konfiguracyjnym. W końcu znalazłem taki, który szczegółowo opisuje, jak to zrobić w .net 3.0 i .net 3.5.

Poniżej znajduje się przykład zmiany konfiguracji internetowej aplikacji:

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

W powyższym przykładzie net.tcp: //payroll.myorg.com: 8000 i http://shipping.myorg.com:9000 są jedynymi adresami bazowymi dla ich odpowiednich schematów, które będą mogły być przekazywane. BaseAddressPrefixFilter nie obsługuje żadnych symboli wieloznacznych.

Adresy podstawowe dostarczone przez IIS mogą mieć adresy powiązane z innymi schematami nieobecnymi na liście baseAddressPrefixFilter. Te adresy nie zostaną odfiltrowane.

Rozwiązanie Dns (niesprawdzone): Myślę, że jeśli utworzyłeś nowy wpis dns specyficzny dla twojej aplikacji sieciowej, dodałeś nową stronę internetową i podałeś mu jeden nagłówek hosta pasujący do wpisu dns, to byś złagodził ten problem i nie zrobiłby tego muszę napisać niestandardowy kod lub dodać prefiksy do pliku web.config.

Widziałeś to - http://kb.discountasp.net/KB/a799/error-accessing-wcf-service-this-collection-already.aspx

Możesz rozwiązać ten błąd, zmieniając plik web.config.

W programie ASP.NET 4.0 dodaj następujące wiersze do pliku web.config:

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

W programie ASP.NET 2.0 / 3.0 / 3.5 dodaj następujące wiersze do pliku web.config:

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

W moim przypadku główną przyczyną tego problemu było wiele powiązań HTTP zdefiniowanych w nadrzędnej stronie internetowej, tj. InetMgr-> Sites-> Mysite-> properties-> EditBindings. Usunąłem jedno wiązanie http, które nie było wymagane i problem został rozwiązany.

W moim przypadku było to proste: użyłem kreatora „Dodaj usługę WCF” w Visual Studio, który automatycznie utworzył odpowiednie sekcje w app.config. Następnie zacząłem czytać: Jak hostować usługę WCF w aplikacji zarządzanej . Problem polegał na tym: nie musiałem podawać adresu URL, aby uruchomić usługę internetową.

Zastąpić:

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

Z:

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

Błąd zniknął.

Ogólny pomysł: jeśli podasz adres podstawowy jako parametr i określisz go w config, pojawi się ten błąd. Najprawdopodobniej nie jest to jedyny sposób na uzyskanie błędu.

Miałem ten problem, a przyczyna była raczej głupia. Próbowałem wypróbować wersję demonstracyjną Microsoftu dotyczącą uruchamiania ServiceHost z / w wierszu polecenia. Postępowałem zgodnie z instrukcjami, w tym tam, gdzie jest napisane, aby dodać odpowiednią usługę (i interfejs). Ale dostałem powyższy błąd.

Okazuje się, gdy dodałem klasę usług, VS automatycznie dodał konfigurację do app.config. Demo również próbowało dodać te informacje. Ponieważ było już w konfiguracji, usunąłem część demo i zadziałało.

Wystąpił ten sam błąd na starym serwerze Exchange 2010. Usługa (usługa replikacji skrzynki pocztowej Exchange) podawała powyższy błąd i proces migracji nie mógł być kontynuowany. Przeszukując Internet, znalazłem ten link, który stwierdził poniżej:

Exchange GRE nie otwiera się, gdy jest instalowany po raz pierwszy lub w przypadku wprowadzenia jakichkolwiek zmian na serwerze IIS. Błąd kończy się błędem przystawki, a przy próbie otwarcia strony przystawki wyświetlana jest następująca treść:

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'."

Przyczyna : Ten błąd występuje, ponieważ numer portu HTTP 443 jest już używany przez inną aplikację, a serwer IIS nie jest skonfigurowany do obsługi wielokrotnego wiązania z tym samym portem.

Rozwiązanie : Skonfiguruj serwer IIS do obsługi wielu powiązań portów. Skontaktuj się ze sprzedawcą (Microsoft), aby go skonfigurować.

Ponieważ usługi te były oferowane z serwera sieci Web IIS, sprawdzenie powiązań w witrynie głównej rozwiązało problem. Ktoś pomieszał powiązania witryny, definiując zasady, które się nakładały, i pomieszał usługi.

Naprawienie prawidłowych powiązań rozwiązało problem w moim przypadku i nie musiałem konfigurować Web.Config.