Nie można znaleźć domyślnego elementu punktu końcowego

" ten błąd może wystąpić, jeśli wywołujesz usługę w bibliotece klas i wywołujesz bibliotekę klas z innego projektu."

W tym przypadku musisz dołączyć ustawienia konfiguracji ws do aplikacji main projects.config jeśli jest to winapp lub web.config jeśli jest to aplikacja internetowa. To jest sposób, aby przejść nawet z PRISM i WPF / Silverlight.

Rozwiązałem to (myślę, że tak jak inni sugerowali), tworząc instancje adresu wiążącego i końcowego-ponieważ nie chciałem dodawać nowych ustawień do plików konfiguracyjnych(jest to zamiennik dla istniejącego kodu biblioteki, który jest powszechnie używany, a wcześniej używany starszy odnośnik do usług internetowych itp.), a więc chciałem być w stanie Upuścić to bez dodawania nowych ustawień konfiguracyjnych wszędzie.

var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);

using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
    //set timeout
    productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);

    //call web service method
    productResponse = productService.GetProducts();
} 

Edit

Jeśli używasz https, musisz użyj BasicHttpsBinding zamiast BasicHttpBinding.

Miałem ten sam problem. Okazuje się, że dla odniesienia internetowego, musisz podać URL jako pierwszy parametr do konstruktora:

new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");

Aby nawiązać do usługi sieciowej w Nowym Stylu, musisz podać nazwę, która odnosi się do wpisu punktu końcowego w konfiguracji:

new WebService.WebServiceSoapClient("WebServiceEndpoint");

Z odpowiednim wpisem w Web.config lub App.config:

<client>
      <endpoint address="http://myservice.com/moo.aspx"
        binding="basicHttpBinding" 
        bindingConfiguration="WebService"
        contract="WebService.WebServiceSoap"
        name="WebServiceEndpoint" />
    </client>
  </system.serviceModel>

Miałem taką sytuację, gdzie miałem

• WCF service Hosted somewhere
• Główny Projekt
• projekt konsumencki typu 'class Library', który ma odniesienie do usługi WCF
• główne metody wywołania projektu z projektu konsumenckiego

Teraz projekt konsumencki miał wszystkie powiązane ustawienia konfiguracji w tagu <system.serviceModel> mojej aplikacji.config, its nadal rzucał ten sam błąd co powyżej.

Wszystko co zrobiłem to dodanie tego samego znacznika <system.serviceModel> do mojej głównej aplikacja projektu.plik konfiguracyjny, i w końcu byliśmy gotowi.

" ten błąd może wystąpić, jeśli wywołujesz usługę w bibliotece klas i wywołujesz bibliotekę klas z innego projektu."

" w tym przypadku musisz dołączyć ustawienia konfiguracji ws do aplikacji main projects.config jeśli jest to winapp lub web.config jeśli jest to aplikacja internetowa. To jest sposób, aby przejść nawet z PRISM i WPF / Silverlight."

Tak, ale jeśli nie możesz zmienić głównego projektu (na przykład Orchard CMS), możesz zachować konfigurację usługi WCF w swoim projekcie.

Należy utworzyć Service helper z metodą generowania klienta:

public static class ServiceClientHelper
{
    public static T GetClient<T>(string moduleName) where T : IClientChannel
    {
        var channelType = typeof(T);
        var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
        var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;

        if (contractAttribute == null)
            throw new Exception("contractAttribute not configured");

        //path to your lib app.config (mark as "Copy Always" in properties)
        var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName)); 

        var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
        var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);

        if (serviceModelSectionGroup == null)
            throw new Exception("serviceModelSectionGroup not configured");

        var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
        var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
        var client = channelFactory.CreateChannel();
        return client;
    }
}

I użyj go:

using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
                ... get data from service ...
            }

Zobacz szczegóły w ten artykuł .

To doprowadzało mnie do szału.

Kiedy wywołuję usługę WCF w module Prism, dostaję ten sam błąd:

