asp.net - personalized - technical exception c#

Error de ASP.Net: "El tipo ''foo'' existe tanto en" temp1.dll "como en" temp2.dll "(pt 2)

Question

Solución:

También había movido los archivos ashx y asmx al mismo tiempo. El atributo de clase de las directivas WebService / WebHandler apuntaba al espacio de nombres incorrecto. La moraleja de la historia es asegurarse de ver el marcado de todos los archivos as*x que cambia el espacio de nombres haciendo clic derecho sobre ellos y seleccionando "Ver marcado".

Estoy experimentando el mismo problema que en esta pregunta y en este enlace , pero ninguna de las respuestas solucionó mi problema. (Editar: Configurar el atributo del lote web.config funciona, pero eso es un encubrimiento, no una solución)

El problema que estoy teniendo es con un Control de usuario que moví del directorio raíz a un subdirectorio dentro del mismo proyecto de aplicación web. Solía ​​funcionar bien antes de moverlo. Cuando lo moví, comenzó a darme el mensaje de error.

Se dice que el nombre de clase existe en dos archivos dll en Archivos temporales ASP.NET. Efectivamente, cuando abro Reflector, está en dos dlls.

Si cambio el nombre de la clase y el archivo ascx, todo funciona bien. No hay usos del nombre original en ninguno de los archivos en toda mi aplicación. Cuando cambio el nombre del archivo, abrí todos los archivos dll en Archivos temporales ASP.NET con Reflector, y no existen referencias al nombre de clase original.

Entonces, ¿de dónde viene esta referencia fantasma de cómo puedo solucionar esto?

Actualización: Literalmente agrupé todos los archivos de mi directorio de trabajo para la solución y mi directorio temporal para el antiguo nombre de clase y borré todos los archivos que lo contenían. Luego, renombré el nombre original roto, y sigo recibiendo el error.

Error del servidor en la aplicación ''/''. Descripción del error de compilación: se produjo un error durante la compilación de un recurso requerido para atender esta solicitud. Revise los siguientes detalles de error específicos y modifique su código fuente de manera adecuada.

Error del compilador: CS0433: el tipo ''ASP.dashboard_badusercontrol_ascx'' existe tanto en ''c: / Docunts y Settings / me / Local Settings / Temp / Temporal ASP.NET Files / root / 3c2b7e1f / 2e8a7620 / App_Web_badusercontrol.ascx.a57ad085.iljdmp1p .dll ''y'' c: / Docunts and Settings / me / Configuración local / Temp / Archivos temporales ASP.NET / root / 3c2b7e1f / 2e8a7620 / App_Web_bhdqaimy.dll ''

Error de fuente:

Línea 1098: Línea 1099:
[System.Diagnostics.DebuggerNonUserCodeAttribute ()] Línea 1100: private global :: ASP.dashboard_badusercontrol_ascx @__ BuildControlMyBadUserControl () {Línea 1101:
global :: ASP.dashboard_badusercontrol_ascx @__ctrl; Línea 1102:

Archivo de origen: c: / Archivos y configuraciones / me / Configuración local / Temp / Archivos temporales ASP.NET / root / 3c2b7e1f / 2e8a7620 / App_Web_foo.aspx.a57ad085.1nw6dais.0.cs Línea: 1100

Editar: Ok, entonces hice más pruebas sobre lo que funciona y no funciona. Digamos que el nombre del archivo original era "BadUserControl.ascx" en el espacio de nombres "MyNamespace".

Moví el archivo a un directorio llamado "NewDirectory" y cambié el espacio de nombres a "MyNamespace.NewDirectory". No hay copias de "BadUserControl.ascx" en ningún otro lado en mi HDD. Comprobé dos veces mi historial TFS para asegurar que la ÚNICA diferencia sea la adición de ".NewDirectory" al espacio de nombres en los archivos de marcado y código subyacente.

Dentro de este espacio de nombres se encuentran otros dos controles de usuario llamados "OtherUserControl" y "AnotherUserControl".

Esta situación falla: tengo 2 directivas de registro:

<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %> 
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>

Estas situaciones funcionan:

1. Mantengo el nombre "BadUserControl.ascx" como está. Tengo 1 directiva de registro en una página en el mismo espacio de nombres:

   <%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>

2. Cambio "BadUserControl.ascx" a "GoodUserControl.ascx" Tengo 2 directivas de registro:

   <%@ Register src="GoodUserControl.ascx" tagname="GoodUserControl" tagprefix="uc1" %>
   <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>

3. 2 Registre directivas sin BadUserControl.ascx en absoluto:

   <%@ Register src="AnotherUserControl.ascx" tagname="AnotherUserControl" tagprefix="uc1" %>
   <%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>

Answer 1

• Cierre todas las instancias de Visual Studio en ejecución.
• Detenga IIS (si se ejecuta, de lo contrario, detenga esa cosa de "devserver")
• Borrar la carpeta de archivos temporales de ASP.NET (completamente)
• Borrar la carpeta BIN
• Inicie IIS (si se ejecuta)
• Comience VS
• Reconstruir la solución

Answer 2

Intenta eliminar todos los archivos y carpetas dentro de la carpeta "Archivos temporales ASP.Net", está en esta ruta:

c: / windows / Microsoft.NET / Framework / v2.0.50727 / Archivos temporales ASP.NET

esto funcionó para mí

Answer 3

A veces obtengo esto con mis controles de usuario web. Se quejarán de que existen dos veces cuando edito un archivo diferente. No sé qué es lo que está causando la locura, pero sé que si presiono espacio> guardar en el control de quejas obliga al servidor a recompilar y funciona bien después de eso.

Answer 4

Limpiar Temporary ASP.NET Files . Podría ser que el control antes de mover tiene un ensamblaje y luego - otro

Answer 5

¿Hay más de un proyecto en su solución?

Intente limpiar la carpeta / bin (manualmente). Es posible que el archivo de compilación anterior aún persista en algún lugar, lo que le impide crear ...

Además, eche un vistazo a sus referencias. ¿Quizás esté duplicando la definición de algo a lo que hizo referencia?

Este es un tiro desenfrenado, pero tal vez tengas instalado .dll en GAC.

Answer 6

Con muchos proyectos y carpetas, a veces es posible que se confundan los espacios de nombres, especialmente si intenta forzar cosas mediante el uso de declaraciones de espacios de nombres.

Para ver si esto realmente es un problema, reviso todos mis archivos de código - .cs y .designer.cs - y elimino TODAS las declaraciones del espacio de nombre, luego reconstruyo todo para ver si eso soluciona el problema.

No mencionas qué versión de Visual Studio y .net estás usando, eso también podría ser útil. Recuerdo que traté con un problema similar en VS2005.

Answer 7

Creo que algunas de estas respuestas pueden haber sido fuera de lugar. Lo he visto cuando su código subyacente hace referencia a una versión diferente del ensamblaje que su web.config. p.ej:

(versión 1.1.0.0 a la que se hace referencia en aspx y 1.2.0.0 a la que se hace referencia en web.config)

MyFile.aspx

<%@ Register TagPrefix="cc1" Namespace="StrongNamed.Namespace" Assembly="StrongNamed, Version=1.1.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" %>

web.config:

<assemblies>
    <add assembly="StrongNamed, Version=1.2.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
...

He visto casos en los que si ambas versiones del ensamblaje están en el GAC, ASP.NET le dará el error que usted describe.

Answer 8

Este tipo de error se debe al espacio de nombre. Compruebe el espacio de nombre para todos los archivos para asegurarse de que no haya un error de error de uso del espacio de nombre duplicado o uno.

Answer 9

ACTUALIZACIÓN: de acuerdo, como descubriste, la referencia circular fue una suposición errónea, ya que hay otras situaciones que pueden causar un comportamiento similar.

La forma más general de describir el problema es que el procesamiento por lotes en el tiempo de ejecución funciona de una manera muy permisiva que puede enmascarar problemas. Básicamente, tratamos de agrupar todo en una carpeta, pero si obtenemos un error de compilación al compilar ese lote, recurrimos a la compilación de archivos individuales. En muchos casos eso funciona bien, pero a veces, esto puede llevar a que una página determinada se compile dos veces (similar a lo que describí a continuación, pero por una razón diferente).

Por otro lado, aspnet_compiler funciona de manera estricta , donde si el proceso por lotes falla, falla por completo y no retrocede. Es por eso que ejecutar esta herramienta es una gran manera de localizar varios tipos de problemas (o problemas latentes) que pueden ser muy obvios en el tiempo de ejecución. Supongo que no hicimos un buen trabajo al evangelizar esta herramienta para este propósito :)

En cuanto a por qué el cambio de nombre del archivo lo arregló, esto puede deberse a que cambia el orden en que se procesan los archivos, lo cual es un poco arbitrario. Puede ser que si le cambia el nombre a otra cosa, verá que vuelva a suceder.

Francamente, mirando hacia atrás, ojalá hubiéramos hecho estricto este comportamiento de procesamiento por lotes en tiempo de ejecución, para detectar esas situaciones antes. La razón por la que elegimos el diseño actual de respaldo fue para evitar fallas siempre que fuera posible, pero esto tenía un precio: cuando algo anda mal, es difícil atraparlo :)

RESPUESTA ORIGINAL: En resumen, el problema es que cuando el procesamiento por lotes está activado (y es por defecto), debe evitar tener dependencias circulares a nivel de directorio. Déjame explicarte lo que quiero decir con eso.

Aquí hay un ejemplo. Digamos que tienes:

• En la carpeta 1: page.aspx y uc2.ascx
• En forder2: uc1.ascx

Y diga que page.aspx hace referencia a uc1.ascx (a través de una directiva @register), y que uc1.ascx hace referencia a uc2.ascx. En el nivel de archivo, eso está perfectamente bien, pero a nivel de directorio, hay una dependencia circular: la carpeta 1 hace referencia a algo en la carpeta2, que hace referencia a algo en la carpeta1.

Por qué esto es problemático tiene que ver con cómo funciona el procesamiento por lotes: cuando solicita la página, primero intenta compilar todo en la carpeta 1. Pero como folder1 / page.aspx hace referencia a la carpeta 2 / uc1.ascx, necesita compilar la carpeta 2 antes de que pueda hacer la carpeta 1. ¡Pero entonces uc1 usa uc2, lo que significa que primero debe hacer la carpeta1! En este punto, ASP.NET detecta la situación e intenta aprovecharla compilando uc2.asc por sí mismo. Si bien esto permite que algunos escenarios funcionen, también puede causar cosas raras porque algunos elementos terminan compilados en dos ensamblajes. Aquí, uc2.ascx sería compilado tanto por sí mismo como con el lote de la carpeta1.

De hecho, hay una manera de detectar fácilmente si su sitio tiene tales dependencias circulares de nivel de carpeta. Desde la ventana de una consola VS, vaya a la raíz de su sitio y ejecute:

aspnet_compiler -v foo -p .

Si tiene dependencias circulares de nivel de carpeta, obtendrá algunos errores que se verán así:

/foo/Sub/UC1.ascx(2): error ASPPARSE: Circular file references are not allowed.

La forma económica de evitar este problema es lo que ya sabe: deshabilite el procesamiento por lotes. Ahora al menos sabes por qué funciona :)

Pero lo mejor que puede hacer si puede evitar las dependencias circulares de nivel de carpeta. Si comienzas a pensar en cada carpeta como un "componente" que produce un ensamblaje, eso tiene sentido y puede ayudar a que las piezas de tu sitio sean más modulares.

Sí, también es justo llamar a esto un ''error'' en el sistema de compilación, o al menos una limitación. Pero una vez que te das cuenta, es bastante fácil de evitar.

Answer 10

Me encontré con este problema al menos dos veces.
La respuesta de David Ebbo es definitivamente la que explica lo que está sucediendo.

En mi proyecto, creé un control de usuario que insertaba dinámicamente en un marcador de posición.
Entonces, el código detrás del control sería algo así como:

public partial class CustomerAppointmentList : System.Web.UI.UserControl
{
}

Tenga en cuenta que este control no se encuentra en ningún espacio de nombres.

En el código detrás de ''customer.aspx.cs'', cargo este usercontrol de forma dinámica:

{
    var contentControl = (CustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");
}

Debido a que la clase ''CustomerAppointmentList'' no existe en la página aspx, tengo que hacer referencia a ella en mi custmer.aspx:

<%@ Reference Control="../controls/customerappointmentlist.ascx" %>

Cuando el compilador asp.net tiene que compilar customer.aspx se encontrará con la clase ''CustomerAppointmentList'' y agregará el tipo a la biblioteca para esa carpeta.
Segundos más tarde, el compilador asp.net agregará la clase ''CustomerAppointmentList'' a otra biblioteca para la carpeta ''controls''.

Después de agregar una interfaz ''ICustomerAppointmentList'' en una biblioteca externa (projectname.web.dll) y modificar el código, el problema desapareció. Asi que:

1. Elimine la parte ''Referencia'' en su archivo aspx.
2. Crea una interfaz para tu control de usuario.
3. Asegúrese de que la clase ''CustomerAppointmentList'' herede del control de usuario.
4. Cuando use LoadControl, envíe a la interfaz que acaba de crear.

Mi nuevo código (ascx.cs):

    public partial class CustomerAppointmentList : System.Web.UI.UserControl, ICustomerAppointmentList
{
}

(aspx.cs)

{
var contentControl = (ICustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");  
}

Answer 11

Para mí, esto sucedió cuando mi ubicación precompilada / 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 compilar / construir y luego encontrar duplicados de esa manera.

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