¿De dónde viene el error CS0433 "Type 'X' ya existe tanto en A.dll como en B.dll"?

Cuando ejecuto una aplicación web desde Visual Studio 2008 SP1 usando el servidor web interno (no IIS), recibo el error mencionado anteriormente.

El error completo (archivo de origen Default.aspx.cs ):

Mensaje de error del compilador: CS0433: El tipo 'WebApplication3.Site1' existe tanto en 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll 'y' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

La advertencia completa anterior:

Advertencia: CS0436: el tipo 'WebApplication3._Default' en 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs 'entra en conflicto con el tipo importado' WebApplication3._Default 'en' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL '. Usando el tipo definido en 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.

La fuente de advertencia apunta a un archivo intermedio 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;

y mi pregunta: ¿de dónde viene esto?

La aplicación web (¡no el sitio web!) Tiene un Default.aspx y un Site1.Master , sin dependencias. Están casi vacíos, con un asp:Labelen la página. Anteriormente, esta aplicación web funcionaba bien. Cuando elimino cualquier referencia en Default.aspx.cs al maestro, todo va bien. El maestro solo tiene un código.

En realidad, es una de las muchas aplicaciones web de prueba de disparar y olvidar, por lo que no podría importarme menos. Pero no había visto esto antes y ahora tengo curiosidad por saber qué hacer, aparte de copiar el código en un nuevo proyecto (la solución de limpieza no ayuda).

Nota: He leído esta publicación y algunas otras, no aplican.

Teoría

Cuando este problema no es causado por un error en la aplicación (por ejemplo, nombre de clase duplicado):

Este problema parece presentarse después de que se realiza un cambio en el proyecto de la aplicación que da como resultado una nueva compilación (por ejemplo, cambio de código / referencia / recurso). El problema parece estar en el resultado de esta nueva compilación: por varias razones, Visual Studio no reemplaza todo el contenido de las carpetas obj / bin de su aplicación. Esto da como resultado que al menos parte del contenido de la carpeta bin de su aplicación esté desactualizado.

Cuando ocurre dicho problema, limpiar la carpeta "Archivos temporales ASP.NET", por sí solo, no resuelve el problema. No puede resolver el problema, porque el contenido obsoleto de la carpeta bin de su aplicación se copia de nuevo en la carpeta "Archivos temporales ASP.NET" la próxima vez que se accede a su aplicación, lo que hace que el problema persista. La clave es eliminar todos los archivos existentes y forzar a Visual Studio a reconstruir cada objeto, de modo que la próxima vez que se acceda a su aplicación, los nuevos archivos bin se copiarán en la carpeta "Archivos temporales ASP.NET".

Solución

1. Cerrar Visual Studio
2. Realice un iisreset
3. Elimine todas las carpetas y archivos dentro de la carpeta "Archivos ASP.NET temporales" (la ruta se menciona en el mensaje de error)
4. Elimina las carpetas "obj" y "bin" de la aplicación infractora
5. Reinicie Visual Studio y abra la solución
6. Realice una "Solución limpia" seguida de una "Solución de reconstrucción"

Explicación

• Pasos 1-2: elimine los bloqueos de recursos de las carpetas / archivos que necesitamos eliminar.
• Pasos 3-4: elimine todos los archivos de compilación antiguos
• Pasos 5-6: cree nuevas versiones de los archivos de compilación

Apague w3svc y elimine todo de c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

adicional

• en Windows 7

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

• en servidores IIS (64 bits) esto también puede ocurrir. Buscar:

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

  (reemplace v4.0.30319 por la versión del marco que está usando si es más nueva en su servidor)

Esto puede suceder si coloca archivos .cs en App_Code y cambia su acción de compilación para compilar en un proyecto de aplicación web.

Tenga la acción de compilación para los archivos .cs en App_Code como Contenido o cambie el nombre de App_Code por otro. Cambié el nombre porque intellisense no arreglará los archivos .cs marcados como contenido.

Más información en http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Mire la etiqueta Hereda de todas sus páginas aspx y páginas maestras. Es probable que haya dos clases parciales que tengan el mismo nombre. Cambie uno y vuelva a compilar.