Nie można znaleźć domyślnego elementu końcowego, który odwołuje się do umowy "IMyService" w sekcji Konfiguracja klienta modelu usługi. To możliwe, że nie znaleziono pliku konfiguracyjnego dla Twojej aplikacji lub ponieważ nie znaleziono elementu punktu końcowego pasującego do tego kontraktu u klienta element

Okazuje się, że wygląda w skorupie .plik xap dla usługi.Plik ClientConfig, a nie w serwisie modułu.Plik ClientConfig. Dodałem mój punkt końcowy i wiązanie do istniejącego serwisu.Plik ClientConfig w mojej aplikacji Silverlight Shell (nazywa to własnymi usługami WCF).

Potem musiałem przebudować aplikację Shell, aby wygenerować nową.plik xap dla folderu ClientBin mojego projektu internetowego.

Teraz ta linijka kodu w końcu działa:

MyServiceClient myService = new MyServiceClient();

Otrzymałem ten błąd w ASP.NET aplikacja, w której usługa WCF została dodana do biblioteki klas, która jest dodawana do ASP.NET aplikacja jako odniesienie .plik dll w folderze bin. Aby rozwiązać ten błąd, ustawienia konfiguracyjne w aplikacji.plik konfiguracyjny biblioteki klas odwołujący się do usługi WCF musiał zostać skopiowany do sieci.ustawienia config dla ASP.NET strona / aplikacja.

Znalazłem (jak również kopiowanie do aplikacji klienta UI.config jak używałem interfejsu biblioteki klas) musiałem przedrostek nazwy powiązania z nazwą referencji usługi(Mój to ServiceReference poniżej).

Np.:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ServiceReference.ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

Zamiast domyślnie wygenerowanego:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

Miałem ten sam problem, ale zmiana przestrzeni nazw umowy nie zadziałała. Więc próbowałem. Net 2 Style Web reference zamiast. Net 3.5 Service reference. Zadziałało.

Aby użyć odniesienia internetowego w Visual Studio 2008, kliknij "Dodaj odniesienie do usługi", a następnie kliknij "Zaawansowane", gdy pojawi się okno dialogowe. W tym znajdziesz opcję, która pozwoli Ci użyć odniesienia internetowego zamiast odniesienia do usługi.

Kilka odpowiedzi tutaj trafić na poprawne rozwiązanie, gdy masz do czynienia z umysłowo numberingly niejasny błąd odniesienia usługi z pliku klasy: skopiuj informacje Config Service do aplikacji.config web.konfiguracja konsoli lub aplikacji windows. Żadna z tych odpowiedzi nie pokazuje jednak, co należy skopiować. Spróbujmy to poprawić.

Oto, co skopiowałem z pliku konfiguracyjnego mojej biblioteki klasowej do pliku konfiguracyjnego mojej aplikacji konsoli, aby ominąć ten szalony błąd dla usługi I napisz o nazwie "TranslationServiceOutbound".

W zasadzie chcesz wszystko wewnątrz systemu.serviceModel sekcja:

  <system.serviceModel>
<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpBinding_ITranslationServiceOutbound" />
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
    contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>

Testowanie jednostkowe aplikacji nie-bibliotecznej, która zużywa usługę, może spowodować ten problem.

Informacje, które wprowadzili inni, odnoszą się do głównej przyczyny tego. Jeśli próbujesz napisać zautomatyzowane przypadki testowe, a testowana Jednostka faktycznie wywoła interfejs usługi, musisz dodać odniesienie do usługi do projektu testowego. To jest smak aplikacji wykorzystującej błąd typu library. Nie zdawałem sobie z tego sprawy, ponieważ mój kod, który zużywa interfejs nie jest w bibliotece . Jednakże, gdy test faktycznie zostanie uruchomiony, będzie on uruchamiany z zespołu testowego, a nie testowanego zespołu.

Dodanie referencji serwisowej do projektu testów jednostkowych rozwiązało mój problem.

