Nie znaleziono strony HTTP 404 w interfejsie API sieci Web hostowanej w usługach IIS 7.5

96

Mam aplikację Web Api. Działa doskonale, gdy testowałem go przy użyciu serwera debugującego VS 2010. Ale teraz wdrożyłem go w IIS 7.5 i otrzymuję błąd HTTP 404 podczas próby uzyskania dostępu do aplikacji.

Oto mój plik web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-FlowGearProxy-20123141219;Integrated Security=True" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="true" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>
Armand
źródło
2
Mam ten sam problem. Nie znalazłem jeszcze rozwiązania, jednak odkryłem, że jeśli wybierzesz witrynę w IIS, a następnie przejdziesz do funkcji Handler Mappings, istnieje mapowanie dla plików statycznych, które mapuje * na plik, który musi istnieć. Kiedy usuwam to mapowanie i dodam nowe mapowanie dla wszystkich czasowników HTTP, nie otrzymuję już 404, jest on zastępowany pustą białą stroną.
Despertar
>> używając serwera deweloperskiego do debugowania VS 2010. - AKA zła Cassini. Zobacz blogs.msdn.com/b/rickandy/archive/2011/04/22/… - Jeśli to nie zadziała, utwórz nową aplikację MVC 4 WebApi i przetestuj wdrożenie - proste
RickAndMSFT

Odpowiedzi:

93

Ja też z tym walczyłem. Na szczęście, Steve Michelotti udokumentowane rozwiązanie, które pracowały dla mnie tutaj .

Pod koniec dnia włączyłem wszystkie czasowniki (verb = "*") do modułu obsługi ExtensionlessUrlHandler-Integrated-4.0 w mojej konfiguracji sieciowej.

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
        <handlers>
            <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
            <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
        </handlers>
</system.webServer>

Inni wskazywali, że włączenie WebDAV powoduje problemy. Na szczęście ja też nie napotkałem tego problemu.

Kevin Ortman
źródło
3
+1 dla tego. Ale zmieniłem to w mapowaniu obsługi w aplikacji z poziomu Menedżera usług IIS. Było włączone dla kilku czasowników. Zmieniłem to na wszystkie czasowniki (*) i voila. Ale zawsze lepiej jest podać źródło.
Wolf5,
1
Mam ten sam problem, ale te zmiany mi nie pomogły. Czy jest też inna konfiguracja? A może może być odniesieniem do biblioteki? Zobacz też: stackoverflow.com/questions/27303523/…
Babak
2
wiele osób twierdzi, że użycie runAllManagedModulesForAllRequests wpłynie na wydajność (sprawdź odpowiedzi hemant gautam poniżej). Jednak nie mogę uzyskać tej samej usługi, więc postępuję zgodnie z konfiguracją tutaj: blog.maartenballiauw.be/post/2012/12/07/… Ten link wskazuje również, że włączenie WebDAV może również wpłynąć na wynik
Hoàng Long
Świetna odpowiedź!
EnocNRoll - AnandaGopal Pardue,
1
Dla mnie czasownik już był *. Musiałem również zmienić ścieżkę, aby *działała, ponieważ *.nadal powodowała problem
Alsty
56

Miał ten sam problem. To ustawienie konfiguracji rozwiązało problem.

<system.webServer>
    .....
    <modules runAllManagedModulesForAllRequests="true" />
    .....
</system.webServer>

Jak wyjaśniono w http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html , należy unikać powyższego rozwiązania. Użyj tego zamiast tego. To samo rozwiązanie oferuje również Lopsided. Przechowywanie go tutaj, aby użytkownicy mogli uniknąć wdrażania pierwszego działającego rozwiązania.

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>
hemant gautam
źródło
Działa dobrze, ale nie jest to zbyt dobre rozwiązanie. Lepiej jest użyć UrlRoutingModule (patrz odpowiedź od Lopsided poniżej). britishdeveloper.co.uk/2010/06/…
Der_Meister
37

Jeśli usługi IIS są instalowane lub włączane po ASP.NET, należy ręcznie zarejestrować ASP.NET w usługach IIS, aby aplikacja .NET działała.

