我也在同一时间移动了ashx和asmx文件. WebService / WebHandler指令的Class属性指向错误的命名空间.故事的道德是确保您查看所有作为* x文件的标记,通过右键单击并选择“查看标记”来更改命名空间.
我遇到与this question和this link相同的问题,但没有一个答案解决了我的问题. (编辑：设置web.config批处理属性有效,但这是一个掩护,而不是一个解决方案)
我遇到的问题是使用一个用户控件,我从根目录移动到同一个Web应用程序项目中的一个子目录.在我移动之前,它曾经很好地工作.当我移动它开始给我错误信息.
这就是说,这个类名存在于临时ASP.NET文件中的两个dll文件中.果然,当我打开Reflector,它是在两个dll.
如果我重命名类和ascx文件,一切都正常.在我的整个应用程序的任何文件中不存在原始名称的用法.当我重命名文件时,我使用Reflector打开临时ASP.NET文件中的所有dll文件,并且不存在对原始类名的引用.
那么这个幻影参考在哪里可以解决这个问题？
更新：我字面上grepped我的工作目录中的每个文件的解决方案和我的临时目录为旧类名,并删除每个包含它的文件.然后我重新命名为原来的名字,我仍然收到错误.
Server Error in ‘/’ Application.
Compilation Error Description: An
error occurred during the compilation
of a resource required to service this
request. Please review the following
specific error details and modify your
source code appropriately.Compiler Error ssage: CS0433: The type
‘ASP.dashboard_badusercontrol_ascx’
exists in both ‘c:\Docunts and
Settings\me\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll’
and ‘c:\Docunts and Settings\me\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_bhdqaimy.dll’Source Error:
Line 1098: Line 1099:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
Line 1100: private
global::ASP.dashboard_badusercontrol_ascx
@__BuildControlMyBadUserControl() {
Line 1101:
global::ASP.dashboard_badusercontrol_ascx
@__ctrl; Line 1102:Source File: c:\Docunts and
Settings\me\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_foo.aspx.a57ad085.1nw6dais.0.cs
Line: 1100
编辑：
好的,所以我做了一些更多的测试工作,不起作用.
假设命名空间“MyNamespace”中的原始文件名为“BadUserControl.ascx”.
我将文件移动到名为“NewDirectory”的目录,并将命名空间更改为“MyNamespace.NewDirectory”.在我的硬盘上别的地方没有“BadUserControl.ascx”的副本.我仔细检查了我的TFS历史,以确保唯一的区别是添加“.NewDirectory”到标记和代码隐藏文件中的命名空间.
在这个命名空间里面还有另外两个名为“OtherUserControl”和“AnotherUserControl”的用户控件.
这种情况失败：
我有2个注册指令：
<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %> <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
这些情况有效：
>我保留“BadUserControl.ascx”命名为.
我在同一个命名空间的页面上有1个Register指令：
<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>
>我将“BadUserControl.ascx”更改为“GoodUserControl.ascx”
我有2个注册指令：
<%@ Register src="GoodUserControl.ascx" tagname="GoodUserControl" tagprefix="uc1" %> <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
> 2没有BadUserControl.ascx注册指令：
<%@ Register src="AnotherUserControl.ascx" tagname="AnotherUserControl" tagprefix="uc1" %> <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
解决方法
描述问题的更一般的方法是在运行时批处理以一种非常宽容的方式工作,可以掩盖问题.基本上,我们尝试在一个文件夹中批处理所有内容,但如果在编译该批次时收到编译错误,那么我们将返回到单个文件编译.在许多情况下工作正常,但有时,这可能会导致一个给定的页面被编译两次(类似于下面描述,但是由于不同的原因).
另一方面,aspnet_compiler以严格的方式工作,如果批处理失败,它完全失败并且不会退回.这就是为什么运行这个工具是找到在运行时可能远远不明显的各种类型的问题(或潜在问题)的好办法.我想我们没有做好这个工具的传福音这个目的:)
至于为什么重命名文件修复它,这可能是由于它改变了处理文件的顺序,这是有点任意的.可能是,如果你将它重命名为别的东西,你会再次看到它.
坦率地说,回想起来,我希望我们在运行时使这个批处理行为严格,以便早日捕捉这些情况.我们选择当前秋季设计的原因是为了尽可能避免失败,但是这带来了一个代价：当有什么不对,这是一个很痛苦的抓住它:)
原始答案：
简而言之,问题是当批量打开(默认情况下)时,应避免具有目录级循环依赖性.让我解释一下我的意思.
这是一个例子.说你有：
>在folder1：page.aspx和uc2.ascx中
> forder2：uc1.ascx
并且说page.aspx引用uc1.ascx(通过@register指令),uc1.ascx引用uc2.ascx.在文件级别,这是非常好的,但在目录级别,有一个循环依赖：folder1引用了folder2中的某些东西,它引用了folder1中的某些东西.
为什么这是有问题的与批处理如何工作：当您请求页面时,它首先尝试将folder1中的所有内容一起编译.但是,由于folder1 / page.aspx引用了folder2 / uc1.ascx,因此需要在folder1之前编译folder2,但是uc1使用uc2,这意味着它必须先做文件夹1！在这一点上,ASP.NET检测到这种情况,并尝试通过自己编译uc2.asc来充分利用它.虽然这允许一些场景工作,但它也可能导致奇怪的事情,因为一些项目最终编译在两个程序集中.这里,uc2.ascx将自己和folder1批次一起编译.
实际上有一种方法来轻松检测您的站点是否具有这样的文件夹级循环依赖关系.从VS控制台窗口,转到您的站点的根目录并运行：
aspnet_compiler -v foo -p .
/foo/Sub/UC1.ascx(2): error ASPPARSE: Circular file references are not allowed.
避免这个问题的便宜方法是你已经知道的：禁用批处理.现在至少你知道为什么这样做:)
但是,如果可以避免文件夹级的循环依赖性,那么最好的办法.如果您开始将每个文件夹视为生成程序集的“组件”,这实际上是有意义的,并且可以帮助您的站点更加模块化.
是的,在编译系统中称这是一个“错误”,或至少是一个限制也是公平的.但是一旦你知道它,这是很容易避免的.
