[c#] Where does error CS0433 "Type 'X' already exists in both A.dll and B.dll " come from?

When I run a webapp from Visual Studio 2008 SP1 using the internal web server (not IIS) I receive the above mentioned error.

The full error (source file Default.aspx.cs):

Compiler Error Message: CS0433: The type 'WebApplication3.Site1' exists in both 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_site1.master.cdcab7d2.muczzy9v.dll' and 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\assembly\dl3\44c3a3cf\80dd34ed_6968ca01\WebApplication3.DLL'

The preceding full warning:

Warning: CS0436: The type 'WebApplication3._Default' in 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs' conflicts with the imported type 'WebApplication3._Default' in 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\assembly\dl3\44c3a3cf\e096e61c_6568ca01\WebApplication3.DLL'. Using the type defined in 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.

Source of warning points to an intermediate file 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;

and my question: where does this come from?

The webapp (not website!) has one Default.aspx and one Site1.Master, no dependencies. They're almost empty, with an asp:Label on the page. Previously, this webapp worked fine. When I remove any references in Default.aspx.cs to the master, all goes well. The master has some code only.

It's actually one of many little fire-and-forget test webapps, so I couldn't care less. But I hadn't seen this before and now I'm curious of what to do, other then copying code into a new project (cleaning solution doesn't help).

Note: I've read this post and some others, they don't apply.

if no other solution worked, then just rename the inherits class of that problem causing aspx file and aspx.cs file to a new name, then rebuild the solution. then the issue will be solved for sure. this only worked for me.

eg :

in the aspx file do the following change the inherits class name to Defaultnew

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

in the aspx.cs file rename the class to the same as used in aspx file

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

public partial class Defaultnew : System.Web.UI.Page
{

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

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

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

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 still had the problem after all these suggestions. Some class inside App_Code was being compiled to two DLL's. Something like this (simplified):

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

I just renamed the "App_Code" folder to "Code". This is a MVC5 project, so there shouldn't be a problem with serving .cs files inside the web project's root.

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.

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 might happen if you place .cs files in App_Code and changed their build action to compile in a Web Application Project.

Either have the build action for the .cs files in App_Code as Content or change the name of App_Code to something else. I changed the name since intellisense won't fix .cs files marked as content.

More info at http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Look at the Inherits tag of all your aspx pages and master pages. Chances are there are two partial classes that have the same name. Change one and recompile.

Here is some more info:

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

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

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.

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

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.

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.

Reference : https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

When building an ASP.NET project using Visual Studio, you may randomly see an error message similar to the following:

Compiler Error Message: CS0433: The type 'ASP.summary_common_controls_notes_ascx' exists in both 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll' and 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll'

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.

Source Error: Line 100: Line 101:
New Notes Line 102:
Line 103:
1450 Line 104:

Summary.

Source File: d:\http\post\publisher\default.aspx Line: 102

Common scenarios where this error can occur are discussed below

Scenario 1

Description: A common cause is when there are two assemblies in the same web application bin folder containing two class definitions but that have the same class name. This can happen if more than one Default.aspx was compiled into a single assembly. Commonly, this occurs when the Master page (Default.master) and the Default ASPX page (Default.aspx) both declare a _Default class. Solution: Change the class name of the master page (from _Default in most cases) and rebuild the project. It is important to resolve any naming conflict between classes.

Scenario 2

Description: The Reference Paths in Visual Studio is used to specify the folder path for assembly references used by the project. It is possible that the path contains an assembly that contains the same class name. It may be that there are multiple References added to the same assembly (possibly different version or name) causing a naming conflict.
Solution: Remove the old version reference. To do so, in Visual Studio right-click your web site and check the "References" in the properties.

Scenario 3

Description: By default, when an ASP.NET Web application is compiled the compiled code is placed in the Temporary ASP.NET Files folder. By default the access permissions are given to the ASP.NET local user account, which has the high-trust permissions needed to access compiled code. It is possible that there were some changes in the default permissions causing versioning conflicts. Another possibility would be that anti-virus software could be locking an assembly inadvertently. Solution: Clear the Temporary ASP.NET Files Folder of all contents.

Scenario 4

Description: When the batch attribute in the web.config is set to True it eliminates the delay caused by the compilation required when you access a file for the first time. ASP.NET precompiles all the un-compiled files in a batch mode, which causes delays the first time the files are compiled. Turning off batch compilation may expose masked compilation errors that may exist in the application but are not reported. However more importantly for this issue it tells ASP.NET to dynamically compile individual .aspx/.ascx files into separate assemblies instead of into a single assembly. Solution: Set batch=false in the section in web.config. This should be considered a temporary solution as setting batch=false in the compilation section has a significant performance impact on build times for the application in Visual Studio.

Scenario 5

Description: Modifying the web.config file for an ASP.NET application or changing a file in the bin folder (such as adding, deleting, or renaming) causes the AppDomain to restart. When this occurs all session state is lost and cached items are removed from the cache as the website restarts. It is possible that the problem is caused by an inconsistent state in the web application. Solution: Trigger an AppDomain restart by touching (editing) the web.config file.

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

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.

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.

This may also happen if you have duplicate TagPrefix in your ASPX file.

This would cause this error...

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

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

You can fix this by simply changing the 2nd "uc1" to "uc2"

Fixed...

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

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

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.

Shut down w3svc and delete everything from c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

added

• on Windows 7

  c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

• on IIS servers (64 bit) this can also occur. Look for:

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

  (replace v4.0.30319 by the framework version you're using if newer on your server)

Removing the class files from the App_Code folder, and placing them directly under the website, solved this issue for me.

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.

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.