c# - plantillas - ¿Dónde aparece el error CS0433 "Tipo ''X'' tanto en A.dll como en B.dll"?

menu aspx c# (21)

"Solución limpia" seguida de "Reconstruir solución" parece solucionarlo también.

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

El error completo (archivo fuente Default.aspx.cs ):

Mensaje de error del compilador: CS0433: el tipo ''WebApplication3.Site1'' existe tanto en ''c: / Windows / Microsoft.NET / Framework / v2.0.50727 / Temporal 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 precedente:

Advertencia: CS0436: el tipo ''WebApplication3._Default'' en ''c: / Windows / Microsoft.NET / Framework / v2.0.50727 / Temporal ASP.NET Files / 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 / Temporal ASP.NET Files / root / aa563bcf / 59deedc0 / assembly / dl3 / 44c3a3cf / e096e61c_6568ca01 / WebApplication3 .DLL ''. Utilizando el tipo definido en ''c: / Windows / Microsoft.NET / Framework / v2.0.50727 / Temporal ASP.NET Files / root / aa563bcf / 59deedc0 / App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs''.

Fuente de puntos de advertencia para 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 una Default.aspx y una Site1.Master , sin dependencias. Están casi vacíos, con un asp:Label en 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 tiene solo un código.

En realidad, es una de las muchas pequeñas aplicaciones de prueba de disparar y olvidar, así que no podría importarme menos. Pero no había visto esto antes y ahora tengo curiosidad de 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 se aplican.

Al eliminar los archivos de clase de la carpeta App_Code y colocarlos directamente debajo del sitio web, se resolvió este problema por mí.

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

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 ya que estas referencias de "<Importar" pueden aparecer en diferentes puntos del archivo proj.

Cierre 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 bit) 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 de marco que está utilizando, si es más reciente en su servidor)

En nuestro caso, la razón fue una diferencia en las versiones .dll de los 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 al combinarlo con el siguiente web.config, falló y tiene diferentes versiones de mvc.dll.

Esto me pasó por un error en mi Web.Config

Sytem.Web.Helpers apuntaba 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 señalarlo con la referencia correcta, IIS encontró el dll local y lo utilizó en lugar de buscar en el GAC.

Esto podría 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.

O tiene la acción de compilación para los archivos .cs en App_Code como contenido o cambia el nombre de App_Code a otra cosa. Cambié el nombre ya que intellisense no corregirá los archivos .cs marcados como contenido.

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

Esto puede suceder cuando se especifica el mismo nombre de clase en múltiples archivos .aspx.cs , 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

Al compilar la aplicación we esto da una advertencia, pero la aplicación se ejecuta, sin embargo, después de publicar la aplicación ya no funciona y arroja la excepción como se menciona en la pregunta del OP.

Asegurarse de que dos nombres de clase no se superpongan resuelve el 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 esto simplemente cambiando el 2 ° "uc1" a "uc2"

Fijo...

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

Estoy convirtiendo un antiguo sitio web asp.net (v 1 o 2) para ejecutar bajo .NET 4.5 como una aplicación web.

Mi solución fue mover los delegados del controlador de eventos de control de usuarios que causaban 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) {

He encontrado 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, el error comenzó.

Mire la etiqueta Inherits de todas sus páginas aspx y páginas maestras. Es probable que haya dos clases parciales que tengan el mismo nombre. Cambia uno y vuelve 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

Para mí, al menos, esto sucedió cuando eliminé una referencia a un ensamblaje y agregué una referencia a una versión más nueva, que tenía un nombre diferente. En este caso, parece que el ensamblaje anterior permaneció en la carpeta bin y obj , y no se eliminó con la operación de solución limpia de Visual Studio (quizás porque ya no forma parte del proyecto). En este caso, fue suficiente para eliminar 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.

Sí, tuve el mismo problema y lo resolví cambiando los heredamientos del código c # y la etiqueta de página en aspx

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

Mira here para más detalles.

Espero que esto ayude a alguien.

Todavía tenía el problema después de todas estas sugerencias. Algunas clases dentro de App_Code se estaban 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 "Código de la aplicación" a "Código". Este es un proyecto MVC5, por lo que no debería haber ningún problema al publicar archivos .cs dentro de la raíz del proyecto web.

Tuve el mismo problema con dos controles ascx con 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 de la clase:

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

Tuve el problema similar. Esta es mi solución: coloque clases aisladas que requieran la propiedad [Build Action] establecida como [Compile] en cualquier carpeta que no sea App_Code como Application_Code ya que la carpeta App_Code se compilará como un ensamblaje separado, teniendo la misma clase compilada en 2 ensamblajes.

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

Ejemplo:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Al construir o colocar 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 te dice las dos fuentes que causan el conflicto de inmediato.

System.Core.dll es el archivo .dll que desea conservar, por lo que debe eliminar el otro.

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

De hecho, esto vale la pena tener en cuenta, ya que el directorio bin puede no estar incluido como parte del conjunto de cambios de TFS, puede explicar por qué el control de sus cambios no resuelve el problema para otros miembros de su equipo .

ir a web.config

en la <compilation add batch="false"

Eso debería solucionar el problema

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, código / referencia / cambio de recurso). El problema parece estar en el resultado de esta nueva compilación: por diversas razones, Visual Studio no reemplaza todo el contenido de las carpetas obj / bin de la aplicación. Esto hace que al menos algunos de los contenidos de la carpeta bin de su aplicación estén desactualizados.

Cuando se produce dicho problema, borrar la carpeta "Archivos temporales ASP.NET", solo, no resuelve el problema. No puede resolver el problema, porque los contenidos obsoletos de la carpeta bin de la aplicación se copian nuevamente en la carpeta "Archivos temporales de ASP.NET" la próxima vez que se accede a la aplicación, lo que provoca que el problema persista. La clave es eliminar todos los archivos existentes y obligar a Visual Studio a reconstruir cada objeto, por lo que la próxima vez que se acceda a la aplicación, los nuevos archivos bin se copiarán en la carpeta "Archivos temporales ASP.NET".

Solución

Cerrar Visual Studio
Realice un iisreset
Elimine todas las carpetas y archivos dentro de la carpeta "Archivos temporales ASP.NET" (se hace referencia a la ruta en el mensaje de error)
Eliminar las carpetas "obj" y "bin" de la aplicación ofensiva
Reinicie Visual Studio y abra la solución
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: eliminar todos los archivos de compilación anteriores
Pasos 5-6: crea nuevas versiones de los archivos de compilación