错误CS0433“ A.dll和B.dll中已经存在类型'X'”从何而来？

81

当我使用内部Web服务器（而非IIS）从Visual Studio 2008 SP1运行webapp时，收到上述错误。

完整错误（源文件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：在'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0中，类型为'WebApplication3._Default'。 cs与'c：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3中的导入类型'WebApplication3._Default'冲突.DLL”。使用在'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;

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

该webapp（不是网站！）具有一个Default.aspx和一个Site1.Master，没有依赖关系。它们几乎是空的，asp:Label页面上有个。以前，此Web应用程序运行良好。当我删除Default.aspx.cs中对主服务器的任何引用时，一切顺利。母版只有一些代码。

它实际上是许多一劳永逸的测试型Web应用程序之一，因此我一点也不在乎。但是我以前从未见过这种情况，现在我很好奇该怎么做，然后将代码复制到一个新项目中（清理解决方案无济于事）。

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

c#  asp.net  master-pages 
— 亚伯
source
PS：我的主要思想是：临时目录被搞砸了，我的主要出路是简单地手动删除临时目录并进行重建。如果有人对此有更深入的了解，请不要尝试（将删除“证据”）。
— 亚伯2009年

Answers:

120

理论

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

在对应用程序的项目进行了更改（导致生成新版本）之后，似乎会出现此问题（例如，代码/引用/资源更改）。问题似乎出在这个新版本的输出之内：由于各种原因，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. 删除“ ASP.NET临时文件”文件夹中的所有文件夹和文件（错误消息中引用了路径）
  4. 删除有问题的应用程序的“ obj”和“ bin”文件夹
  5. 重新启动Visual Studio并打开解决方案
  6. 执行“清理解决方案”，然后执行“重建解决方案”

说明

  • 步骤1-2：从我们需要删除的文件夹/文件中删除资源锁。
  • 步骤3-4：删除所有旧的构建文件
  • 步骤5-6：创建构建文件的新版本
— 2蟾蜍
source
3
这篇文章显然扩大了最初接受的答案。很好的解释和明确的步骤，谢谢！
— Abel 2013年
1
@Abel请考虑将此作为答案。因为仅清理ASP.NET临时文件夹无济于事！
— Arin Ghazarian
2
这发生在我的非网络项目中。只需删除bin和obj文件夹即可修复它。
— Matt H
1
@ArinGhazarian，完全是！我还必须删除obj和bin文件夹以清除此错误。
— Santosh
好的答案，很好的解释。谢谢！
— 卡洛斯·罗德里格斯
39

关闭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）

— 亚历克斯·波霍夫斯基
source
2
是的，这可能会起作用（请参阅上面的我自己的评论），但是我希望对它的来源以及如何防止它（甚至使其可再现）有更多的了解。我不反对解决暴力问题，但在这样做之前，我想了解发生了什么。
— 亚伯
过去这发生在我身上。我认为这是VS的问题，在调试会话之后或开始新会话之前，VS无法清理。上次发生在我身上的是几年前的VS2005。
— Alex Polkhovsky 09年
3
接受此答案，因为它是一种解决方案。但是，它没有解释“为什么”。如果我找到更好的解决方案或实际原因，我将更新莱曼的答案或添加自己的答案。
— 亚伯2010年
实际上，这个答案对我不起作用。我的项目在几周前运行良好，但是今天我尝试了一下，并显示了上述问题。我如上所述删除了临时文件（对于Windows 7），相同的问题仍然存在。我仍然想知道为什么...
— Venugopal M
@VenugopalM您是否找到了其他解决方案，上述解决方案对我没有帮助
— Vbp 2014年
11

如果将.cs文件放在App_Code中并将其生成操作更改为在Web应用程序项目中进行编译，则可能会发生这种情况。

在App_Code中将.cs文件的构建操作作为Content进行，或者将App_Code的名称更改为其他名称。我更改了名称，因为intellisense无法修复标记为内容的.cs文件。

有关更多信息，请访问http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

— 莉莉娅
source
您提供的链接是我的解决方案。我从App_Code文件夹中移走了所有类，并将它们放在名为Classes的新文件夹中。然后重命名类的名称空间（名称空间的结尾= .Classes而不是.App_Code）。当然，更新所有using语句和对App_Code文件夹的引用。
— krlzlx
非常感谢你。这让我发疯
— Sperick '16
这也为我解决了。谢谢。
— JonH
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
source
4

从App_Code文件夹中删除类文件，然后将其直接放置在网站下，为我解决了此问题。

