Error cs0433 the type exists in both

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:WindowsMicrosoft.NETFramework64v2.0.50727Temporary ASP.NET FilesBook_Detailsabc12345def8910App_Web_msftx123.dll’ and ‘c:WindowsMicrosoft.NETFramework64v2.0.50727Temporary ASP.NET FilesBook_Detailsabc12345def8910App_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:httppostpublisherdefault.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.

Hi:

I have faced to this issue frequently to be honest!!!

Sh****  It happens while operation as the following:

• Debugging
• Hitting some break point
• In VS Immediate window, or Quick Watch window (anywhere you can type some temp codes to get some debugging temp results)
• The codes I type in contains some Types which Revit API supplies
• Those Types with the same name (but their complete runtime names are not the same) exist in more than one DLL files
• Those DLL files are loaded during the Revit managed process lift cycle

Now I guess that you have figured out that .NET runtime is managing the Revit Process (at least partly managing).

I think VS debugger is visiting the whole managed process to lookup some Types that match your codes typed into Immediate Window.

So, this issue has nothing to do with your VS Solution references. C# solution references are «static», while managed process loads .DLL files (aka Assembly) dynamically.

My by-pass is:

• type in complete C# runtime Type name: like Autodesk.Revit.DB.Element
• Or use an extension method for printing some useful debug info

        public static string ToString2(this MEPCurve elem, int digit = 2)
        {
            digit = Math.Abs(digit);
            if (elem == null)
                return @"|elem == null|";
            else if (!elem.IsValidObject)
                return @"|elem.IsValidObject == false";
            else
            {
                using (Curve curve = (elem.Location as LocationCurve)?.Curve)
                    return elem.GetType().Name + '-' + elem.Id + '-' + curve.ToString2(digit);
            }
        }

The above codes don’t actually solve this problem, but it does help us to by-pass it, don’t it?

If I want to check some suspectable info that might catch my attention, but debugger returns back an ERROR, I would like to use some Printing methods to get some info.

These printing methods are named by myself or our team. We make it sure that their names are never duplicated.

For example, we define only ONE extension method named as ToString2() for the Type Autodesk.Revit.DB.Element.

Hope your life easier.

Nice working day

单身狗；代码狗；健身狗；jolinpiggy@hotmail.com

I’m upgrading a Unity custom project with an ML-Agents 0.4b version to the last 1.0 and I’m getting 12 errors like this:

LibraryPackageCachecom.unity.timeline@1.2.6EditorWindowTimelineWindow_Breadcrumbs.cs(91,47): error CS0433: The type 'ValueTuple<T1, T2>' exists in both 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

LibraryPackageCachecom.unity.barracuda@0.7.0-previewBarracudaRuntimeCoreBackendsBarracudaCompute.cs(586,25): error CS0433: The type 'ValueTuple<T1, T2, T3>' exists in both 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

…

I’m a junior self-taught dev and I’m not confident on what I have to do. I found some links about it, but I don’t know how to implement it:

dotnet/roslyn#21156

On this link there is a reference to this pull request: dotnet/roslyn@850799c

but I have no idea what I should change to fix it.

I would like to know, also, what I should study to be capable to deal with this kind of problems. Any recommendation?