ASP.Net错误:"temp1.dll"和"temp2.​​dll"中存在类型'foo'(第2页)

Question

解:

我也同时移动了ashx和asmx文件.WebService/WebHandler指令的Class属性指向错误的命名空间.故事的寓意是确保通过右键单击它们并选择"查看标记"来查看更改命名空间的所有 as*x文件的标记.

---

我遇到了与此问题和此链接相同的问题,但没有一个答案解决了我的问题.(编辑:设置web.config批处理属性有效,但这是一个掩盖,而不是解决方案)

我遇到的问题是用户控件,我从根目录移动到同一Web应用程序项目中的子目录.在移动它之前,它曾经很好地工作.当我移动它时,它开始给我错误信息.

它说类名存在于临时ASP.NET文件中的两个dll文件中.果然,当我打开Reflector时,它就在两个dll中.

如果我重命名类和ascx文件,一切正常.在我的整个应用程序的任何文件中都不存在原始名称的用法.当我重命名文件时,我打开了带有Reflector的Temporary ASP.NET Files中的所有dll文件,并且不存在对原始类名的引用.

那么这个幽灵参考来自何处我能解决这个问题？

更新:我实际上在工作目录中为解决方案和我的临时目录中的每个文件添加了旧类名,并删除了包含它的每个文件.然后我重命名回原来的,破碎的名字,我仍然得到错误.

'/'应用程序中的服务器错误.编译错误说明:在编译服务此请求所需的资源期间发生错误.请查看以下特定错误详细信息并相应地修改源代码.

编译器错误ssage:CS0433:类型'ASP.dashboard_badusercontrol_ascx'存在于'c:\ Docunts和Settings\me\Local Settings\Temp\Temporary ASP.NET Files\root\3c2b7e1f\2e8a7620\App_Web_badusercontrol.ascx.a57ad085.iljdmp1p .dll'和'c:\ Docunts and Settings\me\Local Settings\Temp\Temporary ASP.NET Files\root\3c2b7e1f\2e8a7620\App_Web_bhdqaimy.dll'

来源错误:

第1098行:第1099行:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]第1100行:私有全局:: ASP.dashboard_badusercontrol_ascx @__ BuildControlMyBadUserControl(){第1101行:
global :: ASP.dashboard_badusercontrol_ascx @__ctrl; 1102行:

源文件: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指令:

<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %> 
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>

这些情况有效:

1. 我保持命名为"BadUserControl.ascx".我在同一名称空间的页面上有1个Register指令:

   <%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>
   

2. 我将"BadUserControl.ascx"更改为"GoodUserControl.ascx"我有2个Register指令:

   <%@ Register src="GoodUserControl.ascx" tagname="GoodUserControl" tagprefix="uc1" %>
   <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
   

3. 2注册没有BadUserControl.ascx的指令:

   <%@ Register src="AnotherUserControl.ascx" tagname="AnotherUserControl" tagprefix="uc1" %>
   <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
   

Answer 1

更新:好的,正如您所发现的那样,循环引用是错误的猜测,因为还有其他情况可能会导致类似的行为.

描述问题的更一般方法是在运行时批处理以非常宽松的方式工作,这可以掩盖问题.基本上,我们尝试在一个文件夹中批量处理所有内容,但如果在编译该批处理时遇到编译错误,我们将回退到单个文件编译.在许多情况下工作正常,但有时,这可能会导致给定页面编译两次(类似于我在下面描述的,但出于不同的原因).

另一方面,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,它需要先编译folder2才能进行folder1.但是然后uc1使用uc2,这意味着它必须首先执行folder1!此时,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.

避免此问题的廉价方法是您已经知道的:禁用批处理.现在至少你知道为什么那样有效:)

但是,如果可以的话,最好的办法是避免文件夹级循环依赖.如果您开始将每个文件夹视为生成程序集的"组件",那么这实际上是有意义的,并且可以帮助您使站点的各个部分更加模块化.

是的,将它称为编译系统中的"错误",或者至少是一个限制也是公平的.但是一旦你意识到这一点,就很容易避免.

Answer 2

干净的Temporary ASP.NET Files。可能是移动之前的控制有一个组件，而移动之后的控制是另一个组件