Aquí hay más información:

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

Seguía teniendo el problema después de todas estas sugerencias. Alguna clase dentro de App_Code se estaba compilando en dos DLL. Algo como esto (simplificado):

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

Acabo de cambiar el nombre de la carpeta "App_Code" a "Código". Este es un proyecto MVC5, por lo que no debería haber ningún problema con la entrega de archivos .cs dentro de la raíz del proyecto web.

Quitar los archivos de clase de la App_Codecarpeta y colocarlos directamente debajo del sitio web me resolvió este problema.

Esto también puede suceder si tiene TagPrefix duplicado en su archivo ASPX.

Esto causaría este error ...

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

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

Puede solucionar este problema simplemente cambiando el segundo "uc1" a "uc2"

Fijo...

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

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

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

Al crear un proyecto ASP.NET con Visual Studio, es posible que vea un mensaje de error similar al siguiente al azar:

Mensaje de error del compilador: CS0433: El tipo 'ASP.summary_common_controls_notes_ascx' existe tanto en 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' y ' c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Archivos temporales ASP.NET \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Descripción: se produjo un error durante la compilación de un recurso necesario para atender esta solicitud. Revise los siguientes detalles específicos del error y modifique su código fuente de manera apropiada.

Error de origen: Línea 100: Línea 101:
Notas nuevas Línea 102:
Línea 103:
1450 Línea 104:

Resumen.

Archivo de origen: d: \ http \ post \ publisher \ default.aspx Línea: 102

Los escenarios comunes donde puede ocurrir este error se analizan a continuación.

escenario 1

Descripción: una causa común es cuando hay dos ensamblados en la misma carpeta bin de la aplicación web que contienen dos definiciones de clase pero que tienen el mismo nombre de clase. Esto puede suceder si se compiló más de un Default.aspx en un solo ensamblado. Por lo general, esto ocurre cuando la página maestra (Default.master) y la página ASPX predeterminada (Default.aspx) declaran una clase _Default. Solución: cambie el nombre de clase de la página maestra (de _Default en la mayoría de los casos) y reconstruya el proyecto. Es importante resolver cualquier conflicto de nombres entre clases.

Escenario 2

Descripción: Las rutas de referencia en Visual Studio se utilizan para especificar la ruta de la carpeta para las referencias de ensamblado utilizadas por el proyecto. Es posible que la ruta contenga un ensamblado que contenga el mismo nombre de clase. Puede ser que se agreguen varias referencias al mismo ensamblado (posiblemente una versión o nombre diferente) que provoquen un conflicto de nombres.
Solución: elimine la referencia de la versión anterior. Para hacerlo, en Visual Studio, haga clic con el botón derecho en su sitio web y marque las "Referencias" en las propiedades.

Escenario 3

Descripción: De forma predeterminada, cuando se compila una aplicación web ASP.NET, el código compilado se coloca en la carpeta Archivos temporales de ASP.NET. De forma predeterminada, los permisos de acceso se otorgan a la cuenta de usuario local de ASP.NET, que tiene los permisos de alta confianza necesarios para acceder al código compilado. Es posible que haya algunos cambios en los permisos predeterminados que causen conflictos de versiones. Otra posibilidad sería que el software antivirus estuviera bloqueando un ensamblaje sin darse cuenta. Solución: borre todo el contenido de la carpeta de archivos temporales de ASP.NET.

Escenario 4

Descripción: cuando el atributo de lote en web.config se establece en True, elimina el retraso causado por la compilación requerida cuando accede a un archivo por primera vez. ASP.NET precompila todos los archivos no compilados en modo por lotes, lo que provoca retrasos la primera vez que se compilan los archivos. Desactivar la compilación por lotes puede exponer errores de compilación enmascarados que pueden existir en la aplicación pero que no se informan. Sin embargo, lo que es más importante para este problema, le dice a ASP.NET que compile dinámicamente archivos .aspx / .ascx individuales en ensamblajes separados en lugar de en un solo ensamblaje. Solución: establezca batch = false en la sección de web.config. Esto debe considerarse una solución temporal, ya que establecer batch = false en la sección de compilación tiene un impacto significativo en el rendimiento de los tiempos de compilación de la aplicación en Visual Studio.

