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

Dodałem serwer proxy do usługi internetowej do rozwiązania VS2008 / .NET 3.5. Podczas konstruowania klienta .NET zgłasza ten błąd:

Nie można znaleźć domyślnego elementu punktu końcowego, który odwołuje się do kontraktu „IMySOAPWebService” w sekcji konfiguracji klienta ServiceModel. Może to być spowodowane tym, że nie znaleziono pliku konfiguracji dla Twojej aplikacji lub dlatego, że element klienta pasujący do tej umowy nie został znaleziony.

Wyszukanie tego błędu każe mi użyć pełnej przestrzeni nazw w umowie. Oto moja app.config z pełną przestrzenią nazw:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
            contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>

Korzystam z XP lokalnego (wspominam o tym, ponieważ wiele hitów Google wspomina o win2k3) Plik app.config jest kopiowany do pliku app.exe.config, więc nie stanowi to również problemu.

Jakieś wskazówki?

„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 takim przypadku musisz włączyć ustawienia konfiguracji WS do głównego projektu app.config, jeśli jest to aplikacja winapp lub web.config, jeśli jest to aplikacja internetowa. W ten sposób można przejść nawet z PRISM i WPF / Silverlight.

Rozwiązałem to (myślę, jak sugerują inni), samodzielnie tworząc instancje powiązania i adresu końcowego - ponieważ nie chciałem dodawać nowych ustawień do plików konfiguracyjnych (jest to zamiennik istniejącego kodu biblioteki, który jest szeroko stosowany, i poprzednio korzystałem ze starszego odwołania do usługi sieci Web itp.), więc chciałem móc to wprowadzić bez konieczności dodawania wszędzie nowych ustawień konfiguracji.

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();
} 

Edytować

Jeśli używasz protokołu https, musisz użyć BasicHttpsBindingzamiast BasicHttpBinding.

Po przetestowaniu kilku opcji w końcu rozwiązałem to za pomocą

umowa = "IMySOAPWebService"

tzn. bez pełnej przestrzeni nazw w konfiguracji. Z jakiegoś powodu pełna nazwa nie została poprawnie rozwiązana

Miałem ten sam problem. Okazuje się, że dla REFERENCJI internetowej musisz podać konstruktorowi adres URL jako pierwszy parametr:

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

W przypadku nowego stylu ODNIESIENIE SERWISOWE, musisz podać nazwę, która odnosi się do pozycji punktu końcowego w konfiguracji:

new WebService.WebServiceSoapClient("WebServiceEndpoint");

Z odpowiednim wpisem Web.configlub App.config:

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

Cholernie trudno jest usunąć wizję tunelu z „działało w starszym programie” ...

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

• Usługa WCF Gdzieś hostowana
• Główny projekt
• Projekt konsumencki typu „Biblioteka klas”, który ma odniesienie do usługi do usługi WCF
• Główny projekt wywołuje metody z projektu konsumenckiego

Teraz projekt Consumer miał wszystkie powiązane ustawienia konfiguracji w <system.serviceModel>tagu mojego app.config, nadal zgłaszał ten sam błąd co powyżej.

Wszystko, co zrobiłem, to dodanie tego samego znacznika <system.serviceModel>do pliku app.config mojego głównego projektu, i wreszcie mogliśmy zacząć.

Prawdziwym problemem, o ile w moim przypadku, był odczyt niewłaściwego pliku konfiguracyjnego. Zamiast app.config konsumenta odnosił się on do konfiguracji głównego proj. Zrozumienie tego zajęło mi dwie godziny.

„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 takim przypadku konieczne będzie włączenie ustawień konfiguracji WS do głównego projektu app.config, jeśli jest to aplikacja win. 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.

Musisz utworzyć pomocnika usługi za pomocą metody 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 tym artykule .

Kilka odpowiedzi tutaj trafiło na właściwe rozwiązanie, gdy napotykasz przytłaczająco niejasny błąd odwoływania się do usługi z pliku klasy: skopiuj informacje o konfiguracji usługi do app.config web.config konsoli lub aplikacji Windows. Jednak żadna z tych odpowiedzi nie pokazuje, co skopiować. Spróbujmy to naprawić.

Oto, co skopiowałem z pliku konfiguracyjnego biblioteki klas do pliku konfiguracyjnego mojej aplikacji konsolowej, aby obejść ten zwariowany błąd dla usługi, którą piszę o nazwie „TranslationServiceOutbound”.

Zasadniczo chcesz wszystko w sekcji system.serviceModel :

  <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>

Ten doprowadził mnie do szału.

Używam Silverlight 3 Prism (CAB) z WCF

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

Nie można znaleźć domyślnego elementu punktu końcowego, który odwołuje się do kontraktu „IMyService” w sekcji konfiguracji klienta modelu usługi. Może to być spowodowane tym, że nie znaleziono pliku konfiguracji dla Twojej aplikacji lub ponieważ element klienta pasujący do tej umowy nie został znaleziony w elemencie klienta