W systemie Windows 7 i wcześniejszych:

  1. Uruchom wiersz polecenia (cmd.exe) jako administrator.
  2. Przejdź do odpowiedniej lokalizacji .NET Framework. (np. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319)
  3. Uruchom aspnet_regiis.exe -i

W przypadku systemu Windows 8 i nowszych:

  1. W menu Start wpisz „Włącz lub wyłącz funkcje systemu Windows” i wybierz pierwszy wynik.
  2. Rozwiń Internet Information Services: World Wide Web Services: Application Development Features i wybierz ASP.NET 4.5 (lub ASP.NET 3.5, jeśli potrzebujesz obsługi projektów w .NET Framework 2.0-3.5).
  3. Kliknij OK.
Brandon Gano
źródło
2
Przeprowadziłem migrację z IIS Express w celu rozwoju do pełnego IIS i właśnie to rozwiązało problem. Dzięki!
Jim Brown
1
Podobne do @JimBrown powyżej; zadziałało dla mnie po migracji z IIS Express.
SolidRegardless
To rozwiązało problem. W systemie Windows 7 Visual Studio 2015 Ent, nowa witryna internetowa MVC 5, została zmieniona z IIS Express na pełne IIS.
Geoff Gunter
26

Czy używasz aplikacji interfejsu API sieci Web w katalogu wirtualnym lub aplikacji?

Na przykład: miałem ten sam problem, kiedy przeniosłem projekt do lokalnych usług IIS w domyślnej witrynie sieci Web> SampleWebAPI. Uważam, że wynika to ze zmiany wURL routingu:

Oryginalny: localhost:3092/api/values
przeniesiony: localhost/SampleWebAPI/api/values

Jeśli przeniesiesz projekt interfejsu API sieci Web do własnej witryny internetowej działającej na innym porcie, wydaje się, że działa.

Dodatkowa uwaga: dodatkowo skomplikowałem sprawę, dodając apijako alias aplikacji w mojej witrynie, która spowodowała skutecznośćURL był:

localhost:81/api/api/values - zauważyłem to po przeniesieniu serwisu na własną stronę

Dlatego, ponieważ chciałem zachować oddzielenie między moją witryną internetową a witryną projektu global.asaxWeb API MVC , zmieniłem reguły routingu w interfejsie Web API „DefaultAPI” z api/{controller}/{id}na, {controller}/{id}a ASP.NET MVC Defaultz {controller}/{id}na info/{controller}/{id}.

Nicholas Barger
źródło
3
hehehe ... ja nazwał moją aplikację w IISjak apiteż. Spowodowało to wszystkie te próby i błędy debugowania przez ponad 2 godziny. Dziękuję bardzo za podzielenie się swoimi doświadczeniami! Zmieniłem nazwę i teraz wróciłem do biznesu. : D
Leniel Maccaferri
Dzięki - to był mój problem! :)
Jen
Nie jestem pewien, dlaczego wywołania API kończyły się niepowodzeniem, gdy hostowałem swój projekt pod portem 8080, po prostu przeniesienie go jako katalogu wirtualnego na domyślną stronę internetową załatwiło sprawę :)
Kiran
14

To jedyna odpowiedź, która mi pomogła ...

Miałem podobny problem ... Wyglądało na to, że bez względu na to, co zrobiłem, nic nie było przekierowywane, a mój plik globalny był po prostu ignorowany. Poważnie rozważałem zakończenie tego wszystkiego, zanim znalazłem tę odpowiedź. Mam nadzieję, że ten link pomoże komuś innemu.


Dodanie następujących elementów do pliku web.config działało dla mnie:

<system.webServer>
  <modules>
    <remove name="UrlRoutingModule-4.0" />
    <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  </modules>
</system.webServer>

Znacznik system.webServer już tam był, ale dodałem do niego tag modules , a następnie tag remove & add to modules.

Przechylony
źródło
Uderz w ten problem na serwerze 2008 (nie R2) i było to jedyne rozwiązanie, które działało dla mnie. Musiałem także połączyć to z ustawieniem puli aplikacji w tryb „zintegrowany”.
Zoomzoom
11