Escenario 5

Descripción: la modificación del archivo web.config para una aplicación ASP.NET o el cambio de un archivo en la carpeta bin (como agregar, eliminar o cambiar el nombre) hace que AppDomain se reinicie. Cuando esto ocurre, todo el estado de la sesión se pierde y los elementos almacenados en caché se eliminan del caché cuando se reinicia el sitio web. Es posible que el problema sea causado por un estado inconsistente en la aplicación web. Solución: active un reinicio de AppDomain tocando (editando) el archivo web.config.

Escenario 6

Descripción: Puede almacenar el código fuente en la carpeta App_Code y se compilará automáticamente en tiempo de ejecución. El ensamblado resultante es accesible para cualquier otro código en la aplicación web. Por lo tanto, la carpeta App_Code funciona de manera muy similar a la carpeta Bin, excepto que puede almacenar el código fuente en ella en lugar del código compilado. La clase se volverá a compilar cuando haya un cambio en el archivo fuente. Si hay un conflicto debido a un ensamblado desactualizado, forzar una recompilación puede resolver el problema. Solución: toque un archivo en las carpetas Bin o App_Code para activar una recompilación completa.

Esto me pasó por un error en mi 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"/>

Se Sytem.Web.Helpersapuntó a 1.0.0.0 en lugar de 3.0.0.0 (MVC 3 se está utilizando en este proyecto).

Como IIS no pudo encontrar la referencia en la carpeta local, buscó en el GAC y encontró dos versiones diferentes. Después de apuntar a la referencia correcta, IIS encontró el dll local y lo usó en lugar de buscar el GAC.

Esto puede suceder cuando se especifica el mismo nombre de clase en varios .aspx.csarchivos, es decir, cuando se crean dos páginas con un nombre de archivo diferente pero por error tienen el mismo nombre de clase.

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

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

Mientras se construye la aplicación web, esto da una advertencia, pero la aplicación se ejecuta, sin embargo, después de publicarla, la aplicación ya no funciona y lanza la excepción como se menciona en la pregunta del OP.

Asegurarse de que dos nombres de clases no se superpongan resuelve el problema.

Encontré otra razón: diferentes versiones utilizadas para iconos en la caja de herramientas y referencias en el proyecto. Después de insertar los objetos de alguna forma, comenzó el error.

"Solución limpia" seguida de "Solución de reconstrucción" parece arreglarlo también.

Terminé cambiando cómo se hace referencia al MasterType en la marca de página.

Cambié: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> a<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Ver aqui para obtener más detalles.

Espero que esto ayude a alguien.

Para mí, al menos, esto sucedió cuando eliminé una referencia a un ensamblado y agregué una referencia a una versión más reciente, que tenía un nombre diferente. En este caso, parece que el ensamblado anterior permaneció en la carpeta bin y obj , y no se eliminó con la operación de solución limpia de Visual Studio (tal vez porque ya no es parte del proyecto). En este caso, fue suficiente borrar el contenido de las carpetas bin y obj del proyecto donde ocurre el error, desde el Explorador de Windows (o una herramienta de administración de archivos). Luego, desde Visual Studio, limpie la solución y reconstruya.

En nuestro caso, la razón fue una diferencia en las versiones .dll de sitios en IIS. Se colocan uno debajo del otro en IIS, lo que le permite acceder al otro a través de un subdominio. Hereda del primer web.config y, combinándolo con el siguiente web.config, falló, ya que tenía diferentes versiones de mvc.dll.

Tuve un problema similar. Esta es mi solución: coloque clases aisladas que requieran un [Build Action]conjunto de propiedades [Compile]en cualquier carpeta que no sea App_Codesimilar, Application_Codeya que la App_Codecarpeta se compilará como un ensamblaje separado, teniendo la misma clase compilada en 2 ensamblados.

