programing

오류 CS0433 "A.dll과 B.dll에 이미 'X'유형이 있습니다."라는 오류는 어디에서 발생합니까?

nasanasas 2020. 10. 18. 18:21
반응형

오류 CS0433 "A.dll과 B.dll에 이미 'X'유형이 있습니다."라는 오류는 어디에서 발생합니까?


IIS가 아닌 내부 웹 서버를 사용하여 Visual Studio 2008 SP1에서 웹앱을 실행할 때 위에서 언급 한 오류가 발생합니다.

전체 오류 (소스 파일 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페이지에있는 거의 비어 있습니다. 이전에는이 ​​웹앱이 제대로 작동했습니다. Default.aspx.cs에서 마스터에 대한 참조를 제거하면 모든 것이 잘됩니다. 마스터에는 일부 코드 만 있습니다.

실제로는 많은 소규모 테스트 웹앱 중 하나이므로 덜 신경 쓰지 않았습니다. 그러나 나는 이것을 전에 본 적이 없었고 지금은 코드를 새 프로젝트에 복사하는 것 외에는 무엇을 해야할지 궁금합니다 (청소 솔루션은 도움이되지 않습니다).

참고 : 이 게시물 과 다른 게시물을 읽었 지만 적용되지 않습니다.


이론

이 문제가 응용 프로그램의 버그로 인한 것이 아닌 경우 (예 : 중복 된 클래스 이름) :

이 문제는 새 빌드 (예 : 코드 / 참조 / 리소스 변경)로 이어지는 애플리케이션의 프로젝트가 변경된 후에 나타나는 것으로 보입니다. 이 문제는이 새 빌드의 출력에있는 것으로 보입니다. 여러 가지 이유로 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 단계 : 빌드 파일의 새 버전 만들기

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 대체)


이는 App_Code에 .cs 파일을 배치하고 웹 애플리케이션 프로젝트에서 컴파일하도록 빌드 조치를 변경 한 경우에 발생할 수 있습니다.

App_Code의 .cs 파일에 대한 빌드 작업이 Content로 있거나 App_Code의 이름을 다른 것으로 변경합니다. intellisense가 콘텐츠로 표시된 .cs 파일을 수정하지 않기 때문에 이름을 변경했습니다.

http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html 에서 자세한 정보


모든 aspx 페이지와 마스터 페이지의 Inherits 태그를 살펴보십시오. 같은 이름을 가진 두 개의 부분 클래스가있을 가능성이 있습니다. 하나를 변경하고 다시 컴파일하십시오.

다음은 몇 가지 추가 정보입니다.

http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx


App_Code폴더 에서 클래스 파일을 제거하고 웹 사이트 바로 아래에 배치하면이 문제가 해결되었습니다.


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

이 모든 제안 후에도 여전히 문제가 발생했습니다. 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 프로젝트이므로 웹 프로젝트의 루트 내에서 .cs 파일을 제공하는 데 문제가 없어야합니다.


참조 : 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 \ 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

설명 : 일반적인 원인은 동일한 웹 응용 프로그램 bin 폴더에 두 개의 클래스 정의가 포함되어 있지만 클래스 이름이 같은 어셈블리가 두 개있는 경우입니다. 둘 이상의 Default.aspx가 단일 어셈블리로 컴파일 된 경우에 발생할 수 있습니다. 일반적으로 이는 마스터 페이지 (Default.master)와 기본 ASPX 페이지 (Default.aspx)가 모두 _Default 클래스를 선언 할 때 발생합니다. 솔루션 : 마스터 페이지의 클래스 이름 (대부분의 경우 _Default에서)을 변경하고 프로젝트를 다시 빌드하십시오. 클래스 간의 이름 충돌을 해결하는 것이 중요합니다.

시나리오 2

설명 : Visual Studio의 참조 경로는 프로젝트에서 사용하는 어셈블리 참조의 폴더 경로를 지정하는 데 사용됩니다. 경로에 동일한 클래스 이름이 포함 된 어셈블리가 포함되어있을 수 있습니다. 동일한 어셈블리 (다른 버전 또는 이름)에 여러 참조가 추가되어 이름 충돌이 발생할 수 있습니다.
해결 방법 : 이전 버전 참조를 제거하십시오. 이렇게하려면 Visual Studio에서 웹 사이트를 마우스 오른쪽 단추로 클릭하고 속성에서 "참조"를 확인합니다.

시나리오 3

설명 : 기본적으로 ASP.NET 웹 응용 프로그램이 컴파일되면 컴파일 된 코드가 Temporary ASP.NET Files 폴더에 저장됩니다. 기본적으로 액세스 권한은 컴파일 된 코드에 액세스하는 데 필요한 높은 신뢰 권한이있는 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.config 파일을 터치 (편집)하여 AppDomain 다시 시작을 트리거합니다.

시나리오 6

Description: You can store source code in the App_Code folder, and it will be automatically compiled at run time. The resulting assembly is accessible to any other code in the Web application. The App_Code folder therefore works much like the Bin folder, except that you can store source code in it instead of compiled code. The class will be recompiled when there is a change in the source file. If there is conflict due to an outdated assembly then forcing a recompile may resolve the problem. Solution: Touch a file in the Bin or App_Code folders to trigger a full recompilation.


