Wdrożenie IIS7 - zduplikowana sekcja „system.web.extensions / scripting / scriptResourceHandler”

209

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

użytkownik20358
źródło

Odpowiedzi:

338

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.

Carlos Aguilar Mares
źródło
Dzięki. Właściwie to wymyśliłem to obejście po majstrowaniu przy kilku innych ...
user20358
3
Dziękujemy za wyjaśnienie tego. Ciągle widziałem rozwiązanie pozwalające usunąć sekcję z pliku konfiguracyjnego i zastanawiam się: „jak wycinanie części pliku konfiguracyjnego jest rozwiązaniem”?
Adam Bruss,
13
BASEN MOJEJ APLIKACJI ZOSTAŁ USTAWIONY DO 4.0 zamiast 2.0!
RolandoCC
1
To było łatwe, zmień starszą stronę na pulę aplikacji 2.0 i viola to działa! Dzięki!
mgrenier
1
Tylko usunięcie sekcji .net 3.5 z web.config zadziałało dla mnie
Anand
49

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:

wprowadź opis zdjęcia tutaj

DaveDev
źródło
13
aaaand, jeśli faktycznie używasz .NET 4.0 w aplikacji?
Michael Paulukonis,
3
@MichaelPaulukonis Miałem ten problem, okazało się, że w głównej stronie internetowej znajduje się web.config, z którego dziedziczy moja strona.
guanome
@MichaelPaulukonis, pfft tak się stanie!
DaveDev
Miałem ten problem, kiedy moja aplikacja została uaktualniona z 3.5 do 4.0, pula aplikacji została poprawnie zaktualizowana, ale plik web.config był nieaktualny. Web.config próbował dodać wszystkie grupy sekcji, które od 4.0 są natywne i nie trzeba ich jawnie dodawać.
drizin
48

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>

Johann
źródło
3
Twoje było jedynym rozwiązaniem, które rozwiązało mój błąd! Wielkie dzięki!
Devdatta Tengshe
1
To także rozwiązało mój problem. Serwer został uaktualniony z IIS6 do IIS7.5. Na IIS6 działał pod wersją 4.0, ale IIS7.5 potrzebował tej zmiany web.config.
johna
to było niesamowite.
mzonerz,
Wartość w PublicKeyToken rozróżnia małe i wielkie litery (i powinna wyglądać tak jak w odpowiedzi). Miałem moje wielkie litery i to nie działało.
Björn
3

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

Aldo Flores Reyes
źródło
22
Witamy w StackOverflow! Jeśli nie masz wystarczającej znajomości języka angielskiego, uruchom swoje odpowiedzi za pośrednictwem Tłumacza Google . Społeczność poprawi wszelkie dziwne frazy, edytując. Dziękuję za Twoją odpowiedź. ||||| za pośrednictwem Tłumacza Google ||||| Bienvenido a StackOverflow! Jeśli nie znasz żadnych języków, wystarczy, że lubisz odpowiedzi na pytania w Tłumaczu Google . La comunidad mejorará frases extrañas en la edición. Gracias por su respuesta.
Andrew Kozak,
3

Ustaw pulę aplikacji na 2.0, zrobiłem to i działałem.

Arnold Sandí Calderón
źródło
3

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.

Stefan Steiger
źródło
Doskonałe wyjaśnienie
William Bello
2

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:

  1. otwórz wiersz polecenia programu Visual Studio (jako administrator)
  2. przejdź do „C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation”
  3. Uruchom servicemodelreg -i
Paul Diggle
źródło
1

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.

Bay Sola
źródło
dzięki. Wygląda na to, że cofanie zmian i cofanie zmian nie spowoduje prawidłowego przejścia aplikacji do stanu .NET 3.5.
Iman
0

Innym sposobem uniknięcia tego problemu, który może pomóc innym, jest zbudowanie usługi sieciowej .net do wersji 4.0 lub wyższej, jeśli to możliwe.

Aelphaeis
źródło
0

W moim przypadku miałem 2 różne aplikacje współdzielące tę samą pulę aplikacji. Pierwszy używał framwork .net4.5, a nowy 2.0. Kiedy zmieniłem drugą aplikację na własną pulę aplikacji, zaczęła działać poprawnie bez żadnych zmian w pliku web.config.

Dowlers
źródło
0

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.

TheGhoul
źródło
0

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>
Mariusz Pawelski
źródło
0

Rozwiązałem go, wykonując następujące kroki:

  1. Utworzyłem nową grupę aplikacji w IIS.
  2. Otwórz zaawansowane ustawienia witryny lub aplikacji internetowej, która ma ten problem.
  3. I ustaw grupę nowej aplikacji.

Oto zdjęcia tych kroków:

Utwórz grupę nowej aplikacji

Po utworzeniu grupy aplikacji

Ustaw grupę aplikacji w swojej witrynie lub aplikacji internetowej

Giovanny Farto M.
źródło
0

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.

Nassosk
źródło
0

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

MrFile
źródło