Er is een ASP.NET-instelling gedetecteerd die niet van toepassing is in de modus Geïntegreerde beheerde pijplijn

Ik heb DotNetOpenAuth SDK-3.4.5.10201.vsix geïnstalleerd en ik krijg het niet werkend.
Het werkt lokaal (wanneer ik als localhost gebruik), maar wanneer ik probeer te publiceren, werkt het niet.

De IIS-foutmelding die ik krijg is

Foutoverzicht
HTTP-fout 500.22 – Interne serverfout
Er is een ASP.NET-instelling gedetecteerd die niet van toepassing is in de modus Geïntegreerde beheerde pijplijn.

EN

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

dan zijn er enkele suggesties om het probleem op te lossen:

Dingen die u kunt proberen:

• Migreer de configuratie naar de
  system.webServer/modulessectie. Jij
  kan dit handmatig doen of met behulp van AppCmd
  vanaf de opdrachtregel – bijvoorbeeld
  %SystemRoot%\system32\inetsrv\appcmd
migrate config "Default Web Site/".
  AppCmdgebruiken om uw . te migreren
  applicatie zal het mogelijk maken om te werken in
  Geïntegreerde modus, en blijven werken
  in de klassieke modus en op vorige
  versies van IIS.

• Als u zeker weet dat het OK is om
  negeer deze fout, deze kan worden uitgeschakeld
  door in te stellen
  system.webServer/validation@validateIntegratedModeConfiguration
  te vals.

• U kunt ook van applicatie wisselen
  naar een toepassingsgroep in de klassieke modus –
  bijvoorbeeld,
  %SystemRoot%\system32\inetsrv\appcmd
set app "Default Web Site/"
/applicationPool:"Classic .NET
AppPool". Doe dit alleen als u
  kan uw toepassing niet migreren.
  (Stel “Standaardwebsite” en “Classic .NET AppPool” in op uw toepassingspad en naam van de toepassingsgroep)

Maar het probleem is dat ik geen toegang heb tot de ISS-server omdat ik er niet de eigenaar van ben. Is er een manier om dit op te lossen?

Antwoord 1, autoriteit 100%

De 2^eoptie is degene die je wilt.

Controleer in uw web.configof deze sleutels bestaan:

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>

Antwoord 2, autoriteit 14%

Toevoegen van <validation validateIntegratedModeConfiguration="false"/>lost het symptoom op, maar is niet geschikt voor alle omstandigheden. Ik heb dit probleem een paar keer rondgelopen en hoop anderen te helpen niet alleen het probleem op te lossen, maar het ook te begrijpen. (Wat steeds belangrijker wordt naarmate IIS 6 vervaagt tot mythes en geruchten.)

Achtergrond:

Dit probleem en de verwarring eromheen begon met de introductie van ASP.NET 2.0 en IIS 7. IIS 6 had en heeft nog steeds maar één pijplijnmodus, en deze is gelijk aan wat IIS 7+ de “klassieke” modus noemt. De tweede, nieuwere en aanbevolen pijplijnmodus voor alle toepassingen die op IIS 7+ draaien, wordt de “geïntegreerde” modus genoemd.

Dus, wat is het verschil? Het belangrijkste verschil is hoe ASP.NET samenwerkt met IIS.

• Classic-modus is beperkt tot een ASP.NET-pijpleiding die niet kan communiceren met de IIS-pijplijn. In wezen komt er een aanvraag binnen en als IIS 6 / Classic is verteld, via serverconfiguratie, kan ASP.NET het aankunnen, dan geeft IIS het verzoek van ASP.NET uit en gaat verder. De betekenis hiervan kan uit een voorbeeld worden verzameld. Als ik de toegang tot statische beeldbestanden zou machtigen, zou ik het niet kunnen doen met een ASP.NET-module omdat de IIS 6-pijplijn die verzoeken zelf aankleedt en ASP.NET nooit die verzoeken zal zien omdat ze nooit zijn uitgedeeld . * Aan de andere kant, autoriseren van welke gebruikers toegang hebben tot een .aspx-pagina, zoals een aanvraag voor foo.aspx is triviaal, zelfs in IIS 6 / klassiek, omdat IIS altijd in handen is van die verzoeken om de ASP.NET-pijpleiding. In de klassieke modus weet Asp.net niet wat het niet is verteld en er is veel dat IIS 6 / klassieker het misschien niet vertelt.

• Geïntegreerde modus wordt aanbevolen omdat ASP.NET-handlers en modules rechtstreeks kunnen communiceren met de IIS-pijplijn. De IIS-pijplijn geeft niet langer het verzoek af aan de ASP.NET-pijpleiding, nu maakt het ASP.NET-code toe om rechtstreeks in de IIS-pijplijn en alle verzoeken die erop te haken. Dit betekent dat een ASP.NET-module niet alleen verzoeken kan observeren aan statische afbeeldingsbestanden, maar deze verzoeken kunnen onderscheppen en actie ondernemen door de toegang te ontzeggen, het verzoek te loggen, enz.

Het overwinnen van de fout:

1. Als u een oudere toepassing gebruikt die oorspronkelijk is gebouwd voor IIS 6, heeft u het misschien naar een nieuwe server verplaatst, er is mogelijk absoluut niets mis met het uitvoeren van de toepassingspool van die toepassing in de klassieke modus. Ga je gang, je hoef je niet slecht te voelen.

