HTTP 404 podczas uzyskiwania dostępu do pliku SVC w usługach IIS

Niedawno utworzyłem usługę WCF, która działa dobrze podczas testowania z Visual Studio 2008. ale kiedy wdrażam projekt w IIS i próbuję uzyskać dostęp do pliku .svc z IIS, pojawia się ten błąd:

"Server Error in '/' Application.The resource cannot be found.  "

Mam ten problem od 4 dni.

w Handler Mappings of IIS Manager widzę dwa wpisy dla .svc:

svc-Integrated and svc-ISAPI-2.0

Musisz dodać mapowanie rozszerzenia SVC do ASP.NET. Najłatwiej to zrobić, uruchamiając ServiceModelReg.exe -iz C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation. Może być również konieczne włączenie ASP.NET, jeśli jeszcze tego nie zrobiłeś.

Jeśli używasz systemu Windows Server 2012 lub 2016, postępuj zgodnie z poniższymi instrukcjami:

• WCF w IIS8; Mapowanie obsługi * .svc nie działa

Co mi pomogło, w systemie Windows 2012 Server R2:

Podziękowania dla „Aarona D”

Znalazłem te instrukcje w poście na blogu, który wskazywał na ten krok, który zadziałał dla mnie (Windows 8, 64-bit):

Upewnij się, że w funkcjach systemu Windows są zaznaczone obie opcje WCF w ramach platformy .NET. Przejdź do Panelu sterowania -> Programy i funkcje -> Włącz / wyłącz funkcje systemu Windows -> Funkcje -> Dodaj funkcje -> Funkcje .NET Framework XX. Upewnij się, że platforma .Net mówi, że jest zainstalowana, i upewnij się, że węzeł aktywacji WCF pod nim jest zaznaczony (zaznaczone pole wyboru) i obie opcje w obszarze Aktywacja WCF są również zaznaczone.

To są:
* Aktywacja HTTP
* Aktywacja bez HTTP
Należy wybrać obie opcje (zaznaczone pole wyboru).

Widzę, że już rozwiązałeś swój problem - ale dla potomności:

Mieliśmy podobny problem, a program obsługi SVC był już poprawnie zainstalowany. Nasz problem polegał na tym, że program obsługi ExtensionlessUrl przetwarzał żądania, zanim dotarły one do modułu obsługi SVC.

Aby to sprawdzić - w Mapach obsługi w Menedżerze usług IIS na poziomie serwera WWW wyświetl listę programów obsługi w kolejności (jest to opcja po prawej stronie). Jeśli różne programy obsługi ExtensionlessUrl pojawiają się nad programami obsługi SVC, kilkakrotnie przesuwaj je w dół, aż znajdą się na dole.

Sprawdza, czy katalog został przekonwertowany na aplikację, która jest usługą IIS.

Miałem dzisiaj ten sam problem.

Dla mnie rozwiązaniem było przejście do IIS, kliknięcie prawym przyciskiem myszy nowej nazwy witryny sieci Web, wybranie Właściwości, ASP.Net i zmiana wersji ASP.Net z „1.1.4322” (którą ustawiono jako domyślną) do 2.0.50727.

Gdy już to zrobiłem, mogłem kliknąć prawym przyciskiem myszy plik .svc, kliknąć „Przeglądaj” i wyświetlić przyjazną stronę serwisu.

Może to również stać się problemem po włączeniu zgodności zarządzania usługami IIS 6 w systemie Windows 10. Ustawienie aktywacji HTTP struktury w ramach usług WCF rozwiąże problem.

W moim przypadku błąd był spowodowany nieprawidłowymi ustawieniami mapowania w pliku applicationhost.config (\ System32 \ inetsrv \ config). Z jakiegoś powodu program Visual Studio 2013 uszkodził go podczas tworzenia katalogu wirtualnego w usługach IIS. Poprawka polegała na ręcznej edycji sekcji witryn w pliku.

Istnieją 2 wersje platformy .net dostępne w ramach funkcji dodawania roli / funkcji w serwerze 2012

za. 3.5

b. 4.5

W zależności od używanej struktury można włączyć aktywację HTTP w usługach WCF. :)

W moim przypadku Win 10. plik applicationHost.config jest uszkodzony przez VS 2012. I możesz pobrać kopię historii tego pliku w C: \ inetpub \ history. Następnie uruchom ponownie usługi IIS i działa poprawnie.

Musiałem dodać rozszerzenie .svc do dozwolonych rozszerzeń w ustawieniach filtrowania żądań (wcześniej otrzymałem błędy 404.7).

Dodanie sufiksu .svc, który jest dozwolony w filtrowaniu żądań, załatwiło sprawę.

Żadne z powyższych rozwiązań nie rozwiązało za mnie tego błędu. Musiałem ustawić w web.config:

system.servicemodel > bindings > webHttpBinding > binding:

<security mode="Transport">
  <transport clientCredentialType="None" />
</security>

Chciałbym skorzystać z okazji i jeszcze raz PRZEKLĄĆ Microsoft za stworzenie tak ogromnego bałaganu w .NET Framework i utrudnianie życia programistom przez tak długi czas!