Kilka rzeczy do sprawdzenia:

  1. Upewnij się, że masz zainstalowaną platformę .NET Framework 4.
  2. Upewnij się, że wersja 4 programu .NET Framework jest wybrana dla Twojej witryny internetowej i katalogu wirtualnego (jeśli dotyczy).
  3. Upewnij się, że masz zainstalowany MVC lub odpowiednie biblioteki DLL w katalogu bin.
  4. Może być konieczne zezwolenie na rozszerzenia usług internetowych ASP.NET 4.0
  5. Umieść aplikację w jej własnej puli aplikacji.
  6. Upewnij się, że katalog ma przynajmniej uprawnienia do wykonywania „Tylko skrypty”.
Joe Schrag
źródło
Mam 4 inne normalne aplikacje internetowe uruchomione na tym samym serwerze IIS i wszystkie używają .NET Framework 4. Więc który z tych 4 punktów nie jest potrzebny? kiedy opublikowałem moją aplikację mvc, dodałem zależności możliwe do wdrożenia i dodałem ASP.NET MVC, więc jest w moim katalogu bin
Armand
@Armand Wygląda na to, że zrobiłeś numer 1. # 2 jest nadal potrzebny. Dodanie zależności, które można wdrożyć, jeśli wykonałeś to zgodnie z opisem tutaj: haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx , powinno zająć się punktem 3 powyżej. # 4 może być konieczne lub nie, chociaż nie mam wiedzy, aby powiedzieć, kiedy jest i nie jest potrzebne.
Joe Schrag,
9

Miałem podobny problem. Miałem odpowiednie ustawienia w moim pliku web.config, ale pula aplikacji była uruchamiana w trybie klasycznym, a nie w trybie zintegrowanym

zrzut ekranu

Rob Sedgwick
źródło
7

Ten problem może również wystąpić z następujących powodów

W sieci Web.Config

<system.webServer>
     <modules runAllManagedModulesForAllRequests="true" /> 
<system.webServer>

2. Upewnij się, że następujące elementy są dostępne w folderze bin na serwerze, na którym wdrożono interfejs API sieci Web

  • System.Net.Http

  • System.Net.Http.Formatting

  • System.Web.Http.WebHost

  • System.Web.Http

Te zestawy nie zostaną domyślnie skopiowane do folderu bin, jeśli publikowanie odbywa się za pośrednictwem programu Visual Studio, ponieważ pakiety interfejsu API sieci Web są instalowane za pośrednictwem narzędzia NuGet na komputerze deweloperskim. Jeśli jednak chcesz, aby te pliki były dostępne w ramach publikowania w programie Visual Studio, musisz ustawić CopyLocal na True dla tych zestawów

Sadish Kumar.V

Sadish Kumar V
źródło
Te biblioteki DLL są wymagane, jeśli nie masz zainstalowanego MVC na serwerze. W moim przypadku widziałem pustą stronę podczas próby wywołania API. Ręczne dodawanie biblioteki DLL zadziałało dla mnie. Dzięki!!
Vipul bhojwani
Mój problem został rozwiązany po dodaniu System.Net.Http do głównego folderu publikowania, moim było rozwiązanie Asp.net Core
mohas
6

Na podstawie tej SO odpowiedź , po prostu musiał zmienić path="*."się path="*"dla dodany ExtensionlessUrlHandler-Integrated-4.0wconfiguration>system.WebServer>handlers w moimweb.config

Przed:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Po:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
Greg
źródło
Dziękuję bardzo Greg, miałem zamiar mnie zabić z powodu tej głupiej ścieżki = "*". ale teraz, po upuszczeniu tej żałosnej kropki, wszystko działa idealnie! Dziękuję Ci bardzo!
Junior Silva,
5

Ja też napotkałem ten problem. Rozwiązałem problem, przechodząc do puli aplikacji> Nazwa puli aplikacji i zmieniłem platformę .NET Framework z wersji 2.0.50727 na 4.0.30319.

coson
źródło
1
Sam też to odkryłem. Głosowanie za Twoją odpowiedź, ponieważ łatwo ją przeoczyć. Kiedy utworzyłem witrynę dla mojej aplikacji, usługi IIS automatycznie utworzyły dla mnie pulę aplikacji, ustawioną na .NET v2.0 !! Dlaczego dlaczego dlaczego?? :)
Mike Taverne
3