2. Aan de andere kant, misschien geef je je applicatie een opknapbeurt of het ging prima totdat je een bibliotheek van derden installeerde via NuGet, handmatig of op een andere manier. In dat geval is het heel goed mogelijk dat httpHandlersof httpModuleszijn toegevoegd aan system.web. Het resultaat is de fout die u ziet omdat validateIntegratedModeConfigurationstandaard trueis. Nu heb je twee keuzes:

   1. Verwijder de elementen httpHandlersen httpModulesuit system.web. Er zijn een paar mogelijke uitkomsten hiervan:
      • Alles werkt prima, een veelvoorkomende uitkomst;
      • Je applicatie blijft klagen, er is mogelijk een web.config in een bovenliggende map waarvan je erft, overweeg ook om die web.config op te schonen;
      • Je wordt moe van het verwijderen van de httpHandlersen httpModulesdie NuGet-pakketten blijven toevoegen aan system.web, doe maar wat je moet doen.
3. Als die opties niet werken of meer problemen opleveren dan het waard is, ga ik je niet vertellen dat je validateIntegratedModeConfigurationniet kunt instellen op false, maar je weet in ieder geval wat je doet en waarom het ertoe doet.

Goed gelezen:

• ASP.NET 2.0 Baanbrekende wijzigingen op IIS 7.0
• ASP. NET-integratie met IIS 7
• HTTP-handlers en HTTP-modules Overzicht

* Natuurlijk zijn er manieren om allerlei vreemde dingen in de ASP.NET-pijpleiding te krijgen van IIS 6 / klassiek via bezittingen zoals Wildcard-toewijzingen , als u dat soort dingen leuk vindt.

Antwoord 3, Autoriteit 4%

Als u nog steeds de HTTP-module moet gebruiken, moet u het configureren (.NET 4.0 Framework) als volgt:

<system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
       <add name="MyModule" type="[Namespace].[Class], [assembly]"/>
   </modules>
   <validation validateIntegratedModeConfiguration="false"/>
</system.webServer>

Antwoord 4, Autoriteit 4%

Ik heb dit probleem tegengekomen, maar had een andere oplossing. Het ging bij het bijwerken van de Control Panel>Administrative Tools>IIS Manageren keert de beheerde pijplijn van mijn app-site uit vanuit Integratednaar Classic.

Antwoord 5

Controleer of er een conflict is in uw IIS-authenticatie. d.w.z. u inschakelt de anonieme authenticatie en ASP.NET-nabootsing die beide ook de fout kunnen veroorzaken.

Antwoord 6

in uw web.Config Controleer of deze toetsen bestaan:

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>

Controleer ook de Asp.Net Impresonation = DisableIn IIS Site Authetication

Antwoord 7

Ik kwam dit probleem tegen en geïnspireerd door het antwoord van @Jeremy Cook, beet ik op de kogel om erachter te komen wat er in godsnaam voor zorgde dat de IIS 7 Integrated-modus mijn web.config niet leuk vond. Dit is mijn scenario:

1. Web API (versie 4.0.030506.0 ook wel de oude genoemd)
2. .NET 4.0
3. Attribuut Routing 3.5.6 voor Web API [spoiler alert: het was deze man!]

Ik wilde attribuutrouting gebruiken in een project dat (helaas) .NET 4 moest gebruiken en daarom geen Web API 2.2 kon gebruiken (waarvoor .NET 4.5 nodig is). Het goedbedoelde NuGet-pakket heeft deze sectie toegevoegd onder de sectie <system.web>:

<system.web>
<httpHandlers>
      <add verb="*" path="routes.axd" type="AttributeRouting.Web.Logging.LogRoutesHandler, AttributeRouting.Web" />
    </httpHandlers>
</system.web>

[Ik zeg goedbedoeld, omdat dit onderdeel vereist is in oudere versies van IIS]

Door deze sectie te verwijderen ben ik voorbij de HTTP 500.23!!

Samenvatting:
Ik onderschrijf Jeremy’s woorden dat het belangrijk is om te begrijpen waarom dingen niet werken in plaats van alleen maar “het symptoom te maskeren”. Zelfs als je het symptoom moet maskeren, weet je wat je doet (en waarom) 🙂

Antwoord 8

Dit werkte voor mij:

1. Verwijder de oorspronkelijk gemaakte site.
2. Maak de site opnieuw in IIS
3. Schone oplossing
4. Oplossing bouwen

Het lijkt erop dat er iets mis is gegaan toen ik de site oorspronkelijk maakte. Ik heb een hekel aan oplossingen die lijken op “Start uw machine opnieuw op en installeer vervolgens Windows opnieuw” zonder te weten wat de fout heeft veroorzaakt. Maar dit werkte voor mij. Snel en eenvoudig. Ik hoop dat het iemand anders helpt.

Antwoord 9

In mijn geval miste ik dll in de bin-map waarnaar werd verwezen in het bestand web.config.
Controleer dus of je een instelling in web.config gebruikte, maar eigenlijk geen dll hebt.

Bedankt

Antwoord 10

Het kostte me een paar uur om dit op te lossen omdat alle instellingen die ik hier vond over deze fout hetzelfde waren, maar het werkte nog steeds niet.
Het probleem was dat ik een map in mijn webservice had van waaruit het bestand naar het WinCE-apparaat moest worden gestuurd, nadat die map met Classic.NetAppPool naar een toepassing was geconverteerd, begon het te werken.

Antwoord 11

Met onderstaande stap is mijn probleem opgelost:

Open CMD-prompt met beheerdersrechten.

Uitvoeren: iisreset.

Hopelijk helpt dit.

Antwoord 12

De methode voor lokaal is de fout