ASP.Net 错误 : “The type ‘foo’ exists in both ”temp1. dll“和”temp2.​​dll“(第 2 部分)

Question

解决方案:

我还同时移动了 ashx 和 asmx 文件。 WebService/WebHandler 指令的 Class 属性指向了错误的命名空间。这个故事的寓意是确保您查看 的标记。全部 as*x通过右键单击它们并选择“查看标记”来更改 namespace 的文件。

我遇到了与 this question 中相同的问题和 this link ，但没有一个答案解决了我的问题。 (编辑:设置 web.config 批处理属性有效，但这是一种掩饰，而不是解决方案)

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

就是说类名存在于 Temporary ASP.NET Files 的两个 dll 文件中。果然，当我打开Reflector时，它在两个dll中。

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

那么这个幻影引用来自哪里，我该如何解决呢？

更新:我从字面上 grep 了解决方案的工作目录中的每个文件，以及旧类名的临时目录，并删除了包含它的每个文件。然后我重命名回原来的，损坏的名称，我仍然得到错误。

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 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" %>

Answer 1

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

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

另一方面，aspnet_compiler 以严格的方式工作，如果批处理失败，它会完全失败并且不会回退。这就是为什么运行此工具是定位在运行时可能不明显的各种类型问题(或潜在问题)的好方法。我想我们没有很好地为此目的宣传这个工具:)

至于为什么重命名文件会修复它，这可能是由于它改变了处理文件的顺序造成的，这有点武断。如果您将其重命名为其他名称，您可能会看到它再次发生。

坦率地说，回想起来，我有点希望我们在运行时严格执行这种批处理行为，以便更早地捕捉到这些情况。我们选择当前的后备设计的原因是尽可能避免失败，但这也是有代价的:当出现问题时，很难捕获它:)

原始答案:
简而言之，问题是当批处理打开时(默认情况下)，您应该避免目录级别的循环依赖。让我解释一下我的意思。

这是一个例子。假设你有:

在文件夹 1: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.

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

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

是的，将其称为编译系统中的“错误”也是公平的，或者至少是一个限制。但是一旦意识到这一点，就很容易避免。