Musiałem wyłączyć opcję „Prekompiluj podczas publikowania”.

Pakman
źródło
A gdzie to robisz?
vapcguy
1
Znajduje się w oknie dialogowym, które pojawia się po kliknięciu projektu prawym przyciskiem myszy i wybraniu opcji Opublikuj. Wygląda to
Pakman
3

Istnieje oficjalna poprawka firmy Microsoft: http://support.microsoft.com/kb/980368

Zdecydowanie NIE polecam używania <modułów runAllManagedModulesForAllRequests = "true">. Prowadzi to do tego, że wszystkie żądania (nawet .jpg, .css, .pdf itp.) Będą przetwarzane przez wszystkie zarejestrowane moduły HTTP. Są dwa negatywne momenty: a) dodatkowe obciążenie zasobów sprzętowych; b) potencjalne błędy, ponieważ moduły http będą przetwarzać nowe typy treści.

Roman O
źródło
1
Dziękuję tak dużo! Próbowałem absolutnie wszystkiego innego i to była jedyna rzecz, która to naprawiła.
Oran Dennison
To samo tutaj, bardzo dziękuję za dodanie tej odpowiedzi! Czy rozwiązanie mojego problemu!
Octavio Garbarino
2

Zacząłem otrzymywać odpowiedzi 404 z internetowego interfejsu API po wykonaniu samouczka systemu Windows Azure, w którym zalecono mi dodanie pliku „WebRole.cs” do mojego projektu.

Po usunięciu „WebRole.cs” z mojego projektu, moje wywołania interfejsu API sieci Web znów zaczęły działać.

Josh Mouch
źródło
To zadziałało dla mnie. Przeprowadziłem migrację aplikacji Azure z powrotem do wdrożenia maszyny wirtualnej i po zakomentowaniu zawartości WebRole.cs moje wywołania WebAPI ponownie zaczęły działać.
Scott,
Musiałem spędzić nad tym dzień! Komentowanie WebRole.cs zadziałało - zastanawiam się jednak dlaczego
Igorek
2

Upewnij się, że pula aplikacji jest w trybie zintegrowanym
i dodaj następujące elementy do pliku web.config:

<system.webServer>
    .....
    <modules runAllManagedModulesForAllRequests="true" />
    .....
</system.webServer>
Rakesh
źródło
2

W moim przypadku problem polegał po prostu na tym, że próbowałem uzyskać dostęp do witryny pod adresem

myserver.myintranet.com/mysite

Jednak powiązanie witryny sieci Web dla protokołu http w usługach IIS nie miało nazwy hosta określonej w powiązaniu. To działało wcześniej i nie mam pojęcia, jak to się zdmuchnęło.

Kiedy myserver.myintranet.compodałem nazwę hosta, 404 zniknął.

W Menedżerze IIS przechodzisz do Powiązania ... w okienku akcji, a następnie edytuj powiązanie http, aby określić nazwę hosta.

toddmo
źródło
Nawet ja też mam ten sam problem. i jak zasugerowałeś, sprawdziłem nazwę hosta w wiązaniu http i zaktualizowałem się tylko poprawnie. Ale nadal mój problem nadal występuje. Uwaga: hostowałem moją aplikację API jako aplikację podrzędną. Proszę zasugerować, jeśli ktoś ma na to pomysł. np. „sample.example.com” to moja główna aplikacja i utworzyłem interfejs API w tej domenie pod nazwą „sample.example.com/myAPI/”
Krishna Mani
2

Nie zapomnij wdrożyć global.asax

Adem Aygun
źródło
1

Wystąpił ten sam problem, odpowiedź 404 dla kontrolerów interfejsu API sieci Web podczas obsługi z IIS, ale wszystko działało dobrze od VS2010. Żadne z powyższych rozwiązań nie zadziałało. W końcu odkryłem, że problem polegał na tym, że dodaliśmy obsługę WSE 3.0 dla aplikacji i brakowało biblioteki dll Microsoft.Web.Services3 w katalogu aplikacji / bin. Dziwne, ale po skopiowaniu dll zaczęło działać mapowanie tras.

devilcius
źródło
1

Dla mnie problem polegał na tym, że witryna główna została skonfigurowana do korzystania z puli aplikacji .NET 2.0, a moja aplikacja w tej witrynie to .NET 4.5.

