This error has been reported elsewhere on stackoverflow, but none of the answers seem applicable to my situation.
I'm publishing a simple .NET web service (.asmx) and when I check the link in production, I'm met with the famous error:
"It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS."
I've gone through the basics already, namely these three most popular hints:
1/ The directory has been created as an "Application" by right-clicking in IIS, et cetera. It's running in its own Application pool.
2/ There is no subdirectory containing any superfluous web.config files. It's just the one web.config.
3/ I've made sure that the namespace matches up with the web service definition, all that basic stuff. At any rate, the project runs fine locally and also runs fine when deployed to a test server. This is leading me to think 'permissions issue' on the prod server, but I'm at a loss since the normal IIS sites run fine.
So I guess what I'm asking is: is there a fourth-most-popular cause of this error that I"m missing?
Oh, the Web Service Application is set to allow web service calls for all versions of .NET installed on IIS.
Also, I'd be happy to leave this legacy approach behind and ditch the .asmx for WCF; however this is the piece of code I'm tasked with rolling out at present.
Thanks!
You need to make sure that your have the proper .net framework version selected in you Application Pool. You can check this by going into IIS manager and going to the Application Pools node. Right click on the application pool that is attached to the website that contains your service and select "Basic Settings" (this choice should be in the left hand column of the window too). Then from the drop down select the proper version of the framework. You might need to create a new application pool specifically for the child application if they need to operate on different versions of the framework.
If the parent site is using .net 4.0 your webservice is probably inheriting that or vice versa (2.0).
So in short, try switching your application pool to a different framework version and see if that clears it up.
Related
Trying to migrate a legacy ASP.NET WebForms/MVC hybrid application from Cloud Services to App Services. All runs fine locally in debug Visual Studio (V2022). The app is predominantly webforms but MVC has been retro fitted and is in use for some pages. It's using .NET Framework 4.8.
Deploying directly from Visual Studio. We have created a new App Service and App Service Plan. The site appears to deploy correctly but the endpoint returns the below as raw text, i.e. the web browser doesn't even attempt to render it, presumably as there is no header information specifying html content-type:
Have checked the configuration for the app service, all appears normal (same as other app services that run quite normally). It's set to ASP.NET 4.8 with all the other standard defaults. The default documents includes Default.aspx which matches the application. The application is using Forms authentication and defaults to a Login.aspx page. We have tried removing this and redeploying but we still get the same result. Configuration and Management diagnostics section on the Azure portal shows no significant errors.
In Kudu (advanced settings) if I access the debug console, I find my app is deployed to c:\home\site\wwwroot> as expected, however if I click "Site Root" it flips me to c:\local>
Could it be IIS is pointing to the wrong path for the site?
In the end found some rogue code that was causing the issue. The different paths under Kudo was a red herring.
To diagnose the problem we moved from VS deployment to CI deployment and still had same issue. This meant it was not publishing settings. We compared web config with other solutions that ran fine as app services and found no significant differences. This ruled out IIS settings from web.server section. We checked for errors on the app and found no errors being reported.
In the end we trawled through the code and eventually found something that was URL specific.
My IIS nested application hangs when I browse from IIS -- browser's busy spinner just spins forever.
I added a 2nd VS ASP.NET web app project to my primary web site, as a IIS 'nested' application.
The 2nd web app project debugs from VS OK and opens browser to it.
Is it possible to break in with debugger to see if code is in a loop or something?
BACKGROUND:
IIS 6.5 on my Windows Server 2012 R2 Azure VM
VS is 15.3.4
IIS > Sites > my primary web site > TEST (this Application added to primary) > Advanced Settings:
App Pool = DefaultAppPool
Physical Path = path to TEST's VS project
Virtual Path = /TEST
IIS 6.5...
Test Settings...
If you aren’t sure what issue is causing your website to spin forever, look at the live requests within IIS. From the IIS Management Console select Worker Processes.
Right click on your running application pool and select “View Current Requests”.
This will bring up a list of the currently running ASP.NET web requests as shown below.
I would suggest looking at the “Time Elapsed” to see if you have a lot of requests that are taking a very long time. You should also see if they are all stuck in the same module. This could be a clue that the issue is all related to ASP.NET Sessions or some other step within the ASP.NET request life cycle. You may also be able to identify a specific URL that is causing the problem.
Also in addition to that , I would highly suggest using a logging framework like NLog, log4net or Serilog. You can then send them to a log management service to make it easier to search them across multiple servers. Application logs are good way to trace your application trace across server.
If your web request is returning a 500 Internal Server Error, you need to check your server-side logs for exceptions. As mentioned above about application logs in general, it is important to have good exception handling in place and properly logging all of your errors.
Also you could use some open source diagnostic tool like Glimpse to trace. Glimpse is a thriving and growing family of open source NuGet packages that provides detailed performance, debugging and diagnostic information for ASP.NET apps. It's trivial to install, lightweight, ultra-fast, and displays key performance metrics at the bottom of every page. It allows you to drill down into your app when you need to find out what's going on at the server. Glimpse provides so much valuable information we recommend you use it throughout your development cycle, including your Azure test environment. While Fiddler and the F-12 development tools provide a client side view, Glimpse provides a detailed view from the server. You can try using that too.
Hope it helps.
Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
I want to run my new web application with forms authentication under the ASP.NET Development WebServer (Cassini), but not at site root "/" (rather, at the path it will reside in production; "/New").
However, the build process gives the error:
"It is an error to use a section
registered as
allowDefinition='MachineToApplication'
beyond application level. This error
can be caused by a virtual directory
not being configured as an application
in IIS.
New.MvcWeb\obj\debug\csautoparameterize\original\web.config"
Now, I understand what it is saying. I have forms authentication enabled in my web.config in a virtual directory. The error goes away when I remove the web.config, or remove the "virtual path: /New" debugger configuration, or move debugging from Cassini to IIS and manually create an application at "/New".
But it is only a 'virtual' directory in the mind of the Build System. The path IS application-enabled in a production IIS setting. Also, if I remove the web.config, Cassini will happily publish "http://localhost/New" as an application (for example, Server.MapPath("~") returns my project directory without the "/New" suffix); however I need forms authentication (an application-level web.config parameter) enabled in it.
How I can avoid this build error while retaining my desired features?
More Details
The project is currently configured for "file-system" site development. This and Cassini are supposed to make it easier for my content creators to participate in development and testing with their local copy of VS2010, without having to install IIS on their Windows PCs. I will also one-click publish to my local IIS for testing, then package/publish/deploy to public test, then finally publish to production. In my mind I imagine Cassini being a very helpful part of this whole process.
VS2010, MVC application, file-system site project
Project Settings:
* ASP.NET 4.0
* Use Visual Studio Development Server
* Virtual Path: /New
web.config snippet:
<authentication mode="Forms">
<forms loginUrl="~/../login.html" timeout="30"/>
</authentication>
I'd generally argue apps should never care if they are running as the root or in a sub-uri. I'd also say that, in 2010, with IIS Express coming, it makes no sense investing any time nor heartache in fighting cassini. That should support your requirements much better.
EDIT FOR MORE DETAILS
Interesting updates about IIS express. We do some of the same things for our design types -- we'd rather they implement the designs rather than the programmers lose hours of their life pursuing individual pixels. We found it easiest to basically treat the designers' machines as essentially continuous integration build agent. They run IIS and build using the same command line build script the CI boxes do. Works surprisingly well. In both cases you have a machine that can't care for itself, so everything needs to be scripted. The IIS bit gets setup once generally as we keep it pretty simple and it rarely needs tweakage with modern versions of .NET. Hope this helps.
So, having learned that Cassini actually does run paths as applications [i.e. Server.MapPath("~") returns the project root folder, and Server.MapPath("/") may not exist], it really becomes strictly a build error.
With a better problem definition, I now see other people also have this error in MVC projects with MvcBuildViews and One-Click-Publish. Here are some articles on how to avoid it:
allowDefinition='MachineToApplication' error when publishing from VS2010 (but only after a previous build)
http://connect.microsoft.com/VisualStudio/feedback/details/556312/mvcbuildviews-does-not-play-well-with-one-click-publish
I've been trying to migrate a fairly large web application from IIS6 to IIS7 the past few days, but every time it seems like we're about done, IIS7 fails to load aspx pages.
The application is a .net 3.5 webapp that makes heavy use of reflection and web services. We use 2 main components (each with their own web site in IIS7 although they share an application pool): the web UI (aspx pages), and the webAPI (asmx pages).
The webAPI portion runs perfectly (as far as we can tell; there are a few things we can't test from the browser), and the web UI pages load static HTM pages just fine. The problem is that once we attempt to view an aspx page (any aspx page), the whole thing just comes to a halt; no error is logged in the event viewer until a few minutes later when we get an IIS 5010 warning (worker process ignoring ping).
We've attempted to migrate the app in two different ways:
Manually: we moved all the necessary files and set up the virtual directories then converted them to Web Sites. Result: the worker process took up 100% of a single core and spun forever (until terminated manually)
Automatically: Utilizing the MSDeploy application from www.iis.net we archived the entire IIS6 web server and unpacked it into a blank IIS7 install. We had to turn off Forms Auth to get rid of a 401.2 error, but after that the result here was that the webAPI component still works just fine, but instead of the web UI worker process taking up 100% of a single core, it grew to about a third of the required memory then hung out doing nothing.
Either way, what happened from the user's point of view was the same.
Unfortunately, we can't even attach a debugger to the worker process because it doesn't seem to be loading managed code.
Details:
.net framework: v3.5
CLR version: v2.0
IIS Authorization mode: Anonymous
OS arch: x64
App arch: x86
Happens with both classic and integrated pipelines
Notes:
New web projects seem to work just fine in IIS7 and, of course, xml web services are also fine
temporary DLLs are created and stored in the temporary ASP.net DLLs folder, even though the worker process never seems to contain managed code.
New pages added to the web UI project also show the same behavior (Didn't hurt to try)
Updates:
We've narrowed down the problem to a single assembly. It's a wrapper for a third party web control. I'm looking into replacing it, we'll see if it fixes the problem.
http://support.softartisans.com/kbview.aspx?ID=1318
Turns out it was an issue with the vendor control. Wish their solution actually worked though...
Try to re-register ASP.NET:
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
The typical command line syntax would be to command line to the ASP.NET 2.0 version of your framework and type:
aspnet_regiis -i
Are you using the "Classic" Pipeline Mode for your Application Pool. The "Integrated" one is the default in IIS7 and it introduced changes in terms of configuration. (One example is HttpHandlers that need a different configuration in web.config).
The "Classic" one mimics the IIS6 application pool, and should work with the same configuration as for IIS6.
If you prefer to use the Integrated Pipeline, there are some tools that will automatically try to convert you configuration files.
Scott Hanselman covers some of these tools in his blog post.