Where error CS0433 "Type" X "already exists in both A.dll and B.dll?

When I launch webapp from Visual Studio 2008 Service Pack 1 using an internal web server (not IIS), I get the above error.

Full error (source file Default.aspx.cs):

Compiler Error Message: CS0433: 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 "as well as" C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ build \ DL3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Previous full warning:

Warning: CS0436: 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 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'.

The warning source points to the 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 is: where did it come from?

In Webapp (and not on the site!) There is one Default.aspx and one Site1.Master, without dependencies. They are almost empty, with asp:Label on the page. This webapp used to work fine before. When I delete all links in the Default.aspx.cs wizard, everything goes well. The wizard has only some code.

This is actually one of many small test webapps, and I didn't care. But I have not seen this before, and now I am curious about what to do, and then copy the code to a new project (a cleaning solution does not help).

Note. I read this post and some others, they do not apply.

+73
c # master-pages
Nov 18 '09 at 16:34
source share
24 answers

Theory

If this problem is not caused by an application error (for example, a duplicate class name):

This problem appears after making changes to the application project, as a result of which a new assembly is created (for example, code / link / resource change). The problem is the release of this new assembly: for various reasons, Visual Studio does not replace the entire contents of your application obj / bin files. This causes at least some of the contents of your application bin folder to become outdated.

When this problem occurs, clearing the ASP.NET Temporary Files folder does not in itself solve the problem. It cannot solve the problem, because the outdated contents of your application bin folder are copied to the ASP.NET Temporary Files folder the next time you access your application, and the problem persists. The key is to delete all existing files and force Visual Studio to rebuild each object, so the next time you access your application, the new bin files will be copied to the "Temporary ASP.NET Files" folder.

Decision

  • Close Visual Studio
  • Run iisreset
  • Delete all folders and files in the folder "Temporary ASP.NET Files" (the path is indicated in the error message)
  • Delete obscene applications "obj" and "bin" folders
  • Restart Visual Studio and open the solution.
  • Follow the “Clean Solution” and then “Reconstruction Solution”

Explanation

  • Steps 1-2: remove resource locks from folders / files that you want to remove.
  • Steps 3-4: delete all old build files
  • Steps 5-6: Creating New Versions of Assembly Files
+105
Apr 02 '13 at 19:01
source share

Turn off 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 happen. Search for:

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

    (replace v4.0.30319 with the version of the framework you are using if there is more on your server)

+39
Nov 18. '09 at 16:37
source share

Take a look at the Inherits tag of all your aspx pages and master pages. Most likely, there are two partial classes that have the same name. Modify it 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

+9
Aug 10 2018-11-22T00:
source share

This can happen if you put the .cs files in App_Code and change their build action to compile in the web application project.

Either there is a build action for .cs files in App_Code as Content, or change the name of App_Code to something else. I changed the name since intellisense will not fix .cs files marked as content.

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

+9
Aug 26 '13 at 10:44 on
source share

Removing class files from the App_Code folder and placing them directly on the website solved this problem for me.

+4
Dec 30 '09 at 12:48
source share

This can also happen if your ASPX file has a duplicate TagPrefix value.

This will result in 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 second uc1 to uc2

Fixed...

 <%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %> <%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %> 
+4
Apr 05 '13 at 15:59
source share

This can happen when one class name is specified in several .aspx.cs files, i.e. when two pages are created with a different file name but mistakenly have the same class name.

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

When creating a web application, this gives a warning, but the application starts, however, after publishing the application it no longer works and throws an exception, as indicated in the OP question.

Make sure the two classes do not overlap the problem.

+3
Jun 18 2018-10-18T00:
source share

A “clean solution” followed by a “Rebuild Solution" also seems to fix it.

+3
Jan 28 '14 at 17:54 on
source share

I still had a problem after all these suggestions. Some class inside App_Code was compiled for two DLLs. 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 an MVC5 project, so there should be no problem servicing .cs files inside the root of the web project.

+3
Sep 04 '14 at 10:47 on
source share

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

When you create an ASP.NET project using Visual Studio, you may occasionally 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 \ 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 while compiling the resource needed to service this request. Please review the following specific error details and modify your source code accordingly.

Source error: line 100: line 101:
New line of notes 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 reason is that there are two assemblies in the same bin folder of a web application that contains two class definitions but have the same class name. This can happen if several Default.aspx files were compiled into one assembly. This usually happens when the main page (Default.master) and the default ASPX page (Default.aspx) both declare the _Default class. Solution: Change the class name of the main page (in most cases it is _Default) and rebuild the project. It is important to resolve any name conflict between classes.

Scenario 2

Description. The link path in Visual Studio is used to specify the folder path for the assembly links used by the project. It is possible that the path contains an assembly with the same class name. Perhaps several links have been added to one assembly (possibly with a different version or name), which can lead to a name conflict.
Solution: Delete the link to the old version. To do this, in Visual Studio, right-click your website and select "Links" in the properties.

Scenario 3

Description: By default, when compiling an ASP.NET web application, the compiled code is placed in the ASP.NET temporary files folder. By default, access rights are granted to the local ASP.NET account, which has the high-level permissions required to access the compiled code. It is possible that some changes have occurred in the default permissions that have led to version conflicts. Another possibility is that antivirus software can inadvertently block an assembly. Solution: Empty the ASP.NET temporary files folder from all contents.

Scenario 4

