Error de ASP.Net: “El tipo ‘foo’ existe tanto en” temp1.dll “como en” temp2.dll “

Al ejecutar un proyecto de aplicación web, en tiempos aparentemente aleatorios, una página puede fallar con un error CS0433: el tipo existe en varias DLL. Las DLL son todas las DLL generadas que residen en el directorio “Archivos temporales de ASP.NET”.

Agregue el atributo batch = “false” al elemento “comstacktion” del archivo web.config.

Este problema se produce debido a la forma en que ASP.NET 2.0 utiliza las referencias de la aplicación y la estructura de la carpeta de la aplicación para comstackr la aplicación. Si la propiedad de lote del elemento en el archivo web.config para la aplicación se establece en verdadero, ASP.NET 2.0 comstack cada carpeta de la aplicación en un ensamblaje separado.

http://www.sellsbrothers.com/1995

http://support.microsoft.com/kb/919284

Esto podría suceder si coloca archivos .cs en App_Code y cambia su acción de comstackción para comstackr en un proyecto de aplicación web.

O tiene la acción de comstackció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

Una posible razón de este error es que hay 2 páginas aspx que tienen el mismo nombre en sus <@page language=......inherits=> inherits= en la línea <@page language=......inherits=> .

Cambiar el inherits= nombre resuelve el error.

Solo en caso de que alguien más comparta mi problema, recibí este error al intentar publicar un sitio web de un proyecto recién ramificado, la comstackción funcionó perfectamente.

Resulta que olvidé eliminar la checkbox “Permitir que el sitio precomstackdo sea actualizable” en Configuración de publicación -> Configurar precomstackción .

Como otro punto de datos, acabo de tener este problema sin ninguna evidencia de referencias circulares como se describe en los enlaces en la respuesta de Ben. La creación de mi proyecto de sitio web fallaría con algunos de estos errores, y establecer la comstacktion batch="false" solucionó, pero no quería ir por esa ruta, ya que este es un sitio web de producción de gran tamaño.

Esta solución estaba en una subcarpeta de mi carpeta D: \ svn, que había mapeado a S :. Cuando abrí la solución de S :, ocurrieron estos errores, pero si fui directamente a D: \ svn y abrí la solución, no hubo errores.

También noté que, a pesar de tener el comstacktion batch="true" en mi web.config, al abrir la solución del disco S: asignado, todos mis archivos .ascx se comstackn en sus propios ensamblajes. Si lo abro desde la ubicación física, los archivos .ascx se comstackn en los ensamblados de sus respectivas carpetas (que es como se supone que funciona el batch="true" ).

Extraño.

En mi caso, al eliminar todas las ensamblajes de salida de las carpetas bin en todos los proyectos de la solución, se solucionó el problema. Desafortunadamente no tengo ninguna explicación para eso.

Este error se debió a un conflicto entre el nombre de clase del formulario web y el código auxiliar wsdl (código detrás del archivo .cs) que tiene el mismo nombre de clase, es decir,

Página ASPX: Tablero de clase: panel de clase de partiacl

AppCode / APIServices.cs: Panel de clase parcial público

El error fue reproducible solo al publicar el sitio web, pero la comstackción y la depuración no informaron ningún error.

En mi caso, he cambiado el nombre de un proyecto, por lo que también se cambió el nombre del dll. Cuando acabo de copiar el nuevo dll pero no pensé en eliminar el anterior del servidor, pronto tuve un grupo de pares con los mismos nombres. Eliminar el dll obsoleto estaba haciendo el truco (de causa).

Ninguna de estas respuestas funcionó para mí, sin embargo, solucioné el problema. Como estaba usando la función de publicación de VS para implementar la aplicación web, seleccioné la opción para eliminar todos los archivos existentes antes de publicar en el asistente de publicación web. Esto forzó una copia limpia de la aplicación y todo funcionó bien desde allí.

Esta solución puede ser útil si su copia de depuración local funciona bien, pero el sistema publicado no lo es. También es excelente si no desea tomarse el tiempo para rastrear dlls individuales para eliminar y no le molesta que los archivos de producción se eliminen primero.

En mi caso, el problema se resolvió cuando edité un archivo Designer.cs que todavía tenía el nombre de clase duplicado. por alguna razón, cuando cambié el nombre de la clase “cerrar sesión” por “logout2”, en el archivo del diseñador no se cambió automáticamente, y aún estaba “desconectado”, y este nombre de clase ya existía en un dll precomstackdo en mi proyecto (que pertenece a una aplicación web de terceros con la que trabajo y desarrollé).

Tengo este problema cuando coloco una parte de una página aspx en el control de usuario por separado. En mi máquina todo estaba bien, en el servidor obtuve un error.

Se cambió el nombre de la clase y el archivo del problema.

http://support.microsoft.com/kb/919284 Método 2: Reordenar las carpetas en la aplicación está escribiendo sobre posibles referencias circulares

Ninguna de estas soluciones funcionó para mí. Mis dos DLL en conflicto estaban en C: \ … \ AppData \ … \ Archivos temporales de ASP.NET \ …

El problema era que había retirado mi repository de origen a una versión anterior, antes de mover un tipo de un proyecto a otro dentro de la misma solución.

Traté de eliminar la DLL más nueva, que ni siquiera debería haber estado allí en la base de código anterior, en la ubicación “Archivos temporales de ASP.NET” identificada por msbuild. msbuild simplemente lo devolvió.

También probé la configuración web.config que algunos aquí han utilizado con éxito, pero tampoco funcionó. Aunque, mientras escribo esto, me doy cuenta de que en realidad había dos proyectos de MVC dentro de la misma solución y que ambos tenían errores, por lo que el problema pudo haber sido que no agregué la configuración a ambos.

Traté de rodar mi repository de origen hacia adelante y limpiar y volver a rodar y limpiar. Nada.

Traté de eliminar todo la ubicación “Archivos temporales ASP.NET”. msbuild simplemente lo devolvió.

Finalmente, intenté reconstruir en Visual Studio. Aunque la salida de línea de comando y la salida “Errores” dieron el mismo error msbuild “Archivos ASP.NET temporales”, el error de Intellisense, al pasar el ratón sobre el tipo en conflicto, en realidad se quejó de las DLL en los directorios de salida. Aparentemente, “Limpiar” y “Reconstruir” no estaban haciendo su trabajo. Borré manualmente las DLL en los directorios de salida identificados por Intellisense, y el problema fue resuelto.

tl; dr: asegúrate de que estás cubriendo todos tus web.configs con la configuración de lote y trata de aprovechar Intellisense para obtener más pistas.

Mi problema estaba relacionado con un archivo .dll que se estaba generando en la carpeta de mi proyecto.

Si está haciendo referencia a otro archivo, en lugar de hacer todo lo que ve arriba, lo que solucionó mi problema instantáneamente fue simplemente eliminar el archivo .dll que estaba dentro de mi directorio / bin para mi proyecto.

El problema no es necesariamente una solución web.config, es una referencia circular que debe resolverse. Me di cuenta de que borraba el archivo .dll anterior en mi archivo de proyecto original, pero no en el proyecto que estaba haciendo referencia a él.

No recomiendo hacer la modificación a su archivo web.config porque es solo una solución de parche, no realmente abordando el problema real. Hazlo si no tienes ganas de solucionar el problema, pero si quieres evitar futuros dolores de cabeza, simplemente elimina el .dll de ambos lugares.

Tuve una clase parcial con el mismo nombre en dos proyectos diferentes. Lo resolví solo dejándolo en un proyecto.

En ocasiones, puede ser útil eliminar la solución y volver a crearla. Como este uso ocurre cuando se convierte de VS2005 a vs2010, algunas referencias al framework 4.0 (después de la actualización) permanecen en la solución, incluso todos los proyectos se definen como 3.5.

Normalmente, la reconstrucción de la solución debería aclarar estos problemas.

Tuve el mismo problema cuando estaba comstackndo la aplicación en un servidor de comstackción.

Mi controlador tenía un código estático simple, así que cambié mi ascx:

  <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="controllerName.ascx.cs" Inherits="Controls.controllerName" %> 

A

  <%@ Control Language="C#" AutoEventWireup="true" Src="controllerName.ascx.cs" Inherits="Controls.controllerName" %> 

También eliminó la palabra clave parcial del código subyacente y agregó un espacio de nombres al código subyacente.

Esta:

 using System; using System.Web.UI; ///  /// My controller ///  public partial class controllerName: UserControl { protected void Page_Load(object sender, EventArgs e) { } } 

A esto:

 using System; using System.Web.UI; namespace Controles { ///  /// My controller ///  public class controllerName : UserControl { protected void Page_Load(object sender, EventArgs e) { } } } 

Y eso funcionó para mí.

Para mí, esto sucedió cuando mi ubicación precomstackda / publicación se estableció en el directorio actual, que era donde también estaba la carpeta raíz del sitio.

Mi sitio web estaba viendo la carpeta de publicación como parte del proyecto al comstackr / construir y luego encontrar duplicados de esa manera.

es decir, no coloque la versión publicada / precomstackda de su sitio en las carpetas de códigos de su sitio.

Tuve el mismo problema cuando estaba comstackndo la aplicación en un servidor de comstackción.

Estoy de acuerdo con la manera de los atributos batch = “true” pero el error indica que existen 2 ensamblados y objetos en el contexto del proyecto. La solución debería ser eliminar uno de ellos que está obsoleto. En el caso anterior, el proyecto es asp.net y creo que el framework 2.0 allí debe estar en App_Code.

Si las DLL se muestran en una carpeta temporal, debe intentar limpiar su solución.

Publicando mi solución:

El problema estaba relacionado con el “Análisis en tiempo real” de Mcafee Antivirus. Deshabilitar esto resolvió el problema. De alguna manera, ASP no usaba la carpeta temporal ASP cuando el antivirus estaba activado.

Espero que esto ayude a alguien.

La carpeta App_Code está causando el problema, coloca la clase fuera de la carpeta (Funciona bien)

La carpeta App_Code no está diseñada para proyectos de aplicaciones web

http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html

Vaya a Agregar referencia y busque tanto el archivo dll, como el dll habrían marcado, desmarque uno de los dll, ya que hay referencias al mismo archivo dll con la ambigüedad de la versión diferente que se genera.

Mi solución fue reemplazar CodePage = “….” con CodeBehind = “…” en el archivo .aspx. De alguna manera, se dejó como CodePage durante una migración desde versiones anteriores de .NET. Esta directiva de página crea otro archivo dll que entra en conflicto con el archivo dll de los proyectos.

Ninguna de estas soluciones funcionó para mí. La comstackción en el modo “Release” funcionó, pero cuando cambié a “Debug” recibí un montón de este mensaje de error.

No entiendo por qué, pero un simple reinicio de Visual Studio fue mi solución.