Podczas próby wdrożenia witryny .net 3.5 w domyślnej puli aplikacji w usługach IIS7, w której sekcja ramowa jest ustawiona na 4.0, pojawia się następujący błąd.
Zdefiniowano zduplikowaną sekcję „system.web.extensions / scripting / scriptResourceHandler”.
Komentowanie obrażających linii również nie pomogło. Jakieś wskazówki na temat tego, co muszę zrobić lub na co spojrzeć?
Odpowiedzi:
Jeśli planujesz wdrożyć na IIS, który ma pulę aplikacji działającą w .net 4.0, musisz wyczyścić web.config, który zawiera wszystkie sekcje Definicje wskazujące na .net 3.5. Powodem tego niepowodzenia jest to, że te definicje sekcji są już zawarte w głównym pliku web.config w .NET 4.0 (patrz% windir% \ microsoft.net \ framework \ v4.0.30319 \ config \ machine.config), które obejmują cały system. web.extensions już zadeklarowane.
Inną szybką poprawką jest ustawienie puli aplikacji na 2.0, tak jak wydaje się to mieć na komputerze deweloperskim.
Rozwiązaniem dla mnie była zmiana wersji platformy .NET w pulach aplikacji z wersji 4.0 na wersję 2.0 dla domyślnej puli aplikacji:
Jeśli, podobnie jak ja, musisz celować w v4, ale możesz budować tylko z .net 3.5, postępuj zgodnie z instrukcją tutaj . Po prostu zamień w pliku web.config całą zawartość na <configSections>:
<configSections>
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere"/>
<section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
<section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
<section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
</sectionGroup>
</sectionGroup>
</sectionGroup>El problema es porque el pool por defecto esta en .net 4.0 Solucion: powierz serwer Administrador IIS lado derecho ustanowienia valores de grupos de aplicaciones.! [Wpisz opis zdjęcia tutaj] [1] y cambiar la vercion del framework! tutaj] [2]
Dzięki temu rozwiązaniu problemu z instalacją centralnego programu SharePoint 2010
----- za pośrednictwem Tłumacza Google -----
Problem polega na tym, że pula jest domyślnie. Rozwiązanie Net 4.0: wprowadź serwer IIS Manager, aby ustawić wartości po prawej stronie pul aplikacji.! [Wpisz opis obrazu tutaj] [1] i zmień wersję ramy! [Wpisz opis obrazu tutaj] [2]
To powinno rozwiązać problem z instalacją centralnej administracji SharePoint 2010
Ustaw pulę aplikacji na 2.0, zrobiłem to i działałem.
Nekromancja.
Jeśli w pliku web.config nie ma żadnych sekcji konfiguracji system.web.extensions ani wpisów modułu obsługi / modułu, ten problem jest spowodowany, ponieważ ty / ktoś skopiował projekt VisualStudio (2013/2015/2017) , ukrywając się -file unhidden .
Z tego powodu nie tylko skopiuje .git, ale także .VS, który zawiera plik applicationhost.config IIS-Express , który wskazuje na pliki web.config przy ścieżkach, które nie istnieją (lub, co gorsza, ścieżki, które istnieją, ale nie mają tej samej treści) ...
Rozwiązanie:
Usuń plik applicationhost.config z folderu .VS.
Lub po prostu usuń całkowicie folder .VS.
Program Visual Studio odtworzy go ponownie.
Moja aplikacja była aplikacją ASP.Net3.5 (korzystającą z wersji 2 frameworka). Po utworzeniu aplikacji ASP.Net3.5 program Visual Studio automatycznie dodał skryptResourceHandler do pliku web.config. Późniejsze wersje .Net umieściły to w pliku machine.config. Jeśli uruchomisz aplikację ASP.Net 3.5 przy użyciu puli aplikacji w wersji 4 (w zależności od kolejności instalacji jest to domyślna pula aplikacji), pojawi się ten błąd.
Kiedy przeniosłem się do korzystania z puli aplikacji w wersji 2.0. Błąd zniknął. Miałem wtedy do czynienia z błędem podczas udostępniania WCF .svc:
Błąd HTTP 404.17 - Nie znaleziono Żądana treść wydaje się być skryptem i nie będzie obsługiwana przez program obsługi plików statycznych
Po pewnym dochodzeniu wydaje się, że musiałem zarejestrować moduł obsługi WCF. wykonując następujące kroki:
Najwyraźniej inni mieli (mieli) tę problem . Odbudowują się w Framework 4.0. Czy możesz?
Zobacz też, jak upewnić się, że Twoje IIS są świeże .
W moim przypadku stało się to po przekonwertowaniu całego rozwiązania (przy użyciu rozszerzenia o nazwie Target Framework Migrator) na 4.6.2, ale ostatecznie cofnąłem zmiany i wróciłem do wersji 3.5 (wersja jest obsługiwana przez TFS). Aby rozwiązać ten problem, przekonwertowałem tylko problematyczny projekt (który uruchamiał IIS Express) na 4.6.2, a następnie z powrotem na 3.5.
Moje postanowienie było trochę głupie.
Zainstalowałem kopię .net 3.5
Utworzono kolejną pulę aplikacji i wybrano .net 3.5 (z rozwijanego menu to 2.0.5077)
Dodano moją stronę do tej puli aplikacji
Przetwarzaliśmy stare i nowe pule, a strona zaczęła działać.
Spowodowało to, że nie zainstalowałem 3.5, mimo że funkcje włączania systemu Windows powiedziały, że tak zrobiłem i utworzyłem kolejną pulę aplikacji do użycia. Mam nadzieję, że to pomaga innym.
W moim przypadku chciałem ręcznie dodać regułę urlrewrite i nie widziałem oczywistego błędu (brakowało mi <rules>tagu):
zły kod:
<rewrite>
<rule name="some rule" stopProcessing="true">
<match url="some-pattenr/(.*)" />
<action type="Redirect" url="/some-ne-pattenr/{R:1}" />
</rule>
</rewrite>
</system.webServer>
</configuration>właściwy kod (ze znacznikiem reguł):
<rewrite>
<rules>
<rule name="some rule" stopProcessing="true">
<match url="some-pattenr/(.*)" />
<action type="Redirect" url="/some-ne-pattenr/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>Rozwiązałem go, wykonując następujące kroki:
Oto zdjęcia tych kroków:
Ten komunikat o błędzie pojawia się w różnych sytuacjach.
W moim przypadku na wierzchu pliku Web.Config mojej aplikacji miałem dodatkowy plik Web.Config w folderze głównym (C: \ Inetpub \ www.root). Prawdopodobnie zostawiłem go po kilku testach, zapomniałem o tym i nie mogłem zrozumieć, na czym polega problem.
Usunięcie go rozwiązało problem.
To może być zła odpowiedź dla ciebie. Ale to był pierwszy hit w Google, kiedy próbowałem rozwiązać mój problem. Powiedziawszy to ...
Ten sam komunikat o błędzie wystąpił również dla mnie, ale gdy próbowałem uruchomić IIS Express za pośrednictwem programu Visual Studio.
Mój problem polegał na tym, że przez pomyłkę popełniłem błąd applicationhost.config TFS. Później, kiedy próbowałem uruchomić projekt na moim laptopie po otrzymaniu najnowszych zatwierdzeń. właśnie wtedy wystąpił błąd.
Odkryłem, że ścieżka do katalogu wirtualnego była nieprawidłowa.
<virtualDirectory path="/" physicalPath="C:\Users\giddan\Documents\Visual Studio 2015\Projects\ProjectName\DeV.ProjectName\DeV.ProjectName.Web" />Mam nadzieję, że to komuś pomoże!
To jest mój pierwszy post, więc bądź delikatny :)