Utworzyłem nową witrynę z pulą aplikacji .NET 4 i umieściłem moją aplikację w katalogu głównym - i to działało dobrze.

JuniorEbuka
źródło
1

Ja też z tym walczyłem. Mój dokładny problem polegał na tym, że miałem usługę sieciową ASMX, która po wprowadzeniu parametru do metody sieciowej i przetestowaniu jej dawała mi 404. Konkretna metoda działała dobrze w przeszłości i nie została zmieniona, tylko ponownie opublikowane. Potem dotarłem tutaj i wypróbowałem wszystkie opublikowane odpowiedzi i nic nie pomogło.

Moje ostateczne rozwiązanie? Wiem, że to drastyczne, ale właśnie stworzyłem nowe rozwiązanie Visual Studio i projekt sieci Web. Wybrałem MVC, a następnie wykonałem „Dodaj”> „Nowy element”, zaznaczono pod nim „Visual C #”> „Sieć” i „Usługa sieci Web (ASMX)”. Skopiowałem cały mój stary kod związany z kodem, następnie zanotowałem przestrzeń nazw, którą dał nowy plik w moim nowym projekcie, a następnie wkleiłem cały mój stary kod do nowego pliku związanego z kodem w nowym projekcie i umieściłem przestrzeń nazw z powrotem do tego, co było.

Następnie utworzyłem foldery w moim projekcie, które miałem przed użyciem programu Visual Studio do „Dodaj”> „Nowy folder”, a następnie skopiowałem z powrotem do folderów z innego projektu za pomocą Eksploratora Windows, a następnie kliknąłem prawym przyciskiem myszy każdy folder w Visual Studio i wykonałem polecenie „Dodaj”> „Istniejący element ...” i pobrałem elementy z tych folderów do folderów programu Visual Studio mojego nowego projektu. Ponownie odwołałem się do wszystkich moich zestawów .NET, mając otwarte oba projekty, więc mogłem porównać, do których odwoływałem się wcześniej (było ich kilka). Musiałem nazwać mój nowy projekt nieco inaczej - w zasadzie zrobiłem coś podobnego do „GeneralWebApp” zamiast na przykład „MyWebApp” - więc musiałem wykonać polecenie „Replace All” w całym rozwiązaniu, aby zastąpić tę nazwę,

Następnie wykonałem „Przebuduj wszystko” w projekcie, a następnie uruchomiłem go przyciskiem „Odtwórz”, który program Visual Studio wyświetla, gdy mam go poprawnie zbudować. Działało dobrze. Więc opublikowałem to i wszystko było w porządku na serwerze, na którym to opublikowałem, kiedy to uruchomiłem. Nie mam wyjaśnienia, co się stało, ale tak właśnie przez to przeszedłem. Nie jest to zły test, aby sprawdzić, czy coś, co robi Visual Studio, zepsuło go.

vapcguy
źródło
1

Jeśli umieścisz tylko folder bin w usługach IIS (po skompilowaniu projektu), ten problem również wystąpi. W takiej sytuacji należy opublikować projekt za pomocą VisualStudio, a następnie umieścić opublikowany folder w usługach IIS.

Emad Armoun
źródło
0

Jakiego rodzaju żądania HTTP wykonujesz?

To jest nieco lewe pole odpowiedzi, ale czy próbowałeś usunąć domyślną stronę błędu usług IIS dla 404, aby sprawdzić, co faktycznie zwraca Twój interfejs API?

Wystąpił problem polegający na tym, że chciałem, aby metoda kontrolera zwracała kod 404, gdy POSTAŁEM niewłaściwy identyfikator. Zauważyłem, że zawsze otrzymuję stronę IIS 404 „Nie znaleziono pliku lub katalogu” zamiast odpowiedzi HTTP z mojego interfejsu API. Usunięcie domyślnej strony błędu 404 rozwiązało problem.

Inny problem, ale nigdy nie wiesz, że może pomóc;)

Oliver Picton
źródło
0

