asp.net-mvc-3 – IIS挂起在ASP.NET MVC 3应用程序中的特定路由

我们有一个非常奇怪的问题,我们正在处理.

我们正在开发一个MVC 3应用程序,周一我们在一个控制器中遇到了四个特定路由(方法)的问题.所有这四条路线都用于角色管理,并处理创建或编辑角色.我们在应用程序中有两个不同的角色层,因此有两个路由为每个层创建角色,两个路由用于编辑每个层的角色.相应创建路由的两种方法都调用相同的视图,以及相应编辑路由的两种方法.两个视图都调用一个共享的部分视图,其中包含与正在创建或编辑的角色的属性相对应的表单字段.

这是问题所在.

如果我尝试在不先运行调试器的情况下点击这些路由,IIS将挂起.它不会出错,抛出错误,甚至在IIS日志中注册请求.

但是,如果我尝试在调试器中访问这些路由,无论我是否设置了断点,路由都会按预期运行.

为了让生活更有趣,如果我在运行并关闭调试器后尝试访问这些相同的路由,那么路径STILL就会发挥作用.

我们可以在我们的开发团队和我们的登台服务器上的每台机器上重现此行为(除了分段上的调试部分).

与所有这些路由相对应的方法本身依赖于我们中间层中同一Web服务中的几种方法.在我们的集成测试中,这些方法在调试器之外正常工作.

我们在代码中检查了无限循环,但是在这些条件下找不到任何会产生无限循环的东西.事实上,共享视图中只有一个循环,但它是每个循环的一个循环,不应该导致无限循环.

最后,当我尝试点击这四条路线中的任何一条而不在调试器下运行或者至少在先前的请求上运行它时,IIS基本上会挂起.它不会超时.它不会抛出错误.它不会将错误记录到IIS日志中.最后,它将耗尽系统资源,您必须重新启动IIS或重新启动整个计算机.

有没有人见过这种行为？关于如何绕过它的任何想法？我以前从未见过这种行为,我们开发组中任何人都可以提出的唯一问题是文件上存在某种权限问题,但是我们没有访问文件系统(在视图文件本身之外,并且他们在处理这些方法的任何时候都有适当的权限.

我愿意接受任何建议.

更新#1：

我也在ASP.NET论坛上发布了这个问题,我有人问了一个问题以获取更多信息.这是我对他们问题的回答.

What IIS are we talking about?

IIS 7.5.我们使用的是成熟的IIS,而不是IIS Express.

What error?

就是这样.没有错误.没有报告错误.实际上,如果我们试图在没有运行调试器的情况下访问这些路由,则请求本身不会记录在站点的IIS日志中.如果调试器正在运行,一切都按预期工作.

VS Cassini?

不. Windows 7附带的IIS 7.5.

If you deploy on IIS a default WebForm project,does it works?

是.没有问题.实际上,我为在我的开发盒上运行的客户维护了许多WebForms应用程序.它们都没有任何问题.

If you deploy on IIS a default MVC project,does it works?

是.我在这个盒子上运行了很多站点.所有这些网站都顺利运行.事实上,本网站上的绝大多数路线都可以毫无问题地访问.在这个非常控制器的绝大多数路线可以访问没有任何问题！

重申一下,该控制器允许用户管理应用程序中的用户,角色和权限.我们有方法列出,创建和更新用户,角色和权限.无论调试器是否正在运行,达到管理用户和权限的方法的路由都会起作用.给我们提出问题的唯一路线是我上面描述的四条路线.

我们目前在这个应用程序中有19个控制器,每个控制器都有不同数量的定义路由方法.为应用程序定义的每个其他路由都正常工作,并且没有表现出这种行为.这是我们看到的这个特定控制器中唯一的四种方法(路线).

更新#2：

我已经将其缩小到控制器内的REST调用(对于我们控制的服务).这是一个奇怪的部分 – 如果我进入REST服务并立即返回一个值(不处理任何东西),它仍然挂在调试器之外.如果我在调试器内部运行或者在运行调试器后立即运行,那么一切正常.

如果我试图直接在fiddler中点击那个REST服务,它就像一个魅力.

我将尝试更改我正在调用的Web服务的服务合同中的URL,看看是否有效.也许这与Web服务上的REST URL有关.

更新#3：

为了进一步混淆,我设置了Fiddler作为我的MVC应用程序和REST中间层之间的代理.对于应用程序中的每个其他REST调用,代理都会获取请求.对于此特定REST调用,代理从不获取请求.

现在这是烦人的部分.我们用来通过REST调用中间层中的所有方法的WebChannelFactory是使用我们的MVC应用程序中的实用程序类创建的.此代码用于生成每个通道,因此填充用户列表的请求与填充权限列表(挂起的权限)的请求之间没有区别.

这是一个挂起的GET请求,所以我可以直接在浏览器中调用它.它没有问题.问题似乎不在服务端,而是在MVC应用程序中的某个地方.