"Clean Solution" followed by "Rebuild Solution" seems to fix it as well.


This happened to me because of an error in my 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"/>

The Sytem.Web.Helpers was pointed at 1.0.0.0 instead of 3.0.0.0 (MVC 3 is being used on this project).

Because IIS couldn't find the reference in the local folder it looked in the GAC and found two different versions. After pointing it at the correct reference IIS found the local dll and used that instead of searching the GAC.


This may happen when the same classname is specified in multiple .aspx.cs files, i.e. when two pages are created with different file name but by mistake have the same classname.

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

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

While building the webapplication this gives a warning, but the application runs, however, after publishing the application doesn't work anymore and throws the exception as mentioned in the OP's question.

Making sure that two classnames do no overlap solves the issue.


I have found another reason: different versions used for icons in toolbox and references in the project. After inserting the objects in some form, the error started.


I ended up changing how the MasterType is referenced in the page mark up.

I changed: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> to <%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

See here for details.

Hope this helps someone out.


For me at least, this happened when I removed a reference to an assembly and added a reference to a newer version of it, which had a different name. In this case, it seems that the old assembly remained in the bin and obj folder, and was not removed with the clean solution operation from Visual Studio (maybe because it is not part of the project anymore). In this case, it was enough to delete the contents of the bin and obj folders of the project where he error happens, from Windows Explorer (or a file management tool). Then, from Visual Studio, clean the solution and rebuild.


In our case, the reason was a difference in the .dll versions of to sites in IIS. They are placed under each other in IIS, letting you access the other thru a subdomain. It inherits from the first web.config, and combining that with the next web.config, it failed, having different versions of mvc.dll.


I had the similar problem. This is my solution : Put isolated classes which require property [Build Action] set as [Compile] to any folder other than App_Code like Application_Code since the App_Code folder will be compiled as a separate assembly, having the same Class compiled in 2 assemblies.


I had same issue with two ascx controls having same class name:

Control1: <%@ Control Language="C#" ClassName="myClassName" AutoEventWireup="true ...> Control2: <%@ Control Language="C#" ClassName="myClassName" AutoEventWireup="true ...>

I fixed it by simply renaming the class name:

Control1: <%@ Control Language="C#" ClassName="myClassName1" AutoEventWireup="true ...> Control2: <%@ Control Language="C#" ClassName="myClassName2" AutoEventWireup="true ...>


Close the Solution and re-open it, then check the projects references for doubling up:

enter image description here

This can happen if you were using NuGet and changed the DLLs reference location. To fix it you have to manually edit the proj file removing the entries, eg:

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

Watch out as these "<Import" references can appear at different spots in the proj file.


A super quick and handy fix is to abuse Visual Studio's incredible intellisense by temporarily referencing the class somewhere.

Example:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

When building or hovering the cursor over the line you can view the following error:

'System.Runtime.CompilerServices.ExtensionAttribute' exists in both 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'

This tells you the two sources causing the conflict immediately.

System.Core.dll is the .dll file that you want to keep, so delete the other one.

I found mine sitting in the bin directory, but it may be elsewhere in the project.

As a matter of fact this is worth bearing in mind, because since the bin directory might not be included as part of the TFS change-set, it can explain why checking in your changes doesn't resolve the issue for other members of your team.


I'm converting an old asp.net (v 1 or 2) web site to run under .net 4.5 as a web application.

My solution was to move the user control event handler delegates that were causing the problem to a separate physical file:

//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)
    {

There are quite a multiple of reasons for this. And most of the ones mentioned above apply to different scenarios. What I noted is that the error occurs ONLY when authentication is set to something else other than 'None'. For my testing purposes I will set this off and it works.


I got re-directed here when clicking on the first Google hit when clicking on the error URL for CS0433, specifically,

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...'

Instead of outlining all the things I did to fix it, let me tell you what I did that broke it. I went to update the NuGet packages for a repo that needed a code update. The packages were pretty old (1 year or so) and all I initially tried to do was update it for a C# project.

Sometime between starting that process and encountering this error, I somehow downgraded the version of the C++ projects in that SLN to target 15063. I also noticed that the C# project had both the TargetPlatformMinVersion and TargetPlatformVersion newly set to 10.0.17134.0

The only thing I had to do to "fix" it was change the TargetPlatformMinVersion to a higher version than the TargetPlatformMinVersion for the C# project. Modifying the C++ project to either version didn't change behavior. I'm not sure why this suddenly stopped working but hopefully someone similarly blocked might get out of a pickle using similar strategies.


In addition to trying 2Toad's answer, I also ended up having to close Visual Studio and delete my .vs folder. After that, everything built correctly.

Incidentally, the error I was encountering didn't specify my Temp folder at all, but was referencing something else that was obviously system-generated. I neglected to save the specific error :\


go to web.config

in the <compilation add batch="false"

it should fix the problem


Yes,Had same issue and solved it by changing the inherits from c# code and page tag in aspx

참고URL : https://stackoverflow.com/questions/1757289/where-does-error-cs0433-type-x-already-exists-in-both-a-dll-and-b-dll-come

반응형