I am migrating Asp.net 2.0 web application from Windows Server 2003 to Windows Server 2012. I am getting following error in Windows Server 2012.
“HTTP Error 500.19 - Internal Server Error”.
Config Error: Unrecognized attribute 'enableCompression'
Error Code: 0x8007000d
Problem is in the following configuration element.
<add name="ScriptResource" enableCompression="false" preCondition="integratedMode"
verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"/>
When I remove the attribute enableCompression="false" the error is gone and even the ajax functionalities are working fine. Why is the attribute throwing error in Windows Server 2012 and what can we do to make it working in Windows Server 2012?
Application Pool setting is listed below.
Indeed, in looking at the official IIS documentation, it appears that the "enable compression" attribute does not exist for the "add" element of the handlers collection:
https://www.iis.net/configreference/system.webserver/handlers/add
This would explain the error, and why removing the "enable compression" attribute results in no further issues.
The truth is that you do not need this attribute any longer. If your application is working without it, then you are good to go. All this tag would do in ASP 2.0 is compress the javascript for a small performance gain in transferring the script to the client. If your javascript filesize is minimal, then this is a very negligible gain.
More importantly, notice that your original code calls enable compression = false. That means the original code had explicitly disabled compression for some reason. The default modern behavior would disable compression as well. Therefore, your new code is behaving the same without the attribute as the original did, with respect to compression.
Finally, the modern method of enabling compression / caching for javascript embedded as assembly resources is to utilize the scriptResourceHandler Element.
Example:
<scriptResourceHandler
enableCompression="true|false"
enableCaching="true|false" />
See the MSDN documentation here: https://msdn.microsoft.com/en-us/library/vstudio/bb513840(v=vs.100).aspx
Related
I am working on a website built using VB.Net and ASP.Net (VS2019 .Net 4), and I am trying to add an ASP.Net Chart control, but i'm having lots of problems. My colleague has helped me with some of them, and now instead of just throwing an error it is generating the chart but isn't able to display it. I can see the image it has created on my machine, but if i right-click it on my page, and select 'Open image in new tab', i get this:
HTTP Error 500.21 - Internal Server Error Handler "ChartImg" has a bad
module "ManagedPipelineHandler" in its module list
Most likely causes: Managed handler is used; however, ASP.NET is not
installed or is not installed completely. There is a typographical
error in the configuration for the handler module list. During
application initialization, either the application initialization
feature has set skipManagedModules to true, or a rewrite rule is
setting a URL that maps to a managed handler and is also setting
SKIP_MANAGED_MODULES=1.
Things you can try: Install ASP.NET if you are using managed handler.
Ensure that the handler module's name is specified correctly. Module
names are case-sensitive and use the format
modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule".
Ensure that any application initialization rewrite rules set
SKIP_MANAGED_MODULE=0 when setting a URL that maps to a managed
handler (such as .aspx, for example.) As an alternative, ensure that
application initialization rewrite rules map the request to an
unmanaged handler (for example, to an .htm file, which is mapped to
the StaticFileHandler.)
Detailed Error Information: Module IIS Web Core Notification
ExecuteRequestHandler Handler ChartImg Error Code 0x8007000d
Requested URL
http://localhost:80/WWW_TFS/GDNv1_Project/trunk-url/gDN/gDN_Support/ChartImg.axd?i=charts_0/chart_0_0.png&g=5850a0c2661a4402a1f0a33a33ec482a
Physical Path
C:\WWW\WWW_TFS\GDNv1_Project\gDN\gDN_Support\ChartImg.axd Logon
Method Anonymous Logon User Anonymous
After some more investigation with my colleague it looks like ChartImg.axd is missing. I've googled the issue but without any luck. Is there some kind of installation I need to do? Or can someone send me a copy of ChartImg.axd?
UPDATE: This issue is not fixed, but now i've started getting this error:
CSLLib.CSLException: Chart cannot save an item after 10 attempts.
---> System.IO.IOException: Chart cannot save an item after 10 attempts.
Everything i can see in Google suggests lack of disk space - but i have over 500GB of space left so that can't be the problem. Is there anything else that might cause this?
UPDATE: I have found that by changing the ChartImageHandler AppSetting to 'storage=memory;deleteAfterServicing=true;' the save issue goes away. The chart image is still not being displayed though.
Phew! Managed to solve this myself. I wasn't setting the control up correctly, so I made these changes and it worked:
Removed this from the asp.net page
<%# Register assembly="System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" namespace="System.Web.UI.DataVisualization.Charting" tagprefix="asp" %>
Removed all web.config settings relating to asp.net chart
Removed the control from the page
Dragged the control on to the page in design view
Configure the chart control
Added a row to AppSettings in the web.config
key="ChartImageHandler" value="storage=memory;deleteAfterServicing=true;"
Added a row to httpHandlers in web.config
path="ChartImg.axd" verb="GET,HEAD,POST" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"
Hope this helps others in the future
My company supports a very old DNN4 site. I am attempting to get a local copy running on my Windows 8 computer so that I can test a set of changes requested by the client.
I have added the site to my Default web site in IIS, and have given the site it's own app pool:
When I try to browse to the site to actually install it, however, I get this error (which looks to be complaining about the handlers section of the web.config).
full error text
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information:
Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
Config File \\?\C:\Users\Public\dnn4\web.config
Requested URL http://localhost:80/dnn4
Physical Path C:\Users\Public\dnn4
Logon Method Not yet determined
Logon User Not yet determined
Config Source:
75: </modules>
76: <handlers>
77: <add name="AJAX_ScriptResourceHandler" path="ScriptResource.axd" verb="GET,HEAD" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="integratedMode,runtimeVersionv2.0" />
You really shouldn't setup the site under your USERS folder, I would recommend you do it outside of the Users folder in a folder that won't have restrictive permissions.
Yesterday we pushed out some changes including the addition of ASP.NET MVC 3 (routing, configuration, etc.) and our ASP.NET charting controls stopped working. In our development environment the ASP.NET chart control works as expected. However in our test and production env. we are getting errors from the DefaultControllerFactory as no path can be found for the axd url - "Pages/Secured/ChartImg.axd"
We've tried comparing any differences with the IIS configuration and web.config and made sure the system.webserver node has the correct handler as so...
<add name="ChartImageHandler" preCondition="integratedMode" verb="GET,HEAD,POST" path="ChartImg.axd" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
This has not helped and we are not sure what else could be wrong. It appears to be the chart handler is not setup correctly, but we have no way of knowing why.
Any help would be greatly appreciated.
It turns out we had a compiler directive on the user control that switched the ImageStorageMode property of the charting control based on debug/release builds. This explained why it was only working on our dev environments that got a debug build and not the other environments. After discovering that we used the fix from this question ASP.NET Charting Control no longer working with .NET 4, which fixed the routing issue we had for the handler when the ImageStorageMode was set to UseHttpHandler.
My Asp.net application is hosted over Azure Cloud,
In that application I do have a Java Chat control, which has its server on Linux,
now I have created a HTTPHandler to redirect that chat request to the Linux server, but some how it doesn't work over the Cloud environment (though it works very well on web environment)
it shows the below error
Microsoft Visual Studio
Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the IIS worker process for URL 'http://127.255.0.0:82/' for role instance 'deployment16(315).Cloud.AnotherHttpHandler_IN_0'. Unable to start debugging on the web server. See help for common configuration errors. Running the web page outside of the debugger may provide further information.
Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start Without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation.
I have even put the Handler under System.webServer as well in the web.config file, see below code
<system.web>
<httpHandlers>
<add verb="*" path="http-bind/*"
type="HelloWorldHandler"/>
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<add verb="*" path="http-bind/*" name="HelloWorldHandler" type="HelloWorldHandler"/>
</handlers>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
I don't know what restricts it over the cloud environment.
Please take a look at this question to see how to configure httpHandlers for running in Azure.
Most importantly - remove the httpHandlers section under the system.web and leave only handlers under system.webServer. Then add also the resourceType="Unspecified" attribute to the handler declaration. This should solve your issue.
I too had same problem.
I fixed it in following way .
The Problem was my machine is 32 bit and the azure server is 64 bit.
In Order to solve the problem i only changed Enable 32 bit option in
the advance setting of application pool. And the Original code worked
out fine.
i got this help from this Link
Sorry for the vague title, as I really can't explain this problem succinctly.
Basically I have Windows Server 2008 x64, IIS7, ASP.NET 2.05, and I have a site running in a Classic AppPool (and no I cannot run in Integrated).
When trying to load an *.aspx file for the first time (i.e. after installing site, restarting the server, etc) I get this error:
HTTP Error 500.0 - Internal Server Error
The page cannot be displayed because an internal server error has occurred.
Module: IsapiModule
Notification: ExecuteRequestHandler
Handler: PageHandlerFactory-ISAPI-2.0-64
Error Code: 0x800710dd
Logon Method: Anonymous
Logon User: Anonymous
The handler is the default IIS7 one:
<add name="PageHandlerFactory-ISAPI-2.0-64" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0" />
I even tried adding in my own handler for aspx that looked like this:
<add name="aspx" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
The only thing that did was change the Handler part of the error notification to say IsapiModule.
The odd thing is that this error only occurs the first time (or when the server has been idle for hours). As soon as I see this error, if I refresh the page it's all fine and dandy again.
I even tried deleting the web.config file and that did absolutely nothing.
I can't seem to find a single answer for this problem on the internet.
Edit: I enabled Failed Request Tracking and this is what it shows:
MODULE_SET_RESPONSE_ERROR_STATUS
Warning ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="The operation identifier is not valid.
(0x800710dd)", ConfigExceptionInfo=""
And right before the error it shows:
NOTIFY_MODULE_START ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", fIsPostNotification="false", fIsCompletion="false"
Now when I compare this to a successful run the difference is that the error produces MODULE_SET_REPONSE_ERROR_STATUS whereas the successful run doesn't (and then goes on to produce the correct HTML output).
Edit: I took a simple app and tried to get that running and I received the same error. But when the apppool was in Integrated mode it ran fine! Unfortunately I cannot migrate our app to integrated for reasons I cannot specify but I narrowed it down to the app pool. Also I don't have to restart the server to repro the error, instead recycling the app pool will do.
Summary:
- As mentioned below there's nothing in the Event Logs to indicate failure. I combed through all logs in Event Viewer
Best thing to do is enable Failed Request Tracing in the IIS section of the web site. You can then enable some filters which give you much more detailed information.
You can do this through the IIS Manager. Click your web site, then in the IIS section of the Features View, double-click "Failed Request Tracing Rules".
It's most likely not already enabled, so from the rightmost column select "Edit Site Tracing". Check the "Enable" checkbox and make note of the directory.
You can then either add a rule in that screen or go to your application and open the "Failed Request Tracing Rules" IIS feature from there.
From the rightmost column again, click "Add..." Then go through the wizard and set up the logging.
Load your page that's throwing the error again. Go to the logging folder and double-click the XML file. There's an XSL in that directory. Don't nuke it, cuz once it's gone it won't get recreated. :s The transformed XML will show you more info than you can possibly hope for.
I just this evening used that to discover a custom error page that I configured was using ~/ instead of "/", causing IIS to die.
When ASP.NET application starts loading, you may have some code that may take too long to execute, probably too big application variables or resources initialization.
The best way is to setup some sort of ping monitor, lot of ISPs provide pinging monitors that can monitor your html url on regular interval, that may help keeping your application all time alive !!
Try looking into initialization procedures of your asp.net app, you may want to increase some timeout values !!
Sounds like something while starting up the app pool. But it should be logging the actual error in the event viewer. Or you could turn CustomErrors off to debug it. The thing is, you need to see the actual error to figure out what's going on.
Do you have an unhandled exception handler in your ASPX code (something like Global Application_Error)?
You should be able to catch the exception and log it if it's coming from the ASPX code (which is quite possible).
I've seen sporadic errors like this before, I just can't remember the underlying cause at the moment.
How to: Handle Application-Level Errors
Well I don't know what was causing this but a clean install of the VM I was using fixed it. Hurrah!
You must add this script on your web.config:
<system.webServer>
<handlers>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</handlers>
I hope this help ! Cheer.