错误 CS0433“Type 'X' already exists in both A.dll and B.dll”的来源是什么？

Question

在使用Visual Studio 2008 SP1内置的Web服务器（而非IIS）运行Web应用程序时，出现上述错误。

完整的错误信息（源文件Default.aspx.cs）：

  

编译器错误消息：CS0433：类型'WebApplication3.Site1'存在于以下两个位置： 'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2.muczzy9v.dll'和   'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL'

前面的警告：

  

警告：CS0436：'WebApplication3._Default'类型在以下两个位置冲突： 'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'中的导入类型   与   'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3.DLL'中的类型'WebApplication3._Default'冲突。使用在'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'中定义的类型。

警告的源指向一个中间文件App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs：

Line 162:    
Line 163:    [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 164:    public class default_aspx : global::WebApplication3._Default, System.Web.IHttpHandler {
Line 165:        
Line 166:        private static bool @__initialized;

我的问题是：这是从哪里来的？

这个Web应用程序（而不是网站！）有一个Default.aspx和一个Site1.Master，没有依赖项。它们几乎是空的，页面上只有一个asp:Label标签。之前，这个Web应用程序运行良好。当我删除Default.aspx.cs中关于Master的任何引用时，一切都很顺利。Master只有一些代码。

实际上，这是许多小型测试Web应用程序之一，所以我并不在乎。但我以前从未见过这种情况，现在我很想知道该怎么做，除了将代码复制到新项目中（清理解决方案无效）。

注意：我已经阅读了这篇文章和其他一些文章，它们都不适用。

- Abel

---

我的主要想法是：某些东西损坏了临时目录，我现在的主要解决方法是手动删除临时目录并重新构建。还没有尝试过（这样会删除“证据”），以防有人在这方面有更深入的见解。 - Abel

Answer 1

理论

当此问题不是由应用程序中的错误引起的（例如重复的类名）时：

此问题似乎在对应用程序项目进行更改并导致新构建（例如代码/引用/资源更改）后出现。该问题似乎存在于此新构建的输出中：由于各种原因，Visual Studio未替换应用程序obj / bin文件夹的全部内容。这会导致应用程序bin文件夹中的一些内容已过期。

当发生上述问题时，仅清除“Temporary ASP.NET Files”文件夹不能解决问题。它无法解决问题，因为您应用程序的bin文件夹中的陈旧内容在下次访问应用程序时将被复制回“Temporary ASP.NET Files”文件夹，从而导致问题持续存在。关键是删除所有现有文件并强制Visual Studio重新构建每个对象，以便下次访问应用程序时，新的bin文件将被复制到“Temporary ASP.NET Files”文件夹中。

解决方案

1. 关闭Visual Studio
2. 执行iisreset
3. 删除“Temporary ASP.NET Files”文件夹中的所有文件夹和文件（路径在错误消息中引用）
4. 删除有问题的应用程序的“obj”和“bin”文件夹
5. 重新启动Visual Studio并打开解决方案
6. 执行“清理解决方案”，然后执行“重建解决方案”

说明

• 步骤1-2：从我们需要删除的文件夹/文件中删除资源锁。
• 步骤3-4：删除所有旧的构建文件。
• 步骤5-6：创建新版本的构建文件。

- 2Toad

---

这篇文章明显扩充了原先被接受的答案。解释得很好，步骤清晰，谢谢！ - Abel

@Abel，请考虑将此作为答案。因为仅清理ASP.NET临时文件夹是不够的！ - Arin Ghazarian

这种情况也发生在我处理非 Web 项目时。只需删除 bin 和 obj 文件夹即可解决问题。 - Matt H

@ArinGhazarian，没错！我不得不删除obj和bin文件夹来清除这个错误。 - Santosh

非常好的答案，解释得很好。谢谢！ - Carlos Rodriguez

每次我遇到这个错误，我都会回到这个页面并尝试上面提供的所有解决方案，但它们都不是永久性的解决方案，通常下一次重建时问题又会出现。最后，我总是设置batch=false来结束这种情况并继续工作。 - Reza Mortazavi

Answer 2

关闭w3svc并删除 c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\ 目录下的所有内容。

新增：

• 在 Windows 7 上，目录为：c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

• 在 IIS 服务器（64位） 上也可能会出现此情况。请查找：

  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

  (如果您的服务器上使用的是更新版本的框架，请用您正在使用的框架版本替换 v4.0.30319)

- Alex Polkhovsky

---

是的，那可能会起作用（请参见我上面的评论），但我希望能更深入地了解这是从哪里来的以及如何防止它（甚至使其可重现）。我不反对采用暴力解决方法，但在这样做之前，我想先了解发生了什么。 - Abel

这在过去曾经发生过我身上。我相信这是VS的一个问题，在调试会话结束后或开始新会话之前，它没有清理干净。上一次这种情况发生在我使用VS2005的时候，那已经是几年前的事了。 - Alex Polkhovsky

接受这个答案是因为它是一个解决方案。然而，它没有解释“为什么”。如果我找到更好的解决方案或实际原因，我会更新Lyman的答案或添加自己的答案。 - Abel

实际上，这个答案对我没有用。我的项目几周前还能正常工作，但今天尝试时出现了上述问题。我按照上面所说的删除了临时文件（适用于Windows 7），但仍然存在同样的问题。我仍然在想为什么... - Venugopal M

@VenugopalM，你有找到其他的解决方案吗？上面的解决方案对我没有用。 - Vbp

+1非常有用的提示。.Net临时目录中有多少内容令人难以置信。我不知道w3svc是什么，所以我必须重新启动计算机才能删除名为“root”的临时目录，但重新启动也有助于解决奇怪的问题。 - Roland

Answer 3

如果您将.cs文件放在App_Code中，并将它们的构建操作更改为Web应用程序项目中的编译，则可能会发生这种情况。

要么将App_Code中.cs文件的构建操作设置为Content，要么将App_Code的名称更改为其他名称。我更改了名称，因为智能感知无法修复标记为Content的.cs文件。

更多信息请参见http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

- Lilja

---

您提供的链接对我来说是解决方案。我将所有类从App_Code文件夹中移动到一个名为Classes的新文件夹中。然后重命名类的命名空间（命名空间结尾为.Classes而不是.App_Code）。当然，还要更新所有使用语句和对App_Code文件夹的引用。 - krlzlx

非常感谢。这让我疯了。 - Sperick

这对我也解决了问题。谢谢。 - JonH

Answer 4

检查你所有的aspx页面和主页面的继承标签。很可能有两个同名的部分类。更改其中一个并重新编译即可。

以下是更多信息： http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx

- NitroxDM

---

好的观点。那时候的代码已经被重写了，所以我无法检查它是否有帮助，但对于任何遇到这个错误的人来说，这绝对是一个很好的指引，感谢分享。 - Abel

Answer 5

所有这些建议之后，我仍然存在问题。 App_Code内部的某个类被编译为两个DLL。 类似于这样（简化）：

warning CS0436: The type 'HcmDbGeographyModelBinder' in 

'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs' 

conflicts with the imported type 'HcmDbGeographyModelBinder' in 

'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\assembly\dl3\ea0aa3ee\6022e6d5_2cc8cf01\HCM.Web.Backoffice.DLL'.

我刚刚将“App_Code”文件夹重命名为“Code”。这是一个MVC5项目，因此在Web项目的根目录中服务.cs文件不应该有问题。

- tggm

Answer 6

如果您的ASPX文件中有重复的TagPrefix，则可能会出现这种情况。

这会导致此错误...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>

您可以通过将第二个“uc1”更改为“uc2”来解决此问题。

已修复...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>

- Jason Geiger

---

这实际上不是问题，tagprefix可以对所有控件相同。 - Spyros

@Spyros 我不同意，因为它解决了我的问题。已经过去一年了，我不记得关于这个问题的所有内容，但把它留在这里让其他人阅读是值得的。 - Jason Geiger

这个答案解决了我的问题。很奇怪，因为错误并不总是发生，只有在一些部署之后才会出现。像Spyros一样，我不相信这会解决问题，我没有看到联系。感谢Jason Geiger发布这个答案。 - VFein

就它的价值而言。引起这个问题的控件均在同一文件夹中，作为虚拟目录从多个虚拟应用程序中引用。 - VFein

删掉我的注释。错误又露出了丑陋的头部。回到起点重新开始。 - VFein

Answer 7

参考文献：https://support.microsoft.com/zh-cn/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

在使用Visual Studio构建ASP.NET项目时，您可能会随机看到类似以下错误消息：

编译器错误消息：CS0433：类型“ASP.summary_common_controls_notes_ascx”在“c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll”和“c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll”中都存在。

描述：在编译用于服务此请求所需的资源时发生错误。请查看以下特定错误详细信息并相应地修改源代码。

源错误：第100行： 第101行：
新备注 第102行：
第103行：
1450行 第104行：

摘要。

源文件：d:\http\post\publisher\default.aspx 行: 102

下面讨论了可能导致该错误的常见场景

场景1

描述：一个常见原因是同一Web应用程序bin文件夹中有两个包含两个类定义但具有相同类名的程序集。如果将多个Default.aspx编译到单个程序集中，则可能会发生这种情况。通常，当主页面（Default.master）和默认ASPX页面（Default.aspx）都声明_Default类时，就会发生此情况。 解决方案：更改主页的类名称（在大多数情况下为_Default）并重新构建项目。解决任何类之间的命名冲突非常重要。

场景2

描述：Visual Studio中的引用路径用于指定项目使用的程序集引用的文件夹路径。可能存在包含相同类名的程序集的路径。可能已经添加了多个引用到同一个程序集（可能是不同版本或名称），导致命名冲突。 解决方案：删除旧版本引用。为此，在Visual Studio中右键单击您的网站并检查属性中的“引用”。

场景3

描述：默认情况下，当编译ASP.NET Web应用程序时，编译代码会放置在Temporary ASP.NET Files文件夹中。默认情况下，访问权限授予ASP.NET本地用户帐户，该帐户具有访问编译代码所需的高信任权限。有可能默认权限发生了一些变化，造成版本冲突。另一个可能性是反病毒软件无意中锁定了一个程序集。 解决方案：清除所有内容的Temporary ASP.NET Files文件夹。

场景4

描述：当web.config中的batch属性设置为True时，它会消除访问文件时首次需要编译所引起的延迟。ASP.NET以批处理模式预编译所有未编译的文件，这会导致第一次编译文件时出现延迟。关闭批处理编译可能会暴露应用程序中存在但未报告的掩盖编译错误。然而更重要的是，它告诉ASP.NET将单个.aspx/.ascx文件动态编译为单独的程序集，而不是编译为一个程序集。 解决方案：在web.config的部分中设置batch=false。考虑到在Visual Studio中为应用程序设置batch=false会对构建时间产生显著的性能影响，因此应将其视为临时解决方案。

场景5

描述：修改ASP.NET应用程序的web.config文件或更改bin文件夹中的文件（如添加、删除或重命名）会导致AppDomain重新启动。当发生这种情况时，所有会话状态都会丢失，并且缓存中的缓存项会被删除，因为网站正在重新启动。可能是由于Web应用程序中存在不一致状态而导致问题。 解决方案：通过触发编辑web.config文件来触发AppDomain重新启动。

场景6

描述：您可以将源代码存储在App_Code文件夹中，并且它会在运行时自动编译。生成的程序集可由Web应用程序中的任何其他代码访问。因此，App_Code文件夹的工作方式类似于Bin文件夹，只是您可以在其中存储源代码而不是已编译的代码。当源文件发生更改时，该类将被重新编译。如果由于过时的程序集而导致冲突，则强制重新编译可能会解决问题。 解决方案：触摸Bin或App_Code文件夹中的文件以触发完全重新编译。

- Sandeep Kumar Narware

---

通常情况下，我会尝试使用最简单的解决方案。以下是我在上述第6个场景中解决问题的方法：“解决方案：触摸Bin或App_Code文件夹中的文件以触发完全重新编译。” - cjo30080

我从第六个场景开始，它对我有效。 - Abdul

Answer 8

把 App_Code 文件夹中的类文件移除，直接放在网站下面，这样就解决了我的问题。

- Naveen Q

---

很抱歉，这并不是一个可行的选项。将dll文件直接放在根目录下被许多人认为是一种安全风险（App_Code或bin是特殊的，并且无法通过IIS/ASP.NET访问，而任何放在根目录下的dll都可以轻易地被下载和反编译.NET程序集）。 - Abel

我也将类放在ASP.NET MVC4项目的models文件夹中来解决这个问题。 - DShook

Answer 9

当在多个 .aspx.cs 文件中指定相同的类名时，即使两个页面由不同的文件名创建但错误地具有相同的类名，也可能会发生这种情况。

// file a.aspx
public partial class Test1: System.Web.UI.Page

// file b.aspx
public partial class Test1: System.Web.UI.Page

在构建Web应用程序时，这会发出警告，但应用程序仍然可以运行，但是在发布应用程序后，应用程序不再工作，并抛出OP问题中提到的异常。

确保两个类名不重叠即可解决此问题。

- Deepak

---

谢谢您关注这个问题。但是在您的示例中，您使用了“partial class”，这实际上是将一个类分割成多个文件的常见方式（也是唯一的方式），在这种情况下，您必须使用相同的名称。 - Abel

这最终与我在网站（而不是应用程序）中遇到的问题非常接近。清除临时文件夹，将东西移出App_Code和其他建议都没有起作用。直到我查看了我的主页.cs代码后台文件，才注意到文件名与类名不匹配，而类名仍然是默认的“MasterPage”。一旦我在右键菜单中进行了类重命名（以便所有引用也会更新），错误最终消失了。我只能猜测我的主页面与System.Web.UI.MasterPage类发生了冲突。 - Andrew S

Answer 10

这是因为我的Web.Config文件出现了错误。

<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Sytem.Web.Helpers被指向了1.0.0.0版本，而不是3.0.0.0版本（该项目使用MVC 3）。

由于IIS在本地文件夹中找不到引用，它在GAC中找到了两个不同的版本。将其指向正确的引用后，IIS找到了本地dll并使用它，而不是搜索GAC。

- mlapaglia