In ASP.NET some scripts are fetched by default from ScriptResource.axd and WebResource.axd (These scrips are: MicrosoftAjaxTimer.js, MicrosoftAjax.js, MicrosoftAjaxWebForms.js in System.Web.Extensions, and DetailsView.js, Focus.js, GridView.js, Menu.js, SmartNav.js, TreeView.js, WebForms.js, WebParts.js and WebUIValidation.js)
For instance a script file called ScriptResource.axd?=someGuid.js will be loaded whenever a page with a validator is present.
How do I use my local WebUIValidation.js file instead? (in ASP.NET 4.5)
What I've tried:
I've read Scott Hanselman's old post on this. His idea is using a scriptmanager to override each script with a scriptreference to a local version like this
<asp:scriptreference name="WebForms.js" assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
http://www.hanselman.com/blog/ASPNETAjaxScriptCombiningAndMovingScriptResourceaxdsToStaticScripts.aspx
I've tried that, but it doesn't seem to work for WebUIValidation.js. As soon as a page with a validator is loaded, a ScriptResource.axd js file containing the validation script will always be fetched.
Hanselman did write a warning (this prior to the release of .NET 4) "NOTE: There're a few controls that don't use the ScriptManager, so they can't have their JavaScript suppressed. So far the Validators are the main culprits. I'm talking to the team and we'll see if we can't get that fixed in 4.0"
But I'm not sure what to do with that information, and I can't find any more recent updates on the subject.
I've also tried replacing the script by using one from my own CDN. I enabled cdn on my Scriptmanager
and in the Application_Start of global.asax I've tried setting a custom cdn path
ScriptManager.ScriptResourceMapping.AddDefinition("WebUIValidation", new
ScriptResourceDefinition
{
Path="~/Scripts/WebForms/WebUIValidation.js",
CdnPath = "https://dl.dropboxusercontent.com/u/4486136/WebUIValidation.js",
LoadSuccessExpression = "window.Sys",
CdnSupportsSecureConnection = true
});
This just results in 2 script instances being loaded, both from the dropbox AND the default cdn (ajax.aspnetcdn.com). The default cdn is loaded last though so it will be the only one executed.
So apparently, it doesnt recognize that I'm trying to overwrite.
I've also tried removing ScriptResource.axd completely, by adding the following to the in my Web.Config
<httpHandlers>
<remove verb="GET,HEAD" path="ScriptResource.axd" />
</httpHandlers>
That doesn't seem to do anything.
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
In an ASP.NET 4.6 project I have followed the instructions for enabling Browser Link against a static HTML file (used to bootstrap angular) by entering the following in the proper place in web.config.
<add name="Browser Link for HTML" path="*.html" verb="*"
type="System.Web.StaticFileHandler, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
resourceType="File" preCondition="integratedMode" />
This is a very simple web.config and I am fairly certain it is not an issue of the handler not being added properly as described here.
However when looking at the html source in the browser, it does not contain the script tags for Browser Link described in this article.
I was under the impression that if there was a problem while loading handlers, the application would fail to load.Is there anyway to troubleshoot handlers being loaded in ASP.NET?
I am developing an Angular module for a CMS, so I was not including the <body> tag in my index.html.
It turns out, the <body> tag must be present. I am guessing the handler is using XPATH to insert the Browser Link script tags.
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
IIS Express is producing 403.14 Forbidden errors when a URL that would otherwise be handled through ASP.NET URL routing happens to correspond to a physical folder in my ASP.NET project. (The folder contains only code, and it's coincidental that the folder name happens to match the URL of a page; my URL structure is determined dynamically by a database, and users can edit that structure, so although I could just rename my project folder, in general I can't prevent this sort of collision occurring.)
This seems to be happening because the DirectoryListingModule steps in to handle the request, and then promptly fails it because directory browsing is disabled. I've tried removing this:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFile" path="*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
That removes the default StaticFile handler configuration, which has modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", and replaces it with a configuration that provides just the feature I want. (I want static file serving, but I have no need for directory listing or default documents in this app.) But the effect seems to be that IIS then produces a completely empty (0 byte) response (with a 200 status) when I hit the offending page.
So next, I tried configuring the StaticFile handler to handle only the specific physical folders that I want to make available:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFileCss" path="style/*.css" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
<add name="StaticFileScripts" path="Scripts/*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
But when I hit the offending URL, this then produces a 404.4 - Not found error, with a message of The resource you are looking for does not have a handler associated with it.. (The Detailed Error Information on the error page says that we're in the IIS Web Core module, during the MapRequestHandler notification, the handler is Not yet determined, and there's an Error Code of 0x80070002, which is a COM HRESULT that corresponds to the Win32 ERROR_FILE_NOT_FOUND error.)
The mystifying thing is that it's not even bothering to ask ASP.NET whether it has a handler for it. IIS seems to be deciding all by itself that there definitely isn't a handler.
This only happens when there's a folder that matches the URL. All other resources with dynamically-determined URLs work just fine - IIS asks ASP.NET for a handler, ASP.NET's routing mechanism runs as normal, and if the URL corresponds to one of my dynamically defined pages, it all works fine. It's just the presence of a physical folder that stops this all from working.
I can see it's IIS doing this because I get one of the IIS-style error pages for this 404, and they have a distinctive design that's very different from the 404s produced by ASP.NET. (If I try to navigate to a URL that neither corresponds to a physical folder, nor to a dynamic resource, I get a 404 page generated by ASP.NET. So normally, IIS is definitely handing requests over to ASP.NET, but IIS is definitely getting in the way for these problematic resources.)
I tried adding this inside my <system.WebServer>, in case the problem was that IIS has decided that requests corresponding to physical folders do not meet the managedHandler precondition:
<modules runAllManagedModulesForAllRequests="true">
But that doesn't appear to help - it still doesn't get ASP.NET routing involved for URLs that correspond to physical folders. In any case, it would be suboptimal - I would prefer not to have managed handlers run for the content that I definitely want to handle as static content. I effectively want ASP.NET URL routing to be used as a backstop - I only want it to come into play if the URL definitely doesn't refer to static content.
I don't understand why ASP.NET isn't even asking ASP.NET what it thinks in this scenario. Why is it not calling into ASP.NET during the MapRequestHandler phase if there's a physical folder that happens to correspond to the URL?
When a physical file or folder with the same URL as the route is found, routes will not handle the request and the physical file will be served.
Althrough you can change this behavior by setting the RouteExistingFiles Property from the RouteCollection object to true.
Take a look at the MSDN page Scenarios when routing is not applied
I have a module in an ASP.NET MVC application. The module is working fine, but it's firing for every type of file including static content even though I have:
<modules runAllManagedModulesForAllRequests="false">
<add name="MyModule" ... / >
</modules>
The module hooks AcquireRequestState and PostRequestHandlerExecute events and both show static content firing (.htm, .css, .png etc.).
I was under the impression that runAllManagedModulesForAllRequests="false" should keep modules from firing on non-ASP.NET content.
To clarify:
I can set preCondition="managedHandler" like this:
<add name="MyModule" type="MyApp.MyModule" preCondition="managedHandler" />
and get my module to fire only managed requests.
However, I'm trying to understand why the IIS pipeline in general is firing managed module hits for every request. I think this used to work just fine in older versions where unless runAllManagedModulesForAllRequests="true" it wasn't firing unmanaged content into ASP.NET modules.
Running on IIS8 on Windows 8 64 bit mode, with integrated pipeline mode.
Update:
After some more research it turns out that the following is true:
if runAllManagedModulesForAllRequests="true" all modules - regardless of their preCondition attribute setting fire on all requests. This also true for Application_XXXX events implement on the HttpApplication
runAllManagedModulesForAllRequests="false" has no effect of keeping unmanaged requests from hitting modules, unless preCondition="managedHandler" is set
runAllManagedModulesForAllRequests="false" does affect Application_XXXX events, causing those events to only fire on managed requests then. IOW, Application_XXXX behaves as if the 'module' implementation had a preCondition="managedHandler"
For more detailed information on this I posted a blog entry:
http://www.west-wind.com/weblog/posts/2012/Oct/25/Caveats-with-the-runAllManagedModulesForAllRequests-in-IIS-78
In IIS7 Microsoft introduced a new way of developing modules and handlers by using managed (.NET) code, not just native code. Problem is switching a request between managed and native code is very expensive, so Microsoft introduced the preCondition="managedHandler". It flags the module as only available for managed content requests (.aspx, .asmx, ...) so IIS avoids firing it for static content.
Now, you can have a situation where you want to modify an static content request, such as minifying JavaScript on the fly. You can write the module using C# and compile it as a managed module, but you want it to be fired for static content, so you simply do not mark it as managedHandler.
Finally, runAllManagedModulesForAllRequests="true" is used to override preCondition="managedHandler" so all of them get fired.
There is more info available at:
http://www.iis.net/learn/get-started/introduction-to-iis/iis-modules-overview#Precondition