ASP.NET生成eurl.axd Http异常错误的处理方法

在IIS6中同时启用了ASP.NET 2.0 和 ASP.NET 4.0 后，网站程序可能会出现如下错误：“ System.Web.HttpException: Path ‘//eurl.axd/‘ was not found. ”

错误发生的原因是当ASP.NET检测到Web站点配置为使用ASP.NET 4.0，本地ASP.NET 4.0 的组件会传递一个不能扩展的 URL到ASP.NET的管理程序作进一步处理。但是，如果一个低于ASP.NET 4.0 的网站配置为使用ASP.NET 2.0，处理这样不能扩展的 URL 时，URL的修改结果中会包含字符串“eurl.axd”，修改后的URL会被发送到 ASP.NET 2.0应用程序。

ASP.NET 2.0中是不能识别“eurl.axd”的。因此ASP.NET 2.0会尝试查找一个文件名为“eurl.axd”的文件并执行它。因为没有这样的文件，所以会请求失败，Http异常并抛出带有字符串“eurl.axd”的错误。

有三种方法可以解决这样的问题：

1.如果网站程序不需要ASP.NET 4‎.0 的支持，那么可以直接配置网站使用ASP.NET 2.0。

2.如果网站程序需要ASP.NET 4‎.0的支持，就需要将该网站下使用ASP.NET 2.0的虚拟目录移动到其他网站。

3.如果上面两种方法都不适用于你的实际情况，那么就只能用这种方法了：

打开注册表找到“HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\ASP.NET\\4.0.30319.0”，添加键值名为“EnableExtensionlessUrls” 类型为“DWORD”的键值，并设置值为“0”。然后在cmd中运行“IISRESET”，重启IIS以读取注册表修改后的内容。注：此项修改就是关闭ASP.NET 4‎.0对无扩展URL的处理，若将此项键值设为“1”则开启。

赞 (0)

