ChatGPT解决这个技术问题 Extra ChatGPT

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode

I Installed DotNetOpenAuth SDK-3.4.5.10201.vsix and I can't get it working. It works locally (when I run as localhost) but when i try to publish it ain't working.

The IIS error message I get is

Error Summary HTTP Error 500.22 - Internal Server Error An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

AND

Module ConfigurationValidationModule Notification BeginRequest Handler StaticFile Error Code 0x80070032

then there are some suggestions on how to solve the problem:

Things you can try:

Migrate the configuration to the system.webServer/modules section. You can do so manually or by using AppCmd from the command line - for example, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Using AppCmd to migrate your application will enable it to work in Integrated mode, and continue to work in Classic mode and on previous versions of IIS. If you are certain that it is OK to ignore this error, it can be disabled by setting system.webServer/validation@validateIntegratedModeConfiguration to false. Alternatively, switch the application to a Classic mode application pool - for example, %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool". Only do this if you are unable to migrate your application. (Set "Default Web Site" and "Classic .NET AppPool" to your application path and application pool name)

But the problem is that I don't have access to the ISS server as I am not the owner of it. Is there any way to solve this?


K
KyleMit

The 2nd option is the one you want.

In your web.config, make sure these keys exist:

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

This shouldn't really affect your app's security. It just turns off the warning that says you have some configuration values that won't be used.
This isn't really overly sound advice if you have settings that won't be used then you should remove them.
@Seph, disagree that this isn't sound advice. Lots of NuGet installations (for example, DotLess) will add entries to sections that apply to integrated mode, and also duplicate that setting for non-integrated mode. This is called portability and allows your configuration to work regardless of whether you are using IIS7/integrated or classic. The only reason to leave this validation setting to true is so that you can leave your training wheels on and have IIS yell at you whenever you add a setting that won't work in integrated mode. This is for the inexperienced, but gets in the way.
This kind of configuration is annoying. @MS: there is a better way.
For those who prefer fixing errors over masking symptoms, I've posted an alternative answer. Concerning NuGet packages, why are we still targeting IIS 6/Classic?
J
Jeremy Cook

Adding <validation validateIntegratedModeConfiguration="false"/> addresses the symptom, but is not appropriate for all circumstances. Having ran around this issue a few times, I hope to help others not only overcome the problem but understand it. (Which becomes more and more important as IIS 6 fades into myth and rumor.)

Background:

This issue and the confusion surrounding it started with the introduction of ASP.NET 2.0 and IIS 7. IIS 6 had and continues to have only one pipeline mode, and it is equivalent to what IIS 7+ calls "Classic" mode. The second, newer, and recommended pipeline mode for all applications running on IIS 7+ is called "Integrated" mode.

So, what's the difference? The key difference is how ASP.NET interacts with IIS.

Classic mode is limited to an ASP.NET pipeline that cannot interact with the IIS pipeline. Essentially a request comes in and if IIS 6/Classic has been told, through server configuration, that ASP.NET can handle it then IIS hands off the request to ASP.NET and moves on. The significance of this can be gleaned from an example. If I were to authorize access to static image files, I would not be able to do it with an ASP.NET module because the IIS 6 pipeline will handle those requests itself and ASP.NET will never see those requests because they were never handed off.* On the other hand, authorizing which users can access a .ASPX page such as a request for Foo.aspx is trivial even in IIS 6/Classic because IIS always hands those requests off to the ASP.NET pipeline. In Classic mode ASP.NET does not know what it hasn't been told and there is a lot that IIS 6/Classic may not be telling it.

Integrated mode is recommended because ASP.NET handlers and modules can interact directly with the IIS pipeline. No longer does the IIS pipeline simply hand off the request to the ASP.NET pipeline, now it allows ASP.NET code to hook directly into the IIS pipeline and all the requests that hit it. This means that an ASP.NET module can not only observe requests to static image files, but can intercept those requests and take action by denying access, logging the request, etc.

Overcoming the error:

If you are running an older application that was originally built for IIS 6, perhaps you moved it to a new server, there may be absolutely nothing wrong with running the application pool of that application in Classic mode. Go ahead you don't have to feel bad. Then again maybe you are giving your application a face-lift or it was chugging along just fine until you installed a 3rd party library via NuGet, manually, or by some other means. In that case it is entirely possible httpHandlers or httpModules have been added to system.web. The outcome is the error that you are seeing because validateIntegratedModeConfiguration defaults true. Now you have two choices: Remove the httpHandlers and httpModules elements from system.web. There are a couple possible outcomes from this: Everything works fine, a common outcome; Your application continues to complain, there may be a web.config in a parent folder you are inheriting from, consider cleaning up that web.config too; You grow tired of removing the httpHandlers and httpModules that NuGet packages keep adding to system.web, hey do what you need to. If those options do not work or are more trouble than it is worth then I'm not going to tell you that you can't set validateIntegratedModeConfiguration to false, but at least you know what you're doing and why it matters.

Good reads:

ASP.NET 2.0 Breaking Changes on IIS 7.0