Mam sytuację, która w teście jednostkowym. Skopiowałem aplikację.plik konfiguracyjny do projektu testów jednostkowych. Tak więc projekt testów jednostkowych zawiera również informacje o punkcie końcowym.

Raz spotkałem się z tym problemem. To dlatego, że wciąż rozwijałem interfejs, który korzysta z usługi WCF. Skonfigurowałem aplikację testową i kontynuowałem rozwój. Następnie w trakcie rozwoju zmieniłem niektóre przestrzenie nazw usług. Więc dwukrotnie sprawdziłem " system.serviceModel -> client -> endpoint - > contract" w sieci.config pasujący do klasy WCF. Więc problem jest rozwiązany.

Przestrzeń nazw w konfiguracji powinna odzwierciedlać resztę ścieżki przestrzeni nazw po domyślnej przestrzeni nazw klienta (skonfigurowanej we właściwościach projektu). Bazując na Twojej opublikowanej odpowiedzi, domyślam się, że twój Klient jest skonfigurowany tak, aby był w "Fusion.DataExchange.Workflows " przestrzeń nazw. Jeśli kod klienta został przeniesiony do innej przestrzeni nazw, musisz zaktualizować konfigurację, aby pasowała do pozostałej ścieżki przestrzeni nazw.

Tylko dla każdego innego z tym samym problemem; napisałem test jednostkowy dla mojej metody, która próbowała połączyć się z moim serwisem. Za każdym razem zawodziło z tym samym wyjątkiem - nie mam pojęcia dlaczego. Kiedy uruchomiłem go z winform działa dobrze.

Mam ten sam Problem.Używam usługi WCF w bibliotece klas i wywołuję bibliotekę klas z projektu aplikacji windows.ale zapomniałem zmienić <system.serviceModel> w pliku konfiguracyjnym projektu aplikacji windows tak samo jak <system.serviceModel> aplikacji klasy Library.Plik konfiguracyjny.
rozwiązanie: zmiana konfiguracji zewnętrznego projektu tak samo jak konfiguracja wcf biblioteki klas.

Jeśli odwołujesz się do usługi internetowej w swojej bibliotece klas, musisz skopiować aplikację.config do aplikacji windows lub aplikacji konsolowej

Rozwiązanie: zmiana konfiguracji zewnętrznego projektu tak samo jak konfiguracja wcf biblioteki klas.

Pracował dla mnie

Witam napotkałem ten sam problem, ale najlepszym rozwiązaniem jest pozwolić. NET skonfigurować konfigurację po stronie klienta. Odkrywam to, gdy dodaję odniesienie do usługi z ciągiem zapytań http:/namespace/service.svc?wsdl = wsdl0 nie tworzy punktów końcowych konfiguracji po stronie klienta. Ale kiedy zdejmę ?wsdl-wsdl0 i używać tylko url http:/namespace/service.svc, tworzy konfigurację punktu końcowego w pliku konfiguracyjnym klienta. w skrócie remoe " ?WSDL = WSDL0".

Nie umieszczaj linii deklaracji klienta usługi jako pola klasy, zamiast tego utwórz instancję przy każdej metodzie, w której została użyta. Więc problem zostanie rozwiązany. Jeśli utworzysz instancję klienta usługi jako pole klasy, wystąpi błąd czasu projektowania !

W przypadku, gdy używasz aplikacji WPF wykorzystującej Framework PRISM, konfiguracja powinna istnieć w Twoim projekcie startowym (tj. w projekcie, w którym znajduje się twój bootstrapper.)

Ten błąd może wystąpić, jeśli wywołujesz usługę w bibliotece klas i wywołujesz bibliotekę klas z innego projektu.