相关推荐

  • asp.net服务器上几种常见异常的解决方案.

    asp.net服务器上几种常见异常的解决方案.

    如下 (1)配置Asp.net站点ISS报出:服务器应用程序不可用.具体异常信息如下: 服务器应用程序不可用 您试图在此 Web 服务器上访问的 Web 应用程序当前不可用.请点击 Web 浏览器中的"刷新"按钮重试您的请求. 管理员注意事项: 详述此特定请求失败原因的错误信息可在 Web 服务器的系统事件日志中找到.请检查此日志项以查明导致该错误发生的原因. 我检查ISS上其他的配置.发现全部都是Asp编写的网站.属性中查看运行的环境竟是Asp.net Framework 1.1版本

  • asp.net Http异常eurl.axd出错信息解决方法

    错误发生的原因是当ASP.NET检测到Web站点配置为使用ASP.NET 4.0,本地ASP.NET 4.0 的组件会传递一个不能扩展的 URL到ASP.NET的管理程序作进一步处理.但是,如果一个低于ASP.NET 4.0 的网站配置为使用ASP.NET 2.0,处理这样不能扩展的 URL 时,URL的修改结果中会包含字符串"eurl.axd",修改后的URL会被发送到 ASP.NET 2.0应用程序. ASP.NET 2.0中是不能识别"eurl.axd"的.因

  • asp.net 错误：0x8007000B 异常的解决方法

    asp.net 错误：0x8007000B 异常的解决方法

    在Asp.net里调用非托管的.dll文件时,出现"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"这样的错误提示. 在c# winform的程序里大概知道该错误:0x8007000B是由于本机操作系统是64位,调用的DLL是32位而产生的错误,所以只需将网站的连接池的设置改成支持32位程序运行就可以解决问题了. 1.打开IIS管理器

  • asp.net开发中常见公共捕获异常方式总结(附源码)

    本文实例总结了asp.net开发中常见公共捕获异常方式.分享给大家供大家参考,具体如下: 前言:在实际开发过程中,对于一个应用系统来说,应该有自己的一套成熟的异常处理框架,这样当异常发生时,也能得到统一的处理风格,将异常信息优雅地反馈给开发人员和用户.我们都知道,.net的异常处理是按照"异常链"的方式从底层向高层逐层抛出,如果不能尽可能地早判断异常发生的边界并捕获异常,CLR会自动帮我们处理,但是这样系统的开销是非常大的,所以异常处理的一个重要原则是"早发现早抛出早处理&q

  • 在ASP.NET 2.0中操作数据之三十八：处理BLL和DAL的异常

    在ASP.NET 2.0中操作数据之三十八：处理BLL和DAL的异常

    导言 在DataList里编辑和删除数据概述里,我们创建了一个提供简单编辑和删除功能的DataList.虽然功能上已经完整了,但是对用户来说是不友好的.因为所有在编辑和删除过程中产生的异常都是未处理的.比如,遗漏了输入product的name,或者编辑product时在price里输入"Very affordable!",都会抛出异常.而由于在代码里未捕捉这些异常,页面会显示ASP.NET运行时的详细错误信息. 如我们在在ASP.NET页面中处理BLL/DAL层的异常里看到的,如果BL

  • 在ASP.NET 2.0中操作数据之十八：在ASP.NET页面中处理BLL/DAL层的异常

    在ASP.NET 2.0中操作数据之十八：在ASP.NET页面中处理BLL/DAL层的异常

    导言 在一个使用了分层体系架构的ASP.NET web应用系统里处理数据,一般遵循以下几步: 1.确定业务逻辑层需要调用哪个方法,并且需要出入哪些参数.这些参数可以通过硬编码设置,程序自动设定,或者由用户输入. 2.调用此方法. 3.处理结果.当调用一个返回数据的BLL方法时,这包括绑定数据到Data Web服务器控件.而对于修改数据的BLL方法而言,这包括基于返回值的基础上执行某些动作,或者适当地处理在第二步中引发的异常. 正如我们在前一节里看到的,无论ObjectDataSource控件还是

  • ASP.NET mvc异常处理的方法示例介绍

    1.首先常见保存异常的类(就是将异常信息写入到文件中去) 复制代码 代码如下: public class LogManager { private string logFilePath = string.Empty; public LogManager(string logFilePath) { this.logFilePath = logFilePath; FileInfo file = new FileInfo(logFilePath); if (!file.Exists) { file.C

  • ASP.NET MVC异常处理模块详解

    一.前言 异常处理是每个系统必不可少的一个重要部分,它可以让我们的程序在发生错误时友好地提示.记录错误信息,更重要的是不破坏正常的数据和影响系统运行.异常处理应该是一个横切点,所谓横切点就是各个部分都会使用到它,无论是分层中的哪一个层,还是具体的哪个业务逻辑模块,所关注的都是一样的.所以,横切关注点我们会统一在一个地方进行处理.无论是MVC还是WebForm都提供了这样实现,让我们可以集中处理异常. 在MVC中,在FilterConfig中,已经默认帮我们注册了一个HandleErrorAttr

  • 在 .NET Framework 2.0 中未处理的异常导致基于 ASP.NET 的应用程序意外退出

    但是,系统日志中可能会记录类似于以下内容的事件消息: 事件类型:警告 事件来源:W3SVC 事件类别:无 事件 ID: 1009 日期: 9/28/2005 时间:3:18:11 PM 用户:N/A 计算机:IIS-SERVER 描述: 为应用程序池"DefaultAppPool"提供服务的进程意外终止.进程 ID 是"2548".进程退出代码是"0xe0434f4d". 而且,应用程序日志中可能会记录类似于以下内容的事件消息: 事件类型:错误

  • Asp.net Mvc 身份验证、异常处理、权限验证(拦截器)实现代码

    1.用户登录 验证用户是否登录成功步骤直接忽略,用户登录成功后怎么保存当前用户登录信息(session,cookie),本文介绍的是身份验证(其实就是基于cookie)的,下面看看代码. 引入命名空间 using System.Web.Security; 复制代码 代码如下: Users ModelUser = new Users() { ID = 10000, Name = UserName, UserName = UserName, PassWord = PassWord, Roles =

随机推荐