— 纳文Q
source
3
恐怕这不是一个选择。将dll直接放置在根目录下被认为存在许多安全风险（App_Code或bin是特殊的，并且无法通过IIS / ASP.NET访问，而根目录中的任何dll都可以轻松下载，并且.NET程序集很容易反汇编）。
— 亚伯2010年
我也将该类放在ASP.NET MVC4项目的models文件夹中，以解决此问题。
— DShook 2013年
4

如果您的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）
source
1
这实际上不是问题，所有控件的tagprefix都可以相同
— Spyros
@Spyros我不同意，因为它为我解决了这个问题。已经一年多了，不记得有关此的所有内容，但是值得将其留在这里供其他人阅读。
— 詹森·盖格2014年
这个答案解决了我的问题。这很奇怪，因为错误并不总是在某些部署之后才会发生。像Spyros一样，我不认为这可以解决问题，也看不到任何联系。感谢Jason Geiger发布此信息。
— VFein
物有所值。导致此问题的控件都在同一文件夹中，并从多个虚拟应用程序引用为一个虚拟目录。
— VFein
写下我的评论。错误再次显示出丑陋的头颅。回到绘图板。
— VFein
4

参考：https : //support.microsoft.com/en-in/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 \临时ASP.NET文件\ 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应用程序时，将已编译的代码放在“临时ASP.NET文件”文件夹中。默认情况下，访问权限被授予ASP.NET本地用户帐户，该帐户具有访问已编译代码所需的高信任权限。默认权限中可能有一些更改，导致版本冲突。另一种可能性是防病毒软件可能无意中锁定了程序集。解决方案：清除所有内容的“临时ASP.NET文件”文件夹。

方案4

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

场景5

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

场景6

说明：您可以将源代码存储在App_Code文件夹中，它将在运行时自动编译。Web应用程序中的任何其他代码都可以访问生成的程序集。因此，App_Code文件夹的工作方式与Bin文件夹非常相似，不同之处在于，您可以在其中存储源代码而不是已编译的代码。当源文件发生更改时，将重新编译该类。如果由于过期的程序集而发生冲突，则强制重新编译可以解决此问题。解决方案：触摸Bin或App_Code文件夹中的文件以触发完全重新编译。

— Sandeep Kumar Narware
source
根据经验，我通常首先尝试提供的最简单的解决方案。上面方案6中的以下内容为我解决了该问题：“解决方案：触摸Bin或App_Code文件夹中的文件以触发完全重新编译。”
— cjo30080
2

这是由于我的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
source
2

当在多个.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中所提到的异常。

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

— 迪帕克
source
Tx对此进行了调查。但是在您的示例中，您使用partial class，这实际上是将一个类拆分为多个文件的一种通用方法（唯一方法），在这种情况下，您必须使用相同的名称。
— 亚伯2010年
最终，这与我在网站（而非应用程序）中的问题很接近。清除Temp文件夹，将内容移出App_Code和其他建议均无效。直到我查看母版页的.cs代码隐藏文件时，我才注意到文件名与类名不匹配，而类名仍然是默认名称MasterPage。一旦在右键菜单中对类进行了重命名（因此所有引用也会更新），错误最终消失了。我只能猜测我的母版页与System.Web.UI.MasterPage班级冲突。
— 安德鲁·S
1

“清洁解决方案”后跟“重建解决方案”似乎也可以解决该问题。

— 罗曼
source
正如我在这个问题在我的情况说明，至少，清洁液也没有帮助。它无济于事的原因是该错误是由临时ASP.NET文件引起的（如第一和第二个答案中所述），当执行“干净的解决方案”时，这些文件不会被清理。
— Abel 2014年
0

我最终改变了在页面标记中引用MasterType的方式。

我更改<%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> 为<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

有关详细信息，请参见此处。

希望这可以帮助某人。

— 克里斯
source
0

至少对我来说，这是在我删除对程序集的引用并添加了对该程序集的更高版本的引用时发生的，该程序集具有不同的名称。在这种情况下，似乎旧程序集保留在bin和obj文件夹中，并且没有通过Visual Studio的全新解决方案操作删除（可能是因为它不再属于项目）。在这种情况下，从Windows资源管理器（或文件管理工具）中删除发生错误的项目的bin和obj文件夹的内容就足够了。然后，从Visual Studio中清洁解决方案并重新生成。

— 吉列尔莫·古铁雷斯
source
0

在我们的案例中，原因是IIS中网站的.dll版本有所不同。它们在IIS中相互放置，使您可以通过子域访问另一个。它继承自第一个web.config，并将其与下一个web.config合并，但失败，具有不同版本的mvc.dll。

— 克里斯蒂安·哈兰德
source
0

