ASP.Net 错误:“类型‘foo’存在于‘temp1.dll’和‘temp2.​​dll’中"(第 2 点) [英] ASP.Net error: “The type ‘foo’ exists in both ”temp1.dll“ and ”temp2.dll" (pt 2)

问题描述

解决方案:

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

I had also moved ashx and asmx files at the same time as this. The Class attribute of the WebService/WebHandler directives were pointed at the wrong namespace. The moral of the story is to make sure you view the markup for all as*x files you change the namespace for by right-clicking on them and choosing "View Markup".

我遇到了与 这个问题 和这个链接，但没有一个答案能解决我的问题.(设置 web.config 批处理属性有效，但这是掩饰，而不是解决方案)

I'm experiencing the same problem as in this question and this link, but none of the answers fixed my problem. (edit: Setting the web.config batch attribute works, but that's a coverup, not a solution)

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

The problem I'm having is with a User Control that I moved from the root directory to a subdirectory within the same Web Application project. It used to work fine before I moved it. When I moved it it started giving me the error message.

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

It's saying that the class name exists in two dll files in Temporary ASP.NET Files. Sure enough, when I open Reflector, it's in two dlls.

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

If I rename the class and ascx file, everything works fine. No usages of the original name exist within any of the files in my entire application. When I rename the file, I opened all of the dll files in Temporary ASP.NET Files with Reflector, and no references to the original class name exists.

那么这个幻象参考来自哪里，我该如何解决这个问题?

So where's this phantom reference coming from how can I fix this?

更新:我从字面上搜索了解决方案的工作目录中的每个文件和旧类名的临时目录，并删除了包含它的每个文件.然后我重命名回原来的、损坏的名称，但仍然出现错误.

Update: I literally grepped every file in my working directory for the solution and my temp directory for the old class name and deleted every file that contained it. I then renamed back to the original, broken name and I still get the error.

/"应用程序中的服务器错误.编译错误说明:An编译过程中发生错误提供服务所需的资源要求.请查看以下内容具体的错误详细信息并修改您的源代码适当.

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.

编译器错误消息:CS0433:类型'ASP.dashboard_badusercontrol_ascx'存在于 'c:Docunts 和设置我本地设置TempTemporary ASP.NETFiles oot3c2b7e1f2e8a7620App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll'和 'c:Docunts and SettingsmeLocal设置TempTemporary ASP.NETFiles oot3c2b7e1f2e8a7620App_Web_bhdqaimy.dll'

Compiler Error ssage: CS0433: The type 'ASP.dashboard_badusercontrol_ascx' exists in both 'c:Docunts and SettingsmeLocal SettingsTempTemporary ASP.NET Files oot3c2b7e1f2e8a7620App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll' and 'c:Docunts and SettingsmeLocal SettingsTempTemporary ASP.NET Files oot3c2b7e1f2e8a7620App_Web_bhdqaimy.dll'

源错误:

第 1098 行:第 1099 行:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]第 1100 行:私人global::ASP.dashboard_badusercontrol_ascx@__BuildControlMyBadUserControl() {第 1101 行:
global::ASP.dashboard_badusercontrol_ascx@__ctrl;第 1102 行:

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:

源文件:c:Docunts 和设置我本地设置TempTemporary ASP.NETFiles oot3c2b7e1f2e8a7620App_Web_foo.aspx.a57ad085.1nw6dais.0.cs行:1100

Source File: c:Docunts and SettingsmeLocal SettingsTempTemporary ASP.NET Files oot3c2b7e1f2e8a7620App_Web_foo.aspx.a57ad085.1nw6dais.0.cs Line: 1100

<小时>

好的，所以我对哪些有效哪些无效进行了更多测试.假设原始文件名是命名空间MyNamespace"中的BadUserControl.ascx".

---

Ok, so I did some more testing on what works and doesn't work. Let's say the original file name was "BadUserControl.ascx" in namespace "MyNamespace".

我将文件移动到名为NewDirectory"的目录并将命名空间更改为MyNamespace.NewDirectory".我的硬盘上的其他任何地方都没有BadUserControl.ascx"的副本.我仔细检查了我的 TFS 历史记录，以确保唯一的区别是在标记和代码隐藏文件的命名空间中添加了.NewDirectory".

I moved the file to a directory called "NewDirectory" and changed the namespace to "MyNamespace.NewDirectory". There are no copies of "BadUserControl.ascx" anywhere else on my HDD. I double-checked my TFS history to ensure the ONLY difference is the addition of ".NewDirectory" to the namespace in the markup and code-behind files.

在这个命名空间中还有另外两个名为OtherUserControl"和AnotherUserControl"的用户控件.

Inside of this namespace are two other user controls named "OtherUserControl" and "AnotherUserControl".

这种情况失败:我有 2 个注册指令:

This situation fails: I have 2 Register directives:

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

这些情况有效:

1. 我将BadUserControl.ascx"按原样命名.我在同一命名空间的页面上有 1 个 Register 指令:

1. I keep "BadUserControl.ascx" named as is. I have 1 Register directive on a page in the same namespace:

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

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

I change "BadUserControl.ascx" to "GoodUserControl.ascx" I have 2 Register directives:

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

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

2 Register directives without BadUserControl.ascx at all:

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

推荐答案

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

UPDATE: ok, as you found, the circular reference was the wrong guess, as there are other situation that may cause similar behavior.

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

The more general way to describe the problem is that batching at runtime works in a very permissive way which can mask problems. Basically, we try to batch everything in one folder, but if we get a compile error when compiling that batch, we fall back to individual file compilation. In many cases that works fine, but sometimes, this can lead to a given page getting compiled twice (similar to what I described below, but for a different reason).

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

On the other hand, aspnet_compiler works in a strict way, where if batching fails it fails altogether and does not fall back. That's why running this tool is a great way to locate various type of issues (or latent issues) that can be far from obvious at runtime. I guess we didn't do a good job evangelizing this tool for this purpose :)

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

