Usługa ma zerowe punkty końcowe aplikacji (niezwiązane z infrastrukturą)

Niedawno utworzyłem usługę WCF (dll) i hosta usługi (exe). Wiem, że moja usługa WCF działa poprawnie, ponieważ mogę pomyślnie dodać usługę do WcfTestClient.

Jednak wydaje mi się, że napotykam problem, gdy przychodzę do wykorzystania mojego programu WCF z hosta usługi (exe). Mogę dodać odwołanie do WCF (dll) do mojego hosta usługi (exe) i utworzyć niezbędne składniki w exe; takich jak instalator usługi, host usługi i plik app.config, skompiluj, a następnie zainstaluj plik exe przy użyciu InstallUtil. Ale kiedy próbowałem uruchomić usługę w konsoli Microsoft Management Console, usługa natychmiast zatrzymuje się po uruchomieniu.

Zacząłem więc badać, co dokładnie może być przyczyną tego problemu i wymyśliłem ten błąd z dziennika aplikacji w Podglądzie zdarzeń.

Opis:

Nie można uruchomić usługi. System.InvalidOperationException: Usługa „Usługa” ma zerowe punkty końcowe aplikacji (niezwiązane z infrastrukturą). Może to być spowodowane tym, że nie znaleziono pliku konfiguracyjnego dla Twojej aplikacji lub nie można znaleźć elementu usługi pasującego do nazwy usługi w pliku konfiguracyjnym lub ponieważ w elemencie usługi nie zdefiniowano żadnych punktów końcowych.

Ten błąd jest faktycznie generowany w OnStart; mojego exe, kiedy wykonuję tę rozmowę ServiceHost.Open(). Widziałem wiele postów, w których inne osoby napotkały ten problem, jednak większość z nich, jeśli nie wszystkie, twierdzi, że nazwa usługi lub umowa; przestrzeń nazw i nazwa klasy, nie są określane. Sprawdziłem oba te wpisy w moim pliku konfiguracyjnym; zarówno w exe, jak iw dll, i idealnie do siebie pasują. Miałem inne osoby w biurze, które podwójnie sprawdzały za mną, aby upewnić się, że w pewnym momencie nie oślepłem, ale oczywiście doszli do tego samego wniosku, co ja, że ​​wszystko wyglądało tak, jakby zostało określone poprawnie. Jestem naprawdę zagubiony, jeśli chodzi o to, co się dzieje w tym momencie. Czy ktoś mógłby mi pomóc w tej sprawie?

Inną możliwą przyczyną może być to, że plik app.config nigdy nie jest odczytywany; przynajmniej nie ten, który moim zdaniem powinien być czytany. Czy to może być problem? Jeśli tak, jak mogę rozwiązać ten problem. Znowu KAŻDA pomoc byłaby doceniona.

Właśnie miałem ten problem i rozwiązałem go dodając przestrzeń nazw do nazwy usługi np

 <service name="TechResponse">

stał się

 <service name="SvcClient.TechResponse">

Widziałem również, że rozwiązano to za pomocą Web.config zamiast App.config.

Punkt końcowy powinien również mieć przestrzeń nazw:

 <endpoint address="uri" binding="wsHttpBinding" contract="Namespace.Interface" />

Jedną rzeczą do przemyślenia jest: czy masz całkowicie odłączone WCF od usługi WindowsService (WS)? WS jest bolesne, ponieważ nie masz nad nimi kontroli ani widoczności. Próbuję to złagodzić, umieszczając wszystkie moje rzeczy spoza WS we własnych klasach, aby można je było testować niezależnie od hosta WS. Takie podejście może pomóc w wyeliminowaniu wszystkiego, co dzieje się ze środowiskiem wykonawczym WS, a w szczególności z usługą.

Jan prawdopodobnie ma rację, że jest to problem z plikiem .config. Usługa WCF zawsze będzie szukać kontekstu wykonania .config . Jeśli więc hostujesz program WCF w różnych kontekstach wykonywania (czyli testujesz za pomocą aplikacji konsolowej i wdrażasz za pomocą WS), musisz upewnić się, że dane konfiguracji WCF zostały przeniesione do odpowiedniego pliku .config. Ale podstawową kwestią dla mnie jest to, że nie wiesz, w czym jest problem, ponieważ szlam WS przeszkadza. Jeśli nie dokonałeś jeszcze refaktoryzacji, aby móc uruchomić swoją usługę w dowolnym kontekście (to jest test jednostkowy lub konsola), zasugerowałbym to zrobić. Jeśli uruchomisz usługę w teście jednostkowym, prawdopodobnie zakończy się niepowodzeniem w taki sam sposób, jak w przypadku WS, który jest znacznie łatwiejszy do debugowania niż próba zrobienia tego z obrzydliwą hydrauliką WS.

