ejemplo - mvc c#

Application_Start no dispara? (27)

Tengo una aplicación ASP.NET MVC (beta) en la que estoy trabajando, y tengo problemas para averiguar si estoy haciendo algo mal, o si mi método Application_Start en Global.asax.cs de hecho no se activa cuando intenta depurar la aplicación.

Puse un punto de interrupción en una línea en mi método Application_Start , y espero que cuando intento depurar la aplicación, se llegue al punto de interrupción ... pero nunca lo hace. No después de reiniciar IIS, no después de reiniciar, nunca. ¿Me estoy perdiendo de algo? ¿Por qué nunca se llama este método?

¿Revisaste la configuración del Proyecto? Tuve este problema y tuve la URL de inicio yendo a un puerto diferente que mi puerto específico del servidor. Me llevó demasiado tiempo darme cuenta ...

Asegúrese de que los espacios de nombres en Global.asax y Global.asax.cs sean los mismos. Si son diferentes, no generará ningún error, pero tampoco alcanzará el punto de interrupción porque no está ejecutando application_start en absoluto.

Asegúrese de que su global.asax no esté en un subdirectorio. Tiene que ser colocado a nivel de raíz en su proyecto.

Cierre Visual Studio y elimine las carpetas bin y obj en su proyecto web (o todos los proyectos en la solución).

Aquí hay comandos para eliminar estas carpetas de todos sus proyectos:

rm */bin -r rm */obj -r

Cosas raras y locas ... pero la depuración en una máquina servidor y otro usuario dejó a IIS Express ejecutándose en su sesión. Tuve que cerrar la sesión de ese usuario para matar a su ejecución de los procesos de IIS Express. ¡Eso parece haber arreglado el problema!

Actualizar

Después de pasar más de 1 hora persiguiendo lo que estaba causando el problema ... aquí está el trato: de alguna manera logré escribir una s dentro de la sección <appSettings> en Web.config . Visual Studio intentó advertirme en la ventana Error List con una advertencia . Confieso que rara vez reviso las advertencias ... debería comenzar a verificarlo a partir de ahora. : D Tan pronto como eliminé la ofensa, se tocó el punto de interrupción en Application_Start .

Creo que el evento de inicio de la aplicación solo se activa cuando se realiza la primera solicitud, ¿está accediendo a su sitio web (es decir, haciendo una solicitud)?

Cuando dices "depurar", ¿te refieres en realidad a iniciar la aplicación desde el servidor web incorporado de Visual Studio para la depuración, o te refieres a adjuntar al proceso en IIS? Si es el primero, debes presionar Application_Start, pero si es el último, puede ser difícil estar en el proceso lo suficientemente temprano como para atraparlo.

Después de probar tantas de las otras respuestas que eran aplicables en mi situación y no tener suerte con ninguna de ellas, ingresé a las propiedades para el proyecto web (el proyecto del lado del servidor para una aplicación de Silverlight utilizando RIA Services), hice clic en Pestaña "Web" y cambió el Servidor seleccionado de "IIS local" a "IIS Express". (Tenga en cuenta que estoy usando VS2013.) Esto resolvió el problema. Application_Start se ejecuta en "IIS Express" pero no en "Local IIS". Interesante...

El problema se produce principalmente cuando intenta trasladar el archivo Global.asax a otro directorio de soluciones. Vuelva a ubicar el archivo Global.asax en la ubicación predeterminada. Funcionará como se esperaba.

En mi caso, matar la instancia del servidor de desarrollo ASP.NET incorporado a través de la bandeja del sistema resolvió el problema.

Estaba tratando de pasar por el código en RegisterRoutes () llamado desde el inicio de la aplicación y sin llegar a mi punto de interrupción. Determinaba que Application_Start no se llamaba. Tuve que hacer un cambio para hacer un cambio superficial en App_start / RouteConfig.cs y guardarlo antes de que Application_Start se llamara. Supongo que estos archivos se almacenan en caché en algún lugar y no se llaman a menos que se realice un cambio.

Intente cambiar el modo de canalización administrada para el grupo de aplicaciones a "Clásico" en lugar de "Integrado". Eso resolvió el problema para mí. Mirando la razón ahora ...

(Los apoyos para esta respuesta pertenecen a Flores (ver su comentario sobre su propia respuesta), solo quería brindar esto como una respuesta separada para llamar más la atención)

Lo siguiente ayuda en cualquier caso (no importa si está usando IIS, Cassini o lo que sea):

Establezca su punto de interrupción en Application_Start
Comience la depuración (lo más probable es que no se golpee) -> se muestra una página en el navegador
Cambie web.config (por ejemplo, ingrese una línea en blanco) y guárdelo
Recargue la página en el navegador -> ¡se golpea el punto de interrupción!

¿Por qué funciona esto? Cuando se cambia web.config, el servidor web (IIS, Cassini, etc.) realiza un reciclaje, pero en este caso (por cualquier motivo), el proceso se mantiene igual, por lo que se mantiene unido al depurador (Visual Studio )

Me enfrenté a este problema al usar una página estática (por ejemplo, index.html) como página de inicio: no se llama a Application-Start. Descubrí que servir una página estática en realidad no inicia la aplicación. Solicitar una página .aspx sí lo hace.

Nota: una buena y sencilla alternativa al uso del "Visual Studio Development Server" incorporado o IIS Express (por ejemplo, porque está desarrollando en contra de IIS y tiene la configuración particular que necesita para el correcto funcionamiento de su aplicación) es simplemente seguir ejecutando ejecutar en IIS (I utilizar la entrada del archivo Servidor web personalizado + entrada + enlace IIS al mismo dominio)

esperar a que la sesión de depuración se active
simplemente haga una edición en blanco en la raíz web.config y guarde el archivo
actualice su página (Ctrl + F5)

Su punto de interrupción debe ser golpeado muy bien, y puede continuar depurando en su hábitat natural de IIS . Excelente !

Realicé algunos cambios basados en "Code Analysis on Build" de Visual Studio. Code Analysis sugirió "CA1822 Mark members as static" para Application_Start () en Global.asax. Lo hice y terminé con este problema.

Sugiero suprimir este mensaje de análisis de código y no alterar la firma de los métodos / clases creados automáticamente por la plataforma utilizada para iniciar la aplicación. La firma del método Application_Start probablemente no era estática por algún motivo.

Volví a este método-signature y Application_Start () estaba disparando de nuevo:

protected void Application_Start() { ... }

Si está utilizando System.Diagnostics.Debugger.Break (); solución alternativa (que creo que está bien para uso temporal) y "simplemente no funciona" en su máquina con Windows 8. El motivo es un error en la "depuración Just in time" de Visual Studio.

La solución es la siguiente para reparar la clave del "Depurador Just-In-Time de Visual Studio"

Abra regedit y vaya a HKEY_CLASSES_ROOT / AppID {E62A7A31-6025-408E-87F6-81AEB0DC9347} para el valor del registro ''AppIDFlags'', establezca el indicador en 0x8

Más información aquí: http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

Si esto está en IIS, la aplicación puede comenzar antes de que se haya conectado el depurador. Si es así, no estoy seguro de si puede enhebrar el sueño el tiempo suficiente para apegarse.

En Visual Studio, puede adjuntar el depurador a un proceso. Para ello, haga clic en Depurar >> Adjuntar para procesar. Adjunte al navegador y luego presione su aplicación. Para estar seguro, reinicie IIS y acceda al sitio. No estoy 100% convencido de que esto resolverá el problema, pero será mucho mejor que desconectar un hilo inactivo en App_Start.

Otra opción es alojar temporalmente en el servidor web incorporado hasta que termine de depurar el inicio de la aplicación.

También tengo problemas con los puntos de interrupción en application_start con IIS, una aplicación alojada. Una buena solución es usar Debugger.Break (); en código en lugar del punto de ruptura VS

Tenía el mismo problema en un proyecto que habíamos asumido después de que otro proveedor lo construyó. El problema era que, si bien había una serie de comandos escritos por el proveedor anterior en Global.asax.cs, lo que podría hacer pensar que estaba en uso, en realidad se ignoraba por completo. Global.asax no estaba heredando de él, y es fácil nunca ver este archivo si el archivo .cs está presente: debe hacer clic con el botón derecho en Global.asax y hacer clic en Ver marcado para verlo realmente.

Global.asax:

<%@ Application Language="C#" %>

Necesita ser cambiado a:

<%@ Application Codebehind="Global.asax.cs" Inherits="ProjectNamespace.MvcApplication" Language="C#" %>

Donde ProjectNamespace es el espacio de nombres de su clase Global.asax.cs (generalmente el nombre de su proyecto).

En nuestro caso, el archivo contenía un montón de código en línea, algunos de los cuales estaban copiados desde el archivo .cs, otros no. Simplemente volcamos el código en línea al archivo .cs y gradualmente fusionamos nuestros cambios nuevamente.

Tengo el mismo problema. He cambiado mucho de nombre en mi solución. Después obtuve dos aplicaciones web que no funcionaban y varias otras aplicaciones web estaban bien. Recibí el error de que tengo rutas incorrectas. Cuando intenté configurar el punto de interrupción en el método Application_Start y luego reinicie IIS, VS no interrumpió la ejecución. Con las aplicaciones web funcionales, el descanso estaba funcionando. Luego, recordé que "solución limpia" y "reconstruir" no eliminan los ensamblajes que quedaron después del cambio de nombre. ¡Y esa fue la solución! He limpiado manualmente los directorios bin de mis buggy-web-applications y luego vi un nuevo error en el atributo Global.asax Inherits="" . Lo cambié en nuevo y el descanso comenzó a funcionar. Supongamos que, durante el cambio de nombre Global.asax no se actualizó, e IIS tomó el ensamblaje anterior (con rutas incorrectas) para iniciar la aplicación.

Tuve el mismo problema, no pude atrapar Application_Start. Y la razón era que no estaba disparando a una missmatch en el archivo de marcado. El archivo de marcado Global.asax heredaba otra clase ...

Tuve este problema al intentar inicializar log4net. Decidí crear un constructor estático para Global.asax

static Global(){ //Do your initialization here statically }

Tuve este problema en un proyecto de formularios web .net 4 vs2010 y probé todo lo mencionado en esta página. Terminé eliminando y agregando global.asax realmente resolvió el problema para mí.

Tuve un problema una vez que Global.asax y Global.asax.cs no se copiaban realmente en la carpeta IIS mediante las secuencias de comandos de implementación ... Así que funcionó cuando se depuraba en el servidor de desarrollo, pero no en IIS.

Tuvimos un problema similar, donde global.asax.cs estaba siendo ignorado.

Resulta que el sitio se actualizó de un sitio web .NET 2 precompilado a un sitio .NET 4.0. En el servidor, el archivo PrecompiledApp.config no se había eliminado de la carpeta raíz. Después de eliminarlo, reciclar el grupo de aplicaciones de IIS y tocar web.config para reiniciar la aplicación, el código en Global.asax.cs comenzó a funcionar correctamente.

Una entrada tardía ...

Para comprobar si la aplicación IIS se inicia antes de que el depurador haya tenido tiempo suficiente para adjuntarla, simplemente agréguela a la parte superior o inferior de Application_Start de GLOBAL.ASAX.

throw new ApplicationException("Yup, it fired");