Wydaje się, że istnieje kilka sposobów na stworzenie/naprawienie tego problemu. Dla mnie, produkt CRM używam został napisany w kodzie macierzystym i jest w stanie wywołać mój.Net dll, ale uruchamiam się informacje konfiguracyjne muszą być w/powyżej głównej aplikacji. Dla mnie aplikacja CRM nie jest. NET, więc skończyło się na tym, że musiałem umieścić go w mojej maszynie.plik konfiguracyjny (nie tam gdzie chcę). Ponadto, ponieważ moja firma korzysta z Websense, trudno było mi nawet dodać odniesienie do Usługi ze względu na uwierzytelnianie Proxy 407 Wymagany problem, który wymagał modyfikacji maszyny.cong.

Rozwiązanie Proxy:

Aby uzyskać odniesienie do usługi WCF do pracy musiałem skopiować informacje z aplikacji.config mojego DLL do głównej aplikacji config (ale dla mnie to była maszyna.config). Musiałem też skopiować informacje o punkcie końcowym do tego samego pliku. Kiedy już to zrobiłem, zacząłem pracować dla mnie.

Ok. Mój przypadek był trochę inny, ale w końcu znalazłem rozwiązanie dla niego: Mam konsolę.EXE -> DLL -> wywołanie WS1 -> DLL - > wywołanie WS2

Miałem zarówno konfiguracje modelu serwisowego WS1, jak i WS2 w konsoli.EXE.config zgodnie z zaleceniami. - nie rozwiązałem problemu.

Ale nadal nie działa, dopóki nie dodałem WebReference WS2 do WS1 również i nie tylko do DLL, który faktycznie tworzy i wywołuje proxy WS2.

Miałem ten sam problem
Korzystałem z aplikacji desktopowej i usługi Global Weather Web service

Usunąłem odnośnik serwisu i dodałem odnośnik WWW i problem rozwiązany Dzięki

Rozwiązaniem dla mnie było usunięcie nazwy punktu końcowego z atrybutu Endpoint Name w sieci klienta.config to pozwoliło proxy używać

ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");

Pozwól, że dodam jeszcze jedną rzecz, której poszukam. (odpowiedź Toma Haigh ' a już do niej nawiązuje, ale chcę być jednoznaczny)

Mój plik web.config miał następującą definicję:

<protocolMapping>
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Używałem już basicHttpsBinding dla jednego odniesienia, ale potem Dodałem nowe odniesienie, które wymagało basicHttpBinding (no s). Wystarczyło dodać to do mojego protocolMapping w następujący sposób:

<protocolMapping>
    <add binding="basicHttpBinding" scheme="http" />
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Jak słusznie wskazuje L. R. , należy to zdefiniować we właściwych miejscach. Na ja, to znaczy jeden w aplikacji mojego projektu testów jednostkowych.config, jak również jeden w sieci projektu głównego serwisu.config.

Miałem ten błąd, gdy odwoływałem się do Umowy w elemencie pliku konfiguracyjnego bez operatora globalnego zakresu.

Tzn.

<endpoint contract="global::MyNamepsace.IMyContract" .../>

Działa, ale

<endpoint contract="MyNamepsace.IMyContract" .../>

Wyświetla błąd "nie można znaleźć domyślnego elementu końcowego, który odwołuje się do umowy".

Zespół zawierający MyNamepsace.IMyContract jest w innym złożeniu niż główna aplikacja, więc może to wyjaśniać potrzebę zastosowania globalnej rozdzielczości zakresu.

Dostałem ten sam błąd i próbowałem kilku rzeczy, ale nie zadziałało, niż zauważyłem, że mój "kontrakt" nie był taki sam dla całych projektów, zmieniłem kontrakt, jak będzie taki sam dla wszystkich projektów wewnątrz rozwiązania i niż to działało. To jest projekt a

<client>
    <endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>

Projekt B:

<client>
    <endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>

W końcu zmieniłem dla obu jako:

<client>
    <endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>

Podczas dodawania referencji serwisowej

Uwaga na Przestrzeń nazw w której wpisujesz:

Należy dołączyć go do nazwy interfejsu:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" 
            contract="MyNamespace.IMySOAPWebService" />
</client>