Ta część konfiguracji w pliku web.config może mi pomóc: w sekcji system.webServer:

      <security>
          <requestFiltering>
              <verbs applyToWebDAV="true">
                  <remove verb="PUT" />
                  <add verb="PUT" allowed="true" />
                  <remove verb="DELETE" />
                  <add verb="DELETE" allowed="true" />
                  <remove verb="PATCH" />
                  <add verb="PATCH" allowed="true" />
              </verbs>
          </requestFiltering>
      </security>      
Konstantin Isaev
źródło
0

Niedawno wystąpił błąd 404 Not Found we wszystkich moich trasach / kontrolerach Web Api 2. Więc wszedłem na rzeczywisty serwer i spróbowałem przeglądać używając localhost zamiast nazwy hosta i otrzymałem "404.7 Not Found - moduł filtrowania żądań jest skonfigurowany tak, aby odmawiać rozszerzenia pliku".

Ten wpis SO pomoże mi go rozwiązać.

Santos
źródło
0

Problem został rozwiązany dla mnie, kiedy włączam pole wyboru dla UrlRoutingModule-4.0:

Menedżer IIS> Moduły> wybierz UrlRoutingModule-4.0> Edytuj moduł> zaznacz pole wyboru „Wywołaj tylko dla żądań do aplikacji ASP.NET lub zarządzanych programów obsługi”.

Anilkumar Y
źródło
0

Miałem ten sam problem: na nowo zainstalowanej maszynie z Visual Studio 2013 projekt interfejsu API sieci Web działał pod IISExpress, ale nie pod lokalnymi IIS. Próbowałem wszystkiego, co mogłem znaleźć, ale ostatecznie problem nie był konieczny z Web API, ale z MVC: nawet gdy był zainstalowany, żaden projekt MVC nie działał.

Pomogło mi odinstalowanie usług IIS (z DODAJ / USUŃ funkcje systemu Windows), a następnie ponowne ich zainstalowanie i uruchomienie aspnet_regiis -i. Może to pomoże komuś innemu.

Marian Siminescu
źródło
0

Spędziłem dużo czasu próbując wielu rzeczy, aby w końcu zdać sobie sprawę, że dodawałem moją aplikację internetową nie w Witrynach / Domyślnych Witrynach internetowych, ale w innej witrynie połączonej z innym portem. Oczywiście wypróbowanie localhost na porcie 80 dałoby 404.

guiomie
źródło
0

nic nie robię, po prostu dodaj ten tag w web.config, jego działanie w tym problemie pojawia się jeden z następujących punktów

  1. Użyj interfejsu API sieci Web w tym samym projekcie przy użyciu formularzy MVC lub asp.net

  2. Użyj RouteConfig i WebApiConfig w Global.asax jako GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);

  3. Użyj RouteConfig do 2 celów, formularzy asp.net przy użyciu z przyjaznym adresem URL i routingiem MVC dla routingu MVC

po prostu używamy tego tagu w web.config, to zadziała.

<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
   .........................
</modules>
</system.webServer>
adnan
źródło
0

Napotkałem ten sam problem z interfejsem API sieci Web i interfejsem API sieci Web .Net Core. Działał dobrze w VS 2017 podczas debugowania, ale zwrócił 404 po opublikowaniu w usługach IIS 7.5. Rozwiązaniem dla mnie była zmiana sposobu tworzenia strony. Zamiast publikować w katalogu głównym witryny sieci Web (utworzonej przez kliknięcie prawym przyciskiem Witryny ... Dodaj witrynę sieci Web), musiałem utworzyć aplikację (utworzoną przez kliknięcie witryny sieci Web prawym przyciskiem myszy ... Dodaj aplikację) i opublikować w tym folderze. Zauważ, że w przypadku wersji Core musiałem zmienić ustawienie wersji puli aplikacji .NET Framework na „Brak kodu zarządzanego”.

miked
źródło
0

Dla mnie rozwiązaniem było usunięcie następujących wierszy z mojego pliku web.config:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.3" newVersion="4.1.1.3" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Tokens" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Zauważyłem, że VS dodał je automatycznie, nie wiem dlaczego

protango
źródło
0

Wypróbuj ten webconfg .. zamień plik „NewsApi.dll” na swój główny plik DLL!


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\NewsApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
    </system.webServer>
  </location>
</configuration>
Prime By Design
źródło