当我使用内部Web服务器(而不是IIS)从Visual Studio 2008 SP1运行Web应用程序时,我收到上述错误。
完整错误(源文件 Default.aspx.cs ):
编译器错误消息:CS0433: 类型'WebApplication3.Site1'存在于 都 “C:\ WINDOWS \ Microsoft.NET \框架\ V2.0.50727 \临时 ASP.NET 文件\ ROOT \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2.muczzy9v.dll” 和 “C:\ WINDOWS \ Microsoft.NET \框架\ V2.0.50727 \临时 ASP.NET 文件\根\ aa563bcf \ 59deedc0 \组件\ DL3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL'
前面的完整警告:
警告:CS0436:类型 'WebApplication3._Default'中 “C:\ WINDOWS \ Microsoft.NET \框架\ V2.0.50727 \临时 ASP.NET 文件\ ROOT \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs' 与导入类型冲突 'WebApplication3._Default'中 “C:\ WINDOWS \ Microsoft.NET \框架\ V2.0.50727 \临时 ASP.NET 文件\根\ aa563bcf \ 59deedc0 \组件\ DL3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3.DLL”。 使用中定义的类型 “C:\ WINDOWS \ Microsoft.NET \框架\ V2.0.50727 \临时 ASP.NET 文件\根\ 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
。以前,这个webapp运行良好。当我将Default.aspx.cs中的任何引用删除到master时,一切顺利。主人只有一些代码。
它实际上是许多小小的“即发即弃”测试webapps中的一个,所以我不在乎。但我之前没有看过这个,现在我很好奇该做什么,然后把代码复制到一个新项目中(清洁解决方案没有帮助)。
注意:我已阅读this post和其他一些内容,但不适用。
答案 0 :(得分:103)
<强>理论强>
当此问题由应用程序中的错误导致不时(例如,重复的类名称):
在对应用程序的项目进行更改后会出现此问题,从而导致新的构建(例如,代码/引用/资源更改)。该问题似乎存在于此新构建的输出中:由于各种原因,Visual Studio不会替换应用程序的obj / bin文件夹中的整个内容。这导致应用程序的bin文件夹中至少有一些内容过时。
当出现上述问题时,单独清除“Temporary ASP.NET Files”文件夹并不能解决问题。它无法解决问题,因为下次访问应用程序时,应用程序bin文件夹的陈旧内容会被复制回“Temporary ASP.NET Files”文件夹,从而导致问题持续存在。关键是删除所有现有文件并强制Visual Studio重建每个对象,因此下次访问您的应用程序时,新的bin文件将被复制到“Temporary ASP.NET Files”文件夹中。
<强>解决方案强>
说明的
答案 1 :(得分:39)
关闭w3svc并删除c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\
<强>加入强>
c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\
也可能发生这种情况。寻找:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
(如果服务器上的版本较新,请使用您正在使用的框架版本替换v4.0.30319)
答案 2 :(得分:9)
查看所有aspx页面和母版页的Inherits标记。有可能有两个具有相同名称的部分类。改变一个并重新编译。
以下是更多信息:
http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx
答案 3 :(得分:9)
如果将.cs文件放在App_Code中并将其构建操作更改为在Web应用程序项目中编译,则可能会发生这种情况。
要么将App_Code中的.cs文件的构建操作作为内容,要么将App_Code的名称更改为其他内容。我更改了名称,因为intellisense不会修复标记为内容的.cs文件。
http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html
的更多信息答案 4 :(得分:4)
从App_Code
文件夹中删除类文件,并将它们直接放在网站下,为我解决了这个问题。
答案 5 :(得分: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" %>
答案 6 :(得分:3)
在所有这些建议之后我仍然遇到了问题。 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'.
我刚刚重命名了&#34; App_Code&#34;文件夹到&#34;代码&#34;。这是一个MVC5项目,因此在Web项目的根目录中提供.cs文件不应该有问题。
答案 7 :(得分:3)
“Clean Solution”后跟“Rebuild Solution”似乎也解决了这个问题。
答案 8 :(得分:3)
当在多个.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问题中提到的异常。
确保两个类名不重叠可以解决问题。
答案 9 :(得分: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。
答案 10 :(得分:2)
我发现了另一个原因:用于工具箱中的图标和项目中的引用的不同版本。以某种形式插入对象后,错误就开始了。
答案 11 :(得分:2)
使用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 \交\出版商\ 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设置为Visual Studio中应用程序的构建时间会对性能产生重大影响。
场景5
描述:修改ASP.NET应用程序的web.config文件或更改bin文件夹中的文件(例如添加,删除或重命名)会导致AppDomain重新启动。发生这种情况时,所有会话状态都会丢失,并且在网站重新启动时将从缓存中删除缓存的项目。这可能是该问题是由Web应用程序不一致的状态造成的。 解决方案:触发一个AppDomain重启通过触碰(编辑)web.config文件
场景6
描述:您可以将源代码存储在App_Code文件夹中,并且它将在运行时自动编译。将所得的组件在Web应用程序中的任何其他代码访问。因此,App_Code文件夹的工作方式与Bin文件夹非常相似,不同之处在于您可以在其中存储源代码而不是已编译的代码。当出现在源文件中的变化的类将被重新编译。如果由于过期的程序集而导致冲突,则强制重新编译可以解决此问题。 解决方案:触摸Bin或App_Code文件夹中的文件以触发完全重新编译。
答案 12 :(得分: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
{
答案 13 :(得分:0)
除了尝试2Toad的答案外,我还不得不关闭Visual Studio并删除我的.vs文件夹。之后,一切正常构建。
顺便说一句,我遇到的错误根本没有指定我的Temp文件夹,而是引用了其他显然是系统生成的错误。我忽略了保存特定错误:\
答案 14 :(得分:0)
在点击CS0433
的错误URL时,当我单击第一个Google匹配时,我被重定向到这里,
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 ++项目版本降级为目标15063
。我还注意到,C#项目的TargetPlatformMinVersion
和TargetPlatformVersion
都新设置为10.0.17134.0
我唯一要做的“修复”是将C#项目的TargetPlatformMinVersion
更改为高于TargetPlatformMinVersion
的版本。将C ++项目修改为任一版本都不会改变行为。我不确定为什么突然停止工作,但希望有人被类似的封锁可能会使用类似的策略摆脱泡菜。
答案 15 :(得分:0)
有很多原因。上面提到的大多数情况适用于不同的情况。我注意到的是,仅当身份验证设置为“无”以外的其他值时,才会发生该错误。出于测试目的,我将其设置为关闭且有效。
答案 16 :(得分: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)
{
答案 17 :(得分:0)
超快速且方便的解决方法是通过临时引用某个类的类来滥用Visual Studio令人难以置信的智能感知。
示例:强>
System.Runtime.CompilerServices.ExtensionAttribute x = null;
在线上构建或悬停光标时,您可以查看以下错误:
'System.Runtime.CompilerServices.ExtensionAttribute'存在于两者中 'C:\ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll'
这会告诉您两个导致冲突的来源。
System.Core.dll
是您要保留的.dll文件,因此请删除另一个。
我发现我坐在bin
目录中,但它可能在项目的其他地方。
事实上,值得记住,因为bin
目录可能不包含在TFS更改集的一部分中,它可以解释为什么检入更改无法解决您团队中的其他成员的问题。
答案 18 :(得分: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')" />
注意这些“&lt; Import”引用可以出现在proj文件的不同位置。
答案 19 :(得分:0)
我遇到了类似的问题。
这是我的解决方案:
将需要属性[Build Action]
设置为[Compile]
的隔离类放到App_Code
之外的任何文件夹,例如Application_Code
,因为App_Code
文件夹将被编译为单独的程序集,具有在2个程序集中编译的相同类。
答案 20 :(得分:0)
在我们的案例中,原因是IIS中的.dll版本与网站的区别。它们在IIS中彼此放置,允许您通过子域访问另一个。它继承自第一个web.config,并将其与下一个web.config相结合,失败了,拥有不同版本的mvc.dll。
答案 21 :(得分:0)
至少对我来说,当我删除对程序集的引用并添加对它的更新版本的引用时,会发生这种情况,该引用具有不同的名称。在这种情况下,似乎旧的程序集仍保留在 bin 和 obj 文件夹中,并且未使用Visual Studio中的清除解决方案操作删除(可能因为它不是项目的一部分了。在这种情况下,从Windows资源管理器(或文件管理工具)中删除发生错误的项目的 bin 和 obj 文件夹的内容就足够了。然后,从Visual Studio中清除解决方案并重建。
答案 22 :(得分:0)
我有两个具有相同类名的ascx控件存在同样的问题:
Control1:&lt;%@ Control Language =“C#”ClassName =“ myClassName ”AutoEventWireup =“true ...&gt; Control2:&lt;%@ Control Language =“C#”ClassName =“ myClassName ”AutoEventWireup =“true ...&gt;
我通过简单地重命名类名来修复它:
Control1:&lt;%@ Control Language =“C#”ClassName =“ myClassName1 ”AutoEventWireup =“true ...&gt; Control2:&lt;%@ Control Language =“C#”ClassName =“ myClassName2 ”AutoEventWireup =“true ...&gt;
答案 23 :(得分:0)
我最终改变了在页面标记中引用MasterType的方式。
我改变了:<%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %>
到<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>
有关详细信息,请参阅here。
希望这可以帮助别人。
答案 24 :(得分:-2)
是的,有同样的问题并通过更改aspx中的c#代码和页面标记的继承来解决它
答案 25 :(得分:-2)
转到web.config
<compilation
中的
它应该解决问题