Okazuje się, że szuka w pliku .xap powłoki pliku ServiceReferences.ClientConfig, a nie w pliku ServiceReferences.ClientConfig modułu. Dodałem mój punkt końcowy i powiązanie do istniejącego pliku ServiceReferences.ClientConfig w mojej aplikacji Silverlight Shell (nazywa to swoją własną usługą WCF).

Następnie musiałem przebudować aplikację Shell, aby wygenerować nowy plik .xap dla folderu ClientBin mojego projektu internetowego.

Teraz ten wiersz kodu w końcu działa:

MyServiceClient myService = new MyServiceClient();

Ten błąd pojawiał się w aplikacji ASP.NET, w której usługa WCF została dodana do biblioteki klas, która jest dodawana do aplikacji ASP.NET jako odnośny plik .dll w folderze bin. Aby rozwiązać błąd, ustawienia konfiguracji w pliku app.config w bibliotece klas odwołującej się do usługi WCF musiały zostać skopiowane do ustawień web.config dla strony / aplikacji ASP.NET.

Znalazłem (oprócz kopiowania do App.config interfejsu użytkownika, ponieważ korzystałem z interfejsu biblioteki klas) musiałem poprzedzić nazwę powiązania nazwą Service Reference (moja jest ServiceReferenceponiżej).

na przykład:

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

zamiast domyślnie generowanego:

<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 kontraktu nie działała dla mnie. Wypróbowałem więc odwołanie do sieci w stylu .Net 2 zamiast odwołania do usługi .Net 3.5. To się udało.

Aby użyć odwołania do sieci w Visual Studio 2008, kliknij „Dodaj odwołanie do usługi”, a następnie „Zaawansowane”, gdy pojawi się okno dialogowe. W tym znajdziesz opcję, która pozwoli ci użyć odwołania do strony internetowej zamiast odwołania do usługi.

Przyczyną tego problemu może być testowanie przez aplikację niebiblioteczną aplikacji korzystającej z usługi.

Informacje, które wprowadzili inni, dotyczą pierwotnej przyczyny tego. Jeśli próbujesz napisać zautomatyzowane przypadki testowe, a testowana jednostka faktycznie wywoła interfejs usługi, musisz dodać odwołanie do usługi do projektu testowego. Jest to smak aplikacji wykorzystującej błąd typu biblioteki. Jednak nie od razu zdałem sobie z tego sprawę, ponieważ mojego kodu używającego interfejsu nie ma w bibliotece . Jednak gdy test faktycznie się uruchomi, będzie on działał z zestawu testowego, a nie z testowanego zestawu.

Dodanie odwołania do usługi do projektu testu jednostkowego rozwiązało mój problem.

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

Raz spotkałem się z tym problemem. Stało się tak, ponieważ wciąż rozwijałem interfejs korzystający z usługi WCF. Skonfigurowałem aplikację testową i kontynuowałem rozwój. Następnie w trakcie projektowania zmieniłem niektóre przestrzenie nazw usług. Więc dwukrotnie sprawdziłem „system.serviceModel -> klient -> punkt końcowy -> kontrakt” w web.config, aby dopasować klasę WCF. Następnie problem został 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). Na podstawie opublikowanej odpowiedzi domyślam się, że klient jest skonfigurowany w przestrzeni nazw „Fusion.DataExchange.Workflows”. Jeśli przeniesiesz kod klienta do innej przestrzeni nazw, musisz zaktualizować konfigurację, aby pasowała do pozostałej ścieżki przestrzeni nazw.

Mam ten sam problem. Korzystam z usługi WCF w bibliotece klas i wywołuję bibliotekę klas z projektu aplikacji systemu Windows. Ale zapomniałem o zmianie w <system.serviceModel>pliku <system.serviceModel>konfiguracyjnym aplikacji systemu Windows. Projektuj tak samo jak plik aplikacji.Config biblioteki klas.
rozwiązanie: zmień Konfiguracja projektu zewnętrznego tak samo jak konfiguracja wcf biblioteki klas.

Cześć, napotkałem ten sam problem, ale najlepszym rozwiązaniem jest pozwolenie .NET na skonfigurowanie konfiguracji po stronie klienta. Odkryłem to, że po dodaniu odwołania do usługi z ciągiem zapytania http: /namespace/service.svc? Wsdl = wsdl0 NIE tworzy punktów końcowych konfiguracji po stronie klienta. Ale gdy usunę? Wsdl-wsdl0 i użyję tylko adresu URL http: /namespace/service.svc, utworzy konfigurację punktu końcowego w pliku konfiguracyjnym klienta. krótko mówiąc „? WSDL = WSDL0”.