我有类似的问题。这是我的解决方案：将需要对属性[Build Action]设置为[Compile]其他文件夹的隔离类放到其他文件夹之外App_Code，Application_Code因为该App_Code文件夹将被编译为一个单独的程序集，并且将相同的Class编译为2个程序集。

— 阿里·马哈茂迪
source
0

我遇到了两个具有相同类名的ascx控件相同的问题：

Control1：<％@控制语言=“ C＃” ClassName =“ myClassName ” AutoEventWireup =“ true ...> Control2：<％@控制语言=” C＃“ ClassName =” myClassName “ AutoEventWireup =” true ...>

我通过简单地重命名类名来解决它：

Control1：<％@控制语言=“ C＃” ClassName =“ myClassName1 ” AutoEventWireup =“ true ...> Control2：<％@控制语言=” C＃“ ClassName =” myClassName2 “ AutoEventWireup =” true ...>

— 库纳尔巴布雷
source
0

关闭解决方案并重新打开它，然后检查项目引用是否加倍：

在此处输入图片说明

如果您使用的是NuGet并更改了DLL的引用位置，则可能会发生这种情况。要修复它，您必须手动编辑proj文件，删除条目，例如：

  <Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />

请注意，这些“ <导入”引用可能出现在proj文件的不同位置。

— 杰里米·汤普森
source
0

超级便捷的修复方法是通过在某个地方临时引用该类来滥用Visual Studio令人难以置信的智能。

例：

System.Runtime.CompilerServices.ExtensionAttribute x = null;

将光标建立或悬停在行上时，您可以查看以下错误：

C：\ Program Files \参考程序集\ Microsoft \ Framework \ v3.5 \ System.Core.dll中都存在'System.Runtime.CompilerServices.ExtensionAttribute'

这将立即告诉您导致冲突的两个来源。

System.Core.dll 是您要保留的.dll文件，因此删除另一个。

我发现我坐在bin目录中，但它可能在项目的其他地方。

实际上，这是值得牢记的，因为既然bin目录可能不包含在TFS变更集中，所以它可以解释为什么签入变更并不能解决团队其他成员的问题。

— WonderWorker
source
0

我正在将旧的asp.net（v 1或2）网站转换为在.net 4.5下作为Web应用程序运行。

我的解决方案是将导致问题的用户控件事件处理程序委托移动到单独的物理文件中：

//move this line to a new physical file:
public delegate void LocationSearchedEventHandler( object sender );

public partial class controls_Drives_LocationAddPanel : UserControl
{
    public event LocationAddedEventHandler LocationAdded;
    protected virtual void OnLocationAdded(LocationAddEventArg e)
    {
— marcel_g
source
0

造成这种情况的原因有很多。上面提到的大多数情况适用于不同的情况。我注意到的是，仅当身份验证设置为“无”以外的其他选项时，才会发生该错误。出于测试目的，我将其设置为有效。

— 查格伯特
source
0

当我点击第一个Google匹配时，点击的错误URL时CS0433，我被重定向到这里，特别是，

The type 'Package' exists in both 'Windows... Version=N.N.N.N, Culture=neutral, PublicKeyToken=null, ContentType=Windows...' and 'Windows..., Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=Windows...'

除了概述我为解决该问题所做的所有工作外，我还告诉您我做了哪些工作使它崩溃。我去更新了一个需要代码更新的仓库的NuGet软件包。这些软件包很旧（大约1年），我最初试图做的只是为C＃项目更新它。

在启动该过程和遇到此错误之间的某个时间，我以某种方式将SLN中的C ++项目版本降级为target 15063。我还注意到C＃项目同时将TargetPlatformMinVersion和TargetPlatformVersion设置为10.0.17134.0

我唯一要做的“修复”是将其更改为TargetPlatformMinVersion比TargetPlatformMinVersionC＃项目更高的版本。将C ++项目修改为任何一个版本都不会改变行为。我不确定为什么突然停止工作，但希望有人被类似的封锁可能会使用类似的策略摆脱泡菜。

— kayleeFrye_onDeck
source
0

除了尝试2Toad的答案外，我还不得不关闭Visual Studio并删除我的.vs文件夹。之后，一切正常。

顺便说一句，我遇到的错误根本没有指定我的Temp文件夹，而是引用了显然是系统生成的其他内容。我忽略了保存特定的错误：\

— 内特
source
0

如果没有其他解决方案，则只需将导致aspx文件和aspx.cs文件的问题的继承类重命名为新名称，然后重新构建解决方案。那么问题肯定会得到解决。这只对我有用。

例如：

在aspx文件中，执行以下操作，将继承类名称更改为Defaultnew

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

在aspx.cs文件中，将类重命名为与aspx文件中使用的类相同

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{
— anandd360
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.