Description: If the batch attribute in the web.config file is set to True, this eliminates the delay caused by compilation, which is required when the file is first accessed. ASP.NET precompiles all uncompiled files in batch mode, which causes delays when compiling files for the first time. Disabling batch compilation can lead to masked compilation errors that may exist in the application but are not reported. However, more important for this problem, ASP.NET dynamically compiles individual .aspx / .ascx files into separate assemblies, rather than into a single assembly. Solution: set batch = false in the section in web.config. This should be considered a temporary solution, since setting batch = false in the compilation section has a significant impact on performance for application build time in Visual Studio.

Scenario 5

Description. Changing the web.config file for an ASP.NET application or changing the file in the bin folder (for example, adding, deleting, or renaming) will restart AppDomain. When this happens, all session state is lost, and cached items are removed from the cache when the website is restarted. It is possible that the problem is caused by an inconsistent state in the web application. Decision. Restart the application domain by touching (editing) the web.config file.

Scenario 6

Description: You can save the source code in the App_Code folder, and it will be automatically compiled at runtime. The resulting assembly is available for any other code in the web application. Therefore, the App_Code folder works the same as the Bin folder, except that you can store the source code in it instead of the compiled code. The class will be recompiled when the source file changes. If there is a conflict due to an outdated assembly, then forced recompilation can solve the problem. Decision. Touch the file in the Bin or App_Code folders to start a full recompilation.

+3
Jan 31 '19 at 19:56
source share

This happened to me due to 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"/> 

Sytem.Web.Helpers is pointed at 1.0.0.0 instead of 3.0.0.0 (MVC 3 is used in this project).

Since IIS could not find the link in the local folder, it looked in the GAC and found two different versions. After pointing it with the correct link, IIS discovered a local dll and used this instead of looking for a GAC.

+2
Mar 13 '14 at 19:23
source share

I found another reason: different versions used for toolbar icons and links in the project. An error occurred after inserting objects in some form.

+2
Jun 13 '14 at 7:34
source share

In the end, I changed the way links to MasterType on the page.

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

See here for more details.

Hope this helps someone.

0
Jun 26 '14 at 22:58
source share

I had the same issue with two ascx controls having the 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 ...>

0
Dec 13 '14 at 16:42
source share

At least for me, this happened when I deleted the link to the assembly and added a link to its new version, 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 using the clean solution operation from Visual Studio (possibly because this 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 it occurred from Windows Explorer (or the file management tool). Then, from Visual Studio, clear the solution and rebuild.

0
Apr 15 '15 at 20:55
source share

In our case, the reason was the difference in the .dll versions for sites in IIS. They are placed under each other in IIS, allowing you to access the other through a subdomain. It inherits from the first web.config and combines it with the following web.config, it does not work with different versions of mvc.dll.

0
Apr 24 '15 at 8:07
source share

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

0
Sep 15 '16 at 13:13
source share

Close the solution and open it, then check the project links for doubling :

enter image description here

This can happen if you were using NuGet and changed the location of the DLL links. To fix this, you need to manually edit the proj file by deleting entries, for example:

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

Make sure that these "<Import" links can appear in different places of the proj file.

0
Nov 13 '16 at 23:59
source share

A super quick and convenient fix is ​​to abuse Visual Studio's incredible intellisense by temporarily referring to a class somewhere.

Example:

 System.Runtime.CompilerServices.ExtensionAttribute x = null; 

When you create or hover over a line, you may see the following error:

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

This suggests two sources of conflict at once.

System.Core.dll is the DLL file you want to save, so delete another.

I found my place in the bin , but maybe in another place in the project.

This is actually worth keeping in mind, because since the bin directory cannot be included as part of the TFS change set, it can explain why checking your changes does not solve the problem for other members of your team.

0
Jun 02 '17 at 15:57
source share

I am converting an old asp.net website (v 1 or 2) to work under .net 4.5 as a web application.

My solution was to move the delegates of the user control event handler that caused 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) { 
0
Mar 05 '18 at 17:33
source share

There are many reasons for this. And most of the above apply to various scenarios. What I noticed is that the error occurs ONLY if authentication is set to a value other than "No". For my testing purposes, I will disable this and it works.

0
Aug 20 '18 at 9:09
source share

I was redirected here when I clicked on the first Google hit when I clicked on the error URL for CS0433 , specifically

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

Instead of spelling out everything I did to fix it, let me tell you what I did that broke it. I went to update NuGet packages for a repository that needed code updating. The packages were pretty old (about 1 year) and all I originally tried to do was update them for a C # project.

Sometime between starting this process and finding this error, I somehow downgraded the version of C ++ projects in this SLN to goal 15063 . I also noticed that in the C # project, TargetPlatformMinVersion and TargetPlatformVersion have recently been set to 10.0.17134.0

The only thing I needed to do to “fix” it was to change TargetPlatformMinVersion to a higher version than TargetPlatformMinVersion for a C # project. Changing the C ++ project for any version did not change the behavior. I'm not sure why this suddenly stopped working, but hopefully someone who is blocked this way can get out of the brine using similar strategies.

0
Jun 13 '19 at 1:46
source share

go to web.config

in <compilation add batch="false"

he must fix the problem

-2
Oct 23
source share

Yes, I had the same problem and solved it by changing the inheritance from C # code and page tag in aspx

-2
Jul 16 '14 at 8:46
source share



All Articles