Po prostu skopiuj plik App.config z projektu usługi do aplikacji hosta konsoli i wklej tutaj, a następnie usuń go z projektu usługi.

Dostałem bardziej szczegółowy wyjątek, gdy dodałem go programowo - AddServiceEndpoint:

string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));  

host.AddServiceEndpoint(typeof(MyNamespace.IService),
                        new BasicHttpBinding(), baseAddress);
host.Open();

Przygotowanie konfiguracji dla WCF jest trudne, a czasami definicja typu usługi pozostaje niezauważona.

Napisałem tylko przestrzeń nazw w tagu serwisowym, więc otrzymałem ten sam błąd.

<service name="ServiceNameSpace">

Nie zapominaj, że numer seryjny wymaga w pełni kwalifikowanej nazwy klasy usług.

<service name="ServiceNameSpace.ServiceClass">

Dla innych ludzi, którzy są tacy jak ja.

Dzisiaj wpadłem na ten sam problem, zamieszczając tutaj mój błąd i poprawiając go tak, aby mógł komuś pomóc.

Podczas zmiany struktury kodu w rzeczywistości zmieniłem nazwy klasy usług i IService oraz zmieniłem ServiceHost tak, aby wskazywał na tę nową nazwę klasy usługi (jak pokazano we fragmencie kodu), ale w moich aplikacjach hosta plik App.Config nadal używałem starej nazwy klasy usługi . (zobacz pole nazwy sekcji konfiguracji w poniższym fragmencie)

Oto fragment kodu,

 ServiceHost myServiceHost = new ServiceHost(typeof(NewServiceClassName)); 

aw pliku App.config w sekcji services odnosiłem się do starej nazwy klasy usług, zmieniając ją na New ServiceClassName, który rozwiązał problem.

  <service name="ProjectName.OldServiceClassName"> 
        <endpoint address="" binding="basicHttpBinding" contract="ProjectName.IService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        <host>
          <baseAddresses>
            <add baseAddress=""/>
          </baseAddresses>
        </host>
      </service>

Miałem ten sam problem. Wszystko działa w VS2010, ale kiedy uruchamiam ten sam projekt w VS2008, pojawia się wspomniany wyjątek.

To, co zrobiłem w moim projekcie VS2008, aby to działało, to dodanie wywołania do elementu AddServiceEndpointczłonkowskiego mojego obiektu ServiceHost.

Oto mój fragment kodu:

Uri baseAddress = new Uri("http://localhost:8195/v2/SystemCallbackListener");

ServiceHost host = new ServiceHost(typeof(SystemCallbackListenerImpl), baseAddress);

host.AddServiceEndpoint(typeof(CsfServiceReference.SystemCallbackListener),
                        new BasicHttpBinding(),
                        baseAddress);
host.Open();

Nie modyfikowałem pliku app.config. Ale myślę, że punkt końcowy usługi mógł również zostać dodany w pliku .config.

Właśnie rozwiązałem ten problem w mojej usłudze. Oto błąd, który otrzymałem:

Usługa „EmailSender.Wcf.EmailService” nie ma żadnych punktów końcowych aplikacji (niezwiązanych z infrastrukturą). Może to być spowodowane tym, że nie znaleziono pliku konfiguracyjnego dla Twojej aplikacji, nie znaleziono elementu usługi pasującego do nazwy usługi w pliku konfiguracyjnym lub nie zdefiniowano punktów końcowych w elemencie usługi.

Oto dwa kroki, które zastosowałem, aby to naprawić:

1. Użyj poprawnej w pełni kwalifikowanej nazwy klasy:

   <service behaviorConfiguration="DefaultBehavior" name="EmailSender.Wcf.EmailService">
   

2. Włącz punkt końcowy za pomocą mexHttpBinding, a co najważniejsze, użyj kontraktu IMetadataExchange:

   <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
   

Ten błąd wystąpi, jeśli plik konfiguracji aplikacji obsługującej usługę WCF nie ma odpowiedniej konfiguracji.

Zapamiętaj ten komentarz z konfiguracji:

