"No se pudo cargar el archivo o ensamblado 'XXX.YYY' o una de sus dependencias. El sistema no puede encontrar el archivo especificado."

Question

Tengo una solución .net visual studio con una cantidad de proyectos (bibliotecas de clase y una aplicación web).

Realicé refracción que movía archivos entre proyectos, creaba nuevos proyectos, eliminaba los que no se usaban y renombraba algunos proyectos existentes.

La solución construye sin un problema, pero cuando corro la aplicación web, se produce la siguiente excepción:.

"No se pudo cargar el archivo o ensamblado 'XXX.YYY' o uno de sus dependencias El sistema no puede encontrar el archivo especificado. "

El proyecto llamado XXX.YYY que se eliminó en el refractoring superó un dll llamado XXX.YYY. Pero esto no se usa en ninguna parte de la aplicación. Eliminé el directorio obj de las aplicaciones web y la carpeta bin y reconstruí pero aún así ocurre.

¿Alguien tiene alguna idea de cuándo podría estar ocurriendo esto, algún consejo?

ACTUALIZACIÓN:

Actualización sobre mi problema. Cogí el código de lugar en otra computadora y lo ejecuté desde allí, y se compiló y ejecutó correctamente sin que se produzca este problema. Así que esto me hace pensar que el problema es con mi PC en lugar de con la base del código. Tal vez hay algo almacenado en caché en mi PC. Eliminé mis archivos temporales en "C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET" pero no tuve suerte.

Cualquier otra cosa que pueda almacenarse en la memoria caché u otra razón para que ocurra en mi PC.

nueva actualización

Otra actualización en esto. He ejecutado el mismo código en la máquina de otros desarrolladores y él no tiene un problema al ejecutarlo. ¡Así que definitivamente debe ser algo en mi máquina! Lo único diferente en nuestra máquina es que estoy ejecutando IIS7 con el grupo de aplicaciones de la aplicación en modo clásico. El otro desarrollador ejecuta IIS6.

2 nuevas piezas en la información. En primer lugar en mi httpmodules en mi web.config, tengo que eliminar un módulo http personalizado, antes de agregarlo. El otro desarrollador no tiene que hacer esto. En segundo lugar, he podido solucionar el problema "No se pudo cargar el archivo o ensamblar 'XXX.YYY' o uno de sus dependencias" a través de un "hackeo" que es solo una solución a corto plazo al crear una biblioteca de clases en mi proyecto llamado XXX .YYY e incluyendo las clases que se buscan, que son todos controles personalizados, es decir. heredando de System.Web.UI.WebControls.WebControl.

Cualquier otra pensamientos ....

Answer 1

¡Buenas noticias que he resuelto el problema! Tuve que volver a instalar mi entorno de tiempo de ejecución de .net. También eliminé sitios de IIS y volví a listar el sitio web. Cuando lo ejecuté, el problema no ocurrió y el sitio se ejecutó.

Muchísimas gracias a todos por su ayuda y asistencia, muy apreciadas. ¡Todos los consejos y la ayuda me orientaron en la dirección para resolver esto!

Answer 2

acaba de comprobar los proyectos de la estructura de configuración .. si hay un archivo DLL compilado de 64 bits en sus referencias y su principal proyecto es de 32 bits (o cualquier CPU y su máquina es de 32 bit) o ​​viceversa, obtendrá este error

Answer 3

Use Dependency Walker (depende) en todos sus EXEs y DLL para ver cuál tiene la dependencia que falta. Debe ejecutar depende del directorio de trabajo de su proyecto para obtener mejores resultados.

Una vez que sepas qué EXE/DLL es el culpable, ve a la configuración de ese proyecto y mira si allí se menciona la dependencia de la que se queja.

EDITAR: Otra cosa se me ocurrió hace unos minutos ... Si alguna de sus dependencias está "bloqueada" porque fueron marcadas como descargadas por algunos metaware de MS (cuando usa DL con el explorador de Inet, por ejemplo) que pueden evitar que se cargue código ejecutable. Mire las propiedades de sus ejecutables (DLL/EXE) con Windows Explorer y vea si tienen un botón de desbloqueo en la primera página. Si es así, haz clic en ese botón. Esto me tomó un tiempo para averiguarlo hace un tiempo, espero que ayude.

Answer 4

Haga la búsqueda de solución para el texto "XXX.YYY" y elimine todas las ocurrencias. Tal vez lo has omitido en algún archivo web.config.

Además, puede verificar los archivos * .csproj si la búsqueda de la solución no encuentra nada. Básicamente son archivos de texto, por lo que no debería haber problemas para eliminar referencias.

Answer 5

Simplemente le falta una dependencia. Es probable que una situación como el Proyecto A tenga una referencia al Proyecto B que tenga una referencia al Proyecto C. Su directorio de salida no cuenta con la DLL para el Proyecto C.

Answer 6

Existen dos posibles motivos.

1) Cuando ejecuta su aplicación web, todavía utiliza los ensamblajes antiguos en algún lugar de sus máquinas. Sus ensamblajes anteriores se referían al ensamblaje anterior "XXX.YYY".

2) El último archivo binario que ha construido todavía hace referencia al ensamblaje anterior "XXX.YYY".

Para saber qué ensamblajes utiliza su aplicación web, si está ejecutando un depurador, puede encontrarlo fácilmente desde la ventana de resultados. Deberían ser las primeras pocas líneas de la salida. Otra forma de averiguarlo es abrir las ventanas del Módulo en VS.NET IDE durante la depuración.

Si no puede depurarlo por alguna razón o tiene problemas para conectar un depurador, otra manera más fácil de hacerlo es usar fuslogvw. Le proporciona las ubicaciones exactas de todos los assemblis cargados con éxito, así como los ensamblajes que no pudo cargar. Asegúrese de ejecutar el fuslogvw como administrador en Windows 7.

Después de averiguar qué ensamblajes cargó con éxito su webapp, puede hacer ildasm en esos ensamblajes para ver qué ensamblajes están haciendo referencia. Necesitas revisarlos uno por uno, desafortunadamente.

Supongo que algunos de los ensamblados cargados con éxito provienen de algún lugar de la memoria caché ASP.NET o GAC.

Answer 7

Habilite el registro de diagnóstico para el resultado de compilación (Herramientas -> Opciones -> Compilación y ejecución -> Verbosidad del registro de salida -> Diagnóstico) y Cree la solución y vea desde donde Visual Studio selecciona el dll (somedll.dll versión xxx. yy). Ahora ejecute la aplicación y vea dónde está tratando de resolver el dll en tiempo de ejecución. (Windbg es una opción).

Answer 8

Ve a References en Solution Explorer en Visual Studio. Seleccione el conjunto que se está quejando. Selecciónelo y vaya a la opción de menú View y seleccione Property Window en la parte inferior. Mientras se selecciona el ensamblaje, vea sus propiedades en la ventana de propiedades y busque el valor Copy Local. Si su valor está establecido en False, configúrelo en True.Crea la solución y publícala. Debería resolver con éxito el problema.