ASP.NET Integration with IIS 7

HTTP Handlers and HTTP Modules Overview

*Of course there are ways to get all kind of strange things into the ASP.NET pipeline from IIS 6/Classic via incantations like wildcard mappings, if you like that sort of thing.


+1 only solution is a not answer of your problem but solution with explanation that is perfect answer. What it is and why we need to change this, these questions of answer given by @Jeremy cook answer.
This explanation led me to fixing the issue for a small test site hosted in IIS 7.5 in Integrated mode. When I created a new MVC project, it added the httpModule, Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule in my Web.config. This is because I left the "Add Application Insights to project" option checked when creating a new ASP.NET Web Aapplication project. When I removed the httpModule from Web.config, the site worked without the error. Setting validateIntegratedModeConfiguration to false worked, but that was just a bandaid approach.
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode. This is yet another useless Microsoft error message. ASP.net has thousands of settings but Microsoft did not think to include the one causing the error in the error text. MS is being run by marketeers rather than engineers so don't expect things to improve any time soon. :-(
K
KyleMit

If you still need to use the HTTP Module you need to configure it (.NET 4.0 framework) as follows:

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

I think HttpModules property in system.web is for ASP 3.5 or before. For ASP 4 or above use modules in system.webserver
@HoyCheung its actually a matter of using Integrated or Classic pipeline, not what version of .Net, which decides whether to use system.web/httpModules or system.webServer/modules.
G
Gaʀʀʏ

I ran into this issue but had a different fix. It involved updating the Control Panel>Administrative Tools>IIS Manager and reverting my App site's Managed Pipeline from Integrated to Classic.


Agreed - this is the better option rather than just hiding the error! Make sure you're using the correct App Pool - should be Classic not Integrated
I am using visual studio 2012, how can i change app pool to classic.
This isn't a good solution if you want to be using all the new features available in Integrated Pipeline. This is like saying reverting to .NET 2.0 from 4.0 because of a problem.
To do this in IIS Manager, go to Application Pools in the tree on the left, double-click on the pool you want to change, and choose the pipeline mode.
J
Jim Yu

Check if there is any conflict in your IIS authentication. i.e. you enable the anonymous authentication and ASP.NET impersonation both might cause the error also.


N
Nil

In your web.config make sure these keys exist:

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

As well as check the Asp.Net Impresonation = Disable In IIS Site Authetication


S
Sudhanshu Mishra

I ran into this problem and inspired by @Jeremy Cook's answer, I bit the bullet to find out what the heck caused IIS 7 Integrated mode to not like my web.config. Here's my scenario:

Web API (version 4.0.030506.0 aka the old one) .NET 4.0 Attribute Routing 3.5.6 for Web API [spoiler alert: it was this guy!]

I wanted to use attribute routing in a project that (unfortunately) had to use .NET 4 and hence could not use Web API 2.2 (which needs .NET 4.5). The well meaning NuGet package added this section under the <system.web> section:

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

[I say well meaning, because this part is required on older versions of IIS]

Removing this section got me past the HTTP 500.23!!

Summary: I second Jeremy's words that it is important to understand why things don't work rather than just "masking the symptom". Even if you have to mask the symptom, you know what you are doing (and why) :-)


Thanks. I added AttributeRouting, including the Api Controller add-on NuGet package, and removing the section you indicated from web.config solved the problem. However, I am a little concerned because my MVC web app was already using .NET framework 4.5.
@RobertOschler if you are on .NET 4.5, you already have attribute routing built in AFAIK - you shouldn't need this NuGet?
Thanks and crap. There went a few hours today getting the AttributeRouting package running NuGet. I pulled it out and undid all the code "fixes" I added to make it work, and substituted the Web API 2 Route() attribute for the GET() attribute. Worked great. We really need an expert system these days just to help us with all these packages.
P
Paul

This worked for me:

Delete the originally created site. Recreate the site in IIS Clean solution Build solution

Seems like something went south when I originally created the site. I hate solutions that are similar to "Restart your machine, then reinstall windows" without knowing what caused the error. But, this worked for me. Quick and simple. Hope it helps someone else.


M
Mcan_Cicek

check these keys exist in your config file

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

T
Termininja

The method for local Is the error

https://i.stack.imgur.com/WJ6nx.png


Don't change this setting unless you really know what you're doing. This is almost never the correct answer.
If the goal is to run it in classic mode then this is a better solution than hiding the validation error that says it won't run right in integrated mode.
n
naveen rawat

In my case i was missing dll in bin folder which was referenced in web.config file. So check whether you were using any setting in web.config but actually don't have dll.

Thanks


M
Mladen Radosović

It took me few hours to solved this because all off the settings that I found here about this error were the same but it still didn't work. The problem was tha I had a folder in my web service from which the file should be send to WinCE device, after converting that folder to an application with Classic.NetAppPool it started to work.


S
Shaiju T

Below step solved my issue:

Open CMD Prompt with Admin Privileges.

Run : iisreset.

Hope this helps.