Nie umieszczaj wiersza deklaracji klienta usługi jako pola klasy, zamiast tego utwórz instancję dla każdej metody, która została użyta. Problem zostanie naprawiony. Jeśli utworzysz instancję klienta usługi jako pole klasy, wystąpi błąd czasu projektowania!

W przypadku korzystania z aplikacji WPF za pomocą frameworka PRISM konfiguracja powinna istnieć w projekcie startowym (tj. W projekcie, w którym znajduje się 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 / rozwiązanie tego problemu. Dla mnie produkt CRM, którego używam, został napisany w natywnym kodzie i jest w stanie wywołać moją bibliotekę DLL .NET, ale natrafiam na informacje o konfiguracji, które muszą znajdować się w głównej aplikacji / powyżej niej. Dla mnie aplikacja CRM nie jest .NET, więc musiałem umieścić ją w moim pliku machine.config (nie tam, gdzie chcę). Ponadto, ponieważ moja firma korzysta z Websense, miałem trudności z dodaniem numeru referencyjnego usługi z powodu problemu z wymaganiem uwierzytelnienia serwera proxy 407, który wymagał modyfikacji pliku machine.cong.

Rozwiązanie proxy:

Aby uruchomić WCF Service Reference, musiałem skopiować informacje z app.config mojej biblioteki DLL do głównej konfiguracji aplikacji (ale dla mnie było to machine.config). Musiałem też skopiować informacje o punkcie końcowym do tego samego pliku. Kiedy to zrobiłem, zaczęło to działać dla mnie.

Ok. Moja sprawa była trochę inna, ale w końcu znalazłem naprawę: Mam Console.EXE -> DLL -> Wywoływanie WS1 -> DLL -> Wywoływanie WS2

Mam obie konfiguracje modelu usługi WS1 i WS2 w Console.EXE.config zgodnie z zaleceniami. - nie rozwiązałem problemu.

Ale nadal nie działało, dopóki nie dodałem WebReference WS2 do WS1, a nie tylko do biblioteki DLL, która faktycznie tworzy i wywołuje proxy WS2.

Jeśli odwołujesz się do usługi sieci Web w bibliotece klas, musisz skopiować plik app.config do aplikacji systemu Windows lub aplikacji konsoli

rozwiązanie: zmień Konfiguracja projektu zewnętrznego tak samo jak konfiguracja wcf biblioteki klas.

Pracował dla mnie

Miałem ten sam problem
którego używałem aplikacji komputerowej i korzystałem z usługi Global Weather Web

Usunąłem odwołanie do usługi i dodałem odwołanie do sieci, a problem rozwiązany Dzięki

Rozwiązaniem było dla mnie usunięcie nazwy punktu końcowego z atrybutu Nazwa punktu końcowego w kliencie web.config, co pozwoliło na użycie proxy

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

ćwiczyłem tylko cały dzień. Również nazwa kontraktu była nieprawidłowa po wprowadzeniu tej poprawki, chociaż była błędna, gdy pojawił się błąd początkowy. Dwukrotnie, a następnie potrójnie sprawdź, czy ludzie zawierają nazwy kontraktów !! atrybut: Ian

Pozwól mi dodać jeszcze jedną rzecz do wyszukania. ( Tom Haigh's już do niej nawiązuje, ale chcę być wyraźna)

Mój web.configplik ma następujące definicje:

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

Już korzystałem z basicHttpsBinding dla jednego odwołania, ale potem dodałem nowe odwołanie, które wymagało basicHttpBinding (brak s). Wszystko, co musiałem zrobić, to dodać to do mojego protocolMappingw następujący sposób:

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

Jak słusznie zauważa LR , należy to określić we właściwych miejscach. Dla mnie oznaczało to jeden w app.config mojego projektu testu jednostkowego, a także w web.config głównego projektu usługowego.

Wystąpił ten błąd, gdy odwoływałem się do kontraktu w elemencie pliku konfiguracyjnego bez operatora zasięgu globalnego.

to znaczy

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

działa, ale

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

daje błąd „Nie można znaleźć domyślnego elementu końcowego, który odwołuje się do umowy”.

Zespół zawierający MyNamepsace.IMyContract znajduje się w innym zestawie niż główna aplikacja, więc może to wyjaśniać potrzebę użycia globalnej rozdzielczości zakresu.

Podczas dodawania odwołania do usługi

uważaj na przestrzeń nazw, którą wpisujesz:

Powinieneś dołączyć go do nazwy swojego interfejsu:

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

Wystąpił ten sam błąd i próbowałem wielu rzeczy, ale nie zadziałało, ale zauważyłem, że moja „umowa” nie była taka sama we wszystkich projektach, zmieniłem umowę tak, jak by była taka sama dla wszystkich projektów wewnątrz rozwiązania i działała. 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, ponieważ:

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

Miałem ten sam problem i został rozwiązany tylko wtedy, gdy aplikacja hosta i dll, który używał tego punktu końcowego, miały tę samą nazwę odwołania do usługi.