As for why renaming the file fixed it, this may be caused by it changing the ordering in which files are processed, which is a bit arbitrary. It may be that if you rename it to something else, you'll see it happen again.

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

Frankly, looking back I kind of wish we had made this batching behavior strict at runtime, to catch those situations earlier. The reason we chose the current fall back design was to avoid failing whenever possible, but this came with a price: when something is wrong, it's a pain to catch it :)

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

ORIGINAL ANSWER: In short, the problem is that when batching is turned on (and it is by default), you should avoid having directory level circular dependencies. Let me explain what I mean by that.

这是一个例子.假设您有:

Here is an example. Say you have:

• 在文件夹 1 中:page.aspx 和 uc2.ascx
• 在 forder2 中:uc1.ascx

然后说 page.aspx 引用 uc1.ascx(通过@register 指令)，并且 uc1.ascx 引用 uc2.ascx.在文件级别，这完全没问题，但在目录级别，存在循环依赖:folder1 引用了 folder2 中的某些内容，而后者引用了 folder1 中的某些内容.

And say that page.aspx references uc1.ascx (via a @register directive), and that uc1.ascx references uc2.ascx. At the file level, that’s perfectly fine, but at the directory level, there is a circular dependency: folder1 references something in folder2, which references something in folder1.

为什么会出现问题与批处理的工作方式有关:当您请求页面时，它首先尝试将 folder1 中的所有内容编译在一起.但是由于folder1/page.aspx引用了folder2/uc1.ascx，所以需要编译folder2才能做folder1.但是后来 uc1 使用了 uc2，这意味着它必须先做 folder1！此时，ASP.NET 检测到情况并尝试通过自己编译 uc2.asc 来充分利用它.虽然这允许某些场景工作，但它也可能导致奇怪的事情，因为某些项目最终编译在两个程序集中.在这里，uc2.ascx 将自己编译，也可以与 folder1 批处理一起编译.

Why this is problematic has to do with how batching works: when you request the page, it first tries to compile everything in folder1 together. But since folder1/page.aspx references folder2/uc1.ascx, it needs to compile folder2 before it can do folder1. But then uc1 uses uc2, meaning it must first do folder1! At this point, ASP.NET detects the situation and tries to make the best of it by compiling uc2.asc by itself. While this allows some scenarios to work, it can also cause weird things because some items end up compiled in two assemblies. Here, uc2.ascx would be both compiled by itself and with the folder1 batch.

实际上有一种方法可以轻松检测您的站点是否具有此类文件夹级别的循环依赖项.从 VS 控制台窗口，转到站点的根目录并运行:

There is actually a way to easily detect if your site has such folder level circular dependencies. From a VS console window, go to the root of your site and run:

aspnet_compiler -v foo -p .

如果你有文件夹级别的循环依赖，你会得到一些类似的错误:

If you have folder level circular dependencies, you’ll get some errors that look like:

/foo/Sub/UC1.ascx(2): error ASPPARSE: Circular file references are not allowed.

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

The cheap way to avoid this issue is what you already know: disable batching. Now at least you know why that works :)

但最好的办法是避免文件夹级别的循环依赖.如果您开始将每个文件夹视为生成程序集的组件"，这实际上是有道理的，并且有助于使您的网站的各个部分更加模块化.

But the better thing to do if you can is to avoid the folder level circular dependencies. If you start thinking of each folders as a ‘component’ which produces an assembly, that actually makes sense, and can help make the pieces of your site more modular.

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

Yes, it’s also fair to call this a ‘bug’ in the compilation system, or at least a limitation. But once you’re aware of it, it’s fairly easy to avoid.

这篇关于ASP.Net 错误:“类型‘foo’存在于‘temp1.dll’和‘temp2.​​dll’中"(第 2 点)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！