Podczas wdrażania projektu biblioteki usług zawartość pliku konfiguracyjnego należy dodać do pliku app.config hosta. System.Configuration nie obsługuje plików konfiguracyjnych dla bibliotek.

Jeśli masz usługę WCF hostowaną w usługach IIS, w czasie wykonywania za pośrednictwem VS.NET odczyta plik app.config projektu biblioteki usług, ale po wdrożeniu odczyta plik web.config hosta. Jeśli web.config nie ma identycznej <system.serviceModel>konfiguracji, pojawi się ten błąd. Pamiętaj, aby skopiować konfigurację z app.config po jej dopracowaniu.

Właśnie natknąłem się na ten problem i sprawdziłem wszystkie powyższe odpowiedzi, aby upewnić się, że nie przegapiłem niczego oczywistego. Cóż, miałem pół-oczywisty problem. Moja wielkość nazwy klasy w kodzie i nazwa klasy, której użyłem w pliku konfiguracyjnym, nie pasowały.

Na przykład: jeśli nazwa klasy to CalculatorService, a plik konfiguracyjny odnosi się do Calculatorservice ... pojawi się ten błąd.

Uruchomiłem program Visual Studio w trybie administratora i u mnie zadziałało :) Ponadto upewnij się, że plik app.config, którego używasz do pisania konfiguracji WCF, musi znajdować się w projekcie, w którym jest używana klasa „ServiceHost”, a nie w rzeczywistej usłudze WCF projekt.

Mój problem polegał na zmianie nazwy mojej domyślnej klasy Service1 dla pliku .svc na bardziej zrozumiałą nazwę, co spowodowało, że konfiguracja behawioralna web.config i punkt końcowy odpowiadały starej konwencji nazewnictwa. Spróbuj naprawić plik web.config.

Jedną z kluczowych rzeczy do zapamiętania dla osób pracujących z aplikacją konsoli do hostowania usługi WCF jest to, że plik Web.config w projekcie WCF jest całkowicie ignorowany. Jeśli twoja system.serviceModelkonfiguracja jest tam, musisz przenieść tę sekcję config do pliku App.config projektu konsoli.

Jest to dodatek do odpowiedzi dotyczących upewnienia się, że przestrzeń nazw jest określona we właściwych miejscach.

Jako kolejna wskazówka, to rzeczywiście rozwiązało ten problem w moim przypadku.

Migrację niektórych usług WCF z aplikacji konsoli (która konfiguruje w kodzie kilka usług WCF) do Azure WebRole, aby opublikować je na platformie Azure. Za każdym razem, gdy dodaję nową usługę, VS edytuje mój plik web.config i dodaje ten wiersz:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">

Cóż, przy wszystkich poradach i odpowiedziach powyżej nie mogłem sprawić, by działało, dopóki nie usunąłem wszystkich atrybutów z elementu serviceHostingEnvironment. Jak widać, nie jestem gwiazdą WCF, ale udało mi się współpracować z pierwszą usługą, konfigurując ją jako:

<service name="FirstService" behaviorConfiguration="metadataBehavior">
                <endpoint address=""
                 binding="wsHttpBinding"
                 bindingConfiguration="WSHttpBinding_WcfServicesBinding"
                 contract="IFirstService" />

            </service>

ale kiedy dodałem drugą usługę, przestała działać i zdałem sobie sprawę, że te atrybuty są ponownie.

Mam nadzieję, że to oszczędza czas.

Wystąpił ten błąd w usłudze systemu Windows, gdy utworzona przeze mnie biblioteka usług WCF nie była podłączona do hostingu, ale została połączona w celu połączenia. Brakowało mi punktu końcowego. (Chciałem zarówno połączenie, jak i hosting w mojej usłudze systemu Windows, aby móc obsługiwać usługę WCF dla innych połączeń, a także aby główny proces mojej usługi systemu Windows używał jej również do wykonywania różnych zadań zgodnie z zegarem / harmonogramem).

Poprawka polegała na tym, że kliknąłem prawym przyciskiem myszy plik App.config i wybrałem opcję Edytuj konfigurację WCF. Następnie wykonałem kroki dotyczące tworzenia usługi, aby móc połączyć się z moją usługą WCF. Teraz miałem dwa punkty końcowe w moim App.config, a nie tylko jeden. Jeden punkt końcowy służył do połączenia z biblioteką usług WCF, a inny do jej hostowania.