Tuve el mismo problema con dos controles ascx que tienen el mismo nombre de clase:

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

Lo arreglé simplemente cambiando el nombre del nombre de la clase:

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

Cierre la solución y vuelva a abrirla, luego verifique las referencias de proyectos para duplicar :

Esto puede suceder si estaba usando NuGet y cambió la ubicación de referencia de las DLL. Para solucionarlo, debe editar manualmente el archivo proj eliminando las entradas, por ejemplo:

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

Tenga cuidado porque estas referencias "<Importar" pueden aparecer en diferentes puntos del archivo de proyecto.

Una solución súper rápida y práctica es abusar del increíble intellisense de Visual Studio al hacer referencia temporal a la clase en algún lugar.

Ejemplo:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Al construir o pasar el cursor sobre la línea, puede ver el siguiente error:

'System.Runtime.CompilerServices.ExtensionAttribute' existe en ambos 'C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll'

Esto le indica las dos fuentes que causan el conflicto de inmediato.

System.Core.dll es el archivo .dll que desea conservar, así que elimine el otro.

Encontré el mío en el bindirectorio, pero puede estar en otra parte del proyecto.

De hecho, vale la pena tener esto en cuenta, ya que dado que es posible que el bindirectorio no se incluya como parte del conjunto de cambios de TFS, puede explicar por qué la verificación de sus cambios no resuelve el problema para otros miembros de su equipo.

Estoy convirtiendo un antiguo sitio web asp.net (v 1 o 2) para que se ejecute en .net 4.5 como una aplicación web.

Mi solución fue mover los delegados del controlador de eventos de control de usuario que estaban causando el problema a un archivo físico separado:

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

Hay muchas razones para esto. Y la mayoría de los mencionados anteriormente se aplican a diferentes escenarios. Lo que noté es que el error ocurre SOLAMENTE cuando la autenticación se establece en otra cosa que no sea 'Ninguno'. Para mis propósitos de prueba, lo activaré y funciona.

Me redirigieron aquí al hacer clic en el primer resultado de Google al hacer clic en la URL de error para CS0433, específicamente,

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

En lugar de describir todas las cosas que hice para solucionarlo, déjame decirte qué hice que lo rompió. Fui a actualizar los paquetes de NuGet para un repositorio que necesitaba una actualización de código. Los paquetes eran bastante antiguos (aproximadamente un año) y todo lo que intenté hacer inicialmente fue actualizarlos para un proyecto de C #.

En algún momento entre el inicio de ese proceso y la aparición de este error, de alguna manera bajé la versión de los proyectos de C ++ en ese SLN al objetivo 15063. También noté que el proyecto C # tenía tanto el TargetPlatformMinVersiony TargetPlatformVersionrecién configurado como10.0.17134.0

Lo único que tuve que hacer para "arreglarlo" fue cambiar TargetPlatformMinVersiona una versión superior a la TargetPlatformMinVersiondel proyecto C #. La modificación del proyecto de C ++ a cualquiera de las versiones no cambió el comportamiento. No estoy seguro de por qué esto dejó de funcionar repentinamente, pero espero que alguien bloqueado de manera similar pueda salir de un aprieto utilizando estrategias similares.

Además de probar la respuesta de 2Toad, también terminé teniendo que cerrar Visual Studio y eliminar mi carpeta .vs. Después de eso, todo se construyó correctamente.

Por cierto, el error que estaba encontrando no especificaba mi carpeta Temp en absoluto, pero hacía referencia a otra cosa que obviamente fue generada por el sistema. Me olvidé de guardar el error específico: \

si ninguna otra solución funcionó, simplemente cambie el nombre de la clase heredada de ese problema que causa el archivo aspx y el archivo aspx.cs a un nuevo nombre, luego reconstruya la solución. entonces el problema se resolverá con seguridad. esto solo funcionó para mí.

p.ej :

en el archivo aspx, haga lo siguiente, cambie el nombre de la clase heredada a Defaultnew

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

en el archivo aspx.cs cambie el nombre de la clase al mismo que se usa en el archivo aspx

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

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