Fui un poco cruel durante el fin de semana y decidí actualizar el proyecto a la plataforma 2.0. Debido a que VS2003 y 2005 pueden coexistir, el problema es relativamente fácil de solucionar. Instale la versión Pro de 2005, abra el proyecto original y actualice. El asistente aparecerá automáticamente. El proyecto contiene 7 subproyectos. Toda la lógica y la visualización se implementan en el proyecto en segundo plano. Cada archivo en el proyecto web front-end solo implementa una llamada al método en segundo plano y no se utilizan métodos avanzados en segundo plano. La actualización es muy sencilla.
En resumen, los archivos del proyecto en el proyecto web se han eliminado. Resulta que en el proceso de compilación también se tuvieron en cuenta dos archivos ASPX no relacionados. Lo compilé, lo subí al servidor e informé un error. Más tarde, descubrí que el proyecto recién compilado no tenía la DLL del proyecto web, pero todavía estaba en el directorio del servidor. El resultado es un lío de referencias internas. Elimine el DLL del antiguo proyecto web y estará bien.
Luego planeé probar el modo de publicación. Utilicé la función de publicación del sitio web en el elemento del menú Generar de VS2005 para configurar el directorio en el que publicar. La opción estaba configurada para no permitir actualizaciones. En realidad, copió todo en el directorio web. El proceso de compilación fue muy complicado. Una vez completada la compilación, se generaron un montón de cosas en el directorio bin. Pensé que copiarlas al servidor eliminaría la necesidad de una compilación limpia. Resulta que el proceso csc todavía aparece cuando se accede a la página por primera vez. Después de que se cambió todo el sitio web, todavía había muchos procesos csc, pero el proceso de compilación fue un poco más rápido que antes.
Ocurrió otro problema grave. El programa pareció reiniciarse automáticamente después de un tiempo, lo que provocó que se compilara nuevamente. Más tarde, apareció una ventana de error en el servidor que decía que había un error en el proceso w3wp.exe. ¿él? Después de seleccionar Cancelar, w3wp.exe se reinició automáticamente y comenzó una nueva ronda de recompilación. Este proceso ocurrió tres veces y estaba tan asustado que rápidamente volví a la versión 1.1. Eché un vistazo al visor de eventos y encontré un montón de excepciones no controladas, que eran básicamente errores con valores vacíos. Es extraño, no hubo ningún problema en 1.1 y el código no se modificó.
Más tarde, encontré un artículo (nadie en chino parece haberlo mencionado), http://www.eggheadcafe.com/articles/20060305.asp . El manejo de excepciones no controladas en 2.0 es muy diferente al de 1.1. diferente, 1.1 lo ignorará a menos que afecte la generación de páginas. Y 2.0 hará que el proceso informe un error, lo que afectará directamente el funcionamiento de todo el sitio web. Parece un problema grave, pero parece más razonable; de lo contrario, los programadores seguirán ignorando este error. Sin embargo, debido a este problema, la imposibilidad de cambiar de sitio web también es un problema grave. Por lo tanto, todavía se necesita un método de transición sin problemas. Como se mencionó anteriormente, este método consiste en escribir un HttpModule usted mismo para manejar todas las excepciones no controladas y registrar la información de la excepción en los eventos del sistema, lo cual es beneficioso para el procesamiento de los programadores. Y el código fuente y la descarga del archivo binario de este HttpModule también se proporcionan arriba, incluida la aplicación web de demostración.
Hoy finalmente entendí el método de compilación de la versión previa a la implementación 2.0. Es incorrecto usar VS para publicar el sitio web. Debe usar aspnet_compiler.exe para compilar manualmente, y su proceso de compilación se basa en la configuración real del sitio web. En otras palabras, debe cargar el contenido del proyecto web en el sitio web, establecer la ruta del sitio web en IIS y luego usar aspnet_compile para compilar localmente. Este proceso en realidad coloca el dll generado en C: The. Los que se encuentran en el directorio de caché de WindowsMicrosoft.Net son exactamente los mismos que los generados por csc.exe cuando el usuario accede a la página. Después de este paso, no se producirá ninguna acción de compilación cuando el usuario visite dos veces.
Tan cansado. Por cierto, pensé en un método de cambio fluido, manteniendo dos sitios web apuntando a dos directorios diferentes, uno de los cuales no tiene un encabezado de host y el otro tiene un encabezado de host para actualizar. Después de actualizar el sitio web con el encabezado del host, use aspnet_compiler para compilarlo y luego cambie los encabezados del host de los dos sitios web, de modo que los usuarios recién visitados sean dirigidos al sitio web recién compilado y el usuario no sienta ningún retraso. Simplemente actualice otro sitio la próxima vez.
http://www.cnblogs.com/unfish/archive/2006/09/10/500230.html