Al ejecutar un proyecto de aplicación web, en momentos aparentemente aleatorios una página puede fallar con un error CS0433: el tipo existe en varias DLL. Las DLL son todas DLL generadas que residen en el directorio "Archivos temporales ASP.NET".
Al ejecutar un proyecto de aplicación web, en momentos aparentemente aleatorios una página puede fallar con un error CS0433: el tipo existe en varias DLL. Las DLL son todas DLL generadas que residen en el directorio "Archivos temporales ASP.NET".
Respuestas:
Agregue el atributo batch = "false" al elemento "compilación" 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 carpetas de la aplicación para compilar la aplicación. Si la propiedad por lotes del elemento en el archivo web.config de la aplicación se establece en true, ASP.NET 2.0 compila cada carpeta de la aplicación en un ensamblado independiente.
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
Una posible razón de este error es que hay 2 páginas aspx, que están teniendo el mismo nombre en su inherits=en el<@page language=......inherits=> línea.
Cambiar el inherits=nombre soluciona el error.
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 compilación funcionó perfectamente.
Resulta que me había olvidado de quitar la casilla de verificación "Permitir que el sitio precompilado sea actualizable" en Configuración de publicación -> Configurar precompilació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 la configuracióncompilation batch="false" solucionó, pero no quería ir por ese camino ya que este es un sitio web de producción grande.
Esta solución estaba en una subcarpeta de mi carpeta D: \ svn, que había asignado 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 compilation batch="true"en mi web.config, al abrir la solución desde la unidad S: mapeada, todos mis archivos .ascx se compilan en sus propios ensamblados. Si lo abro desde la ubicación física, los archivos .ascx se compilan en los ensamblados de sus respectivas carpetas (que es como batch="true"se supone que funciona).
Extraño.
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 Clase: tablero de clase partiacl
AppCode / APIServices.cs: Panel de control de clase parcial público
El error solo se podía reproducir al publicar el sitio web, pero la compilación y la depuración no informaron ningún error.
En mi caso, había cambiado el nombre de un proyecto, por lo que también se había cambiado el nombre del dll. Cuando copié el nuevo dll pero no pensé en eliminar el anterior del servidor, pronto tuve un montón de pares de clases con los mismos nombres. Eliminar los dll obsoletos estaba haciendo el truco (de la causa).
Ninguna de estas respuestas funcionó para mí, sin embargo, solucioné el problema. Como estaba usando la función Publicar de VS para implementar la aplicación web, seleccioné la opción para eliminar todos los archivos existentes antes de publicarlos en el asistente Publicar 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 dll individuales para eliminar y no le importa que los archivos de producción se eliminen primero.
En mi caso, el problema se resolvió cuando edité un archivo Designer.cs que aún tenía el nombre de clase duplicado. por alguna razón, cuando cambié el nombre de la clase "logout" a "logout2", en el archivo del diseñador no se cambió automáticamente y todavía estaba "logout", y este nombre de clase ya existía en una dll precompilada en mi proyecto (que pertenece a una aplicación web de terceros con la que trabajo y desarrollo).
Tengo este problema al poner una parte de una página aspx en el control de usuario separado. En mi máquina todo estaba bien, en el servidor apareció un error.
Se renombró 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 \ ... \ Temporary ASP.NET Files \ ...
El problema era que había revertido mi repositorio de origen a una versión anterior, antes de mover un tipo de un proyecto a otro dentro de la misma solución.
Intenté eliminar la DLL más reciente, que ni siquiera debería haber estado allí en la base de código anterior, de la ubicación de "Archivos temporales ASP.NET" identificada por msbuild. msbuild simplemente vuelva a colocarlo.
También probé la configuración web.config que algunos aquí han usado con éxito, pero tampoco funcionó. Aunque, mientras escribo esto, me doy cuenta de que en realidad había dos proyectos MVC dentro de la misma solución y ambos tenían errores, por lo que el problema puede haber sido que no agregué la configuración a ambos.
Intenté hacer avanzar mi repositorio de origen y limpiar y retroceder y limpiar. Nada.
Intenté eliminar todo lo que se encuentra en la ubicación "Archivos temporales de ASP.NET". msbuild simplemente vuelva a colocarlo.
Finalmente, intenté reconstruir en Visual Studio. Aunque la salida de la línea de comandos y la salida "Errores" dieron el mismo error de "Archivos temporales ASP.NET" de msbuild, el error Intellisense, al pasar el cursor sobre el tipo en conflicto, en realidad se quejó de los archivos DLL en los directorios de salida. Aparentemente, "Limpiar" y "Reconstruir" no estaban haciendo su trabajo. Eliminé manualmente las DLL en los directorios de salida identificados por Intellisense, y el problema se resolvió.
tl; dr: asegúrate de cubrir todos tus web.configs con la configuración por lotes e intenta aprovechar Intellisense para obtener más pistas.
Mi problema estaba vinculado a un .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 eliminar el .dll que estaba dentro de mi directorio / bin para mi proyecto.
El problema no es necesariamente una solución de web.config, es una referencia circular que debe resolverse. Me di cuenta de que borré el antiguo .dll en mi archivo de proyecto original, pero no en el proyecto al que se hacía referencia.
No recomiendo hacer la modificación a su archivo web.config porque eso es solo una corrección de curita, no aborda realmente el problema real. Haga eso si no tiene ganas de solucionar el problema, pero si desea evitar futuros dolores de cabeza, simplemente elimine el .dll de ambos lugares.
A veces puede resultar útil eliminar la solución y crearla de nuevo. Dado que este uso ocurre cuando se convierte de VS2005 a vs2010, algunas referencias al marco 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 solucionar estos problemas.
Tuve el mismo problema cuando estaba compilando la aplicación en un servidor de compilació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;
/// <summary>
/// My controller
/// </summary>
public partial class controllerName: UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
}
}A esto:
using System;
using System.Web.UI;
namespace Controles
{
/// <summary>
/// My controller
/// </summary>
public class controllerName : UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}Y eso funcionó para mí.
Para mí, esto sucedió cuando tenía mi ubicación de PrecompiledWeb / Publish configurada en el directorio actual, que era donde también estaba la carpeta raíz del sitio.
Mi sitio web veía la carpeta de publicación como parte del proyecto al compilar / construir y luego buscaba duplicados de esa manera.
es decir, no coloque la versión publicada / precompilada de su sitio en las carpetas de códigos de su sitio.
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 estaba utilizando correctamente la carpeta temporal de ASP cuando el antivirus estaba activado.
Espero que esto ayude a alguien.
La carpeta App_Code está causando el problema, coloque 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
Mi solución fue reemplazar CodePage = "...." con CodeBehind = "..." en el archivo .aspx. De alguna manera se dejó como CodePage durante una migración de versiones anteriores de .NET. Esta directiva de página crea otro archivo dll que entra en conflicto con el archivo dll de proyectos.
Me enfrenté al problema en tiempo de compilación.
Estoy de acuerdo con los atributos batch = "true" , el error indica que existen 2 ensamblajes
Solución 1: eliminar uno de ellos
Solución 2: configurar uno de ellos