El sitio web está ejecutando un dll almacenado en caché de alguna manera después de cambiarlo

Question

La situación es que hice una pequeña corrección de errores a una clase, por lo que quieren implementar el dll afectado. Detuvieron IIS, reemplazaron el dll en la carpeta/bin del directorio iis para el sitio web con el nuevo que les di, y comenzaron a iis nuevamente. Hay varios servidores, pero simplemente lo cambiaron en uno para probarlo. Siguen viendo el mismo error en el registro de eventos del servidor en cuestión. Mirando el rastro de la pila, puedo decir que está ejecutando el viejo dll.

Han comprobado el GAC y no lo ven allí.

He comprobado el archivo DLL con reflector para verificar que les dio la nueva DLL correcta.

Este es un sitio web asp.net 2.0 y el servidor es 2003. No estoy seguro de cómo se implementó originalmente, pero tiene una copia de la antigua DLL en C: \ Windows \ Microsoft.NET \ Framework64 \ v2 .0.50727 \ Archivos temporales ASP.NET \ NAME_services ################# \ assembly \ dl3 ################### \ y en D: \ xxxx \ Sites \ NAME \ Services \ obj \ Release. ¿Podría ser utilizar uno de estos o construir el anterior o incluso simplemente almacenarlo en la memoria caché?

Answer 1

Nuke sus contenidos temporales de la carpeta asp.net. Sin embargo, no estoy seguro de por qué la actualización no se compiló automáticamente.

Answer 2

No tiene que detener IIS para implementar su actualización, simplemente cópielos.

Además, si se copian sólo el DLL, pero su arreglo era en el archivo .aspx, entonces no va a aparecer. Realmente deberías hacer una implementación completa.

Answer 3

Hemos tenido el mismo problema pero con complicaciones menores, tenemos muchos muchos sitios por lo que una "limpieza de toda temp" y reinicie IIS no es una buena opción para nosotros. Así que necesitábamos ser más selectivos en lo que forzar una actualización.

En nuestra máquina de QA, en ... "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales de ASP.NET" Hice una búsqueda de explorador de archivos para el nombre de archivo parcial de lo que están tratando de liberar. El archivo se encontró en una carpeta algo así como: C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos ASP.NET temporales \ root \ 4503212x \ ad95664x, así que detuve el grupo de aplicaciones, eliminé la carpeta, reinicié y todo fue desplegado entonces - ¡genial!

Pero .... Tuvimos el mismo problema al implementar en producción y lo anterior no funcionó.

En pocas palabras, el grupo de aplicaciones QA estaba configurado para "habilitar 32 bit true", pero la producción se estableció en "False" para que los archivos prod temp residieran en: "C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 "en su lugar (\ Framework64 \ en lugar de \ Framework \).

Si la limpieza de archivos temporales no está funcionando - doble revisar sus marcos, o buscar en los archivos se actualizan en el directorio C: \ Windows \ Microsoft.NET nivel de carpeta y por debajo. usted puede estar sorprendido