Application_Start non si attiva?

Ho un'applicazione ASP.NET MVC (beta) su cui sto lavorando e non riesco a capire se sto facendo qualcosa di sbagliato o se il mio Application_Startmetodo in Global.asax.cs in realtà non si attiva quando provo per eseguire il debug dell'applicazione.

Ho inserito un punto di interruzione su una riga nel mio Application_Startmetodo e mi aspetto che quando provo a eseguire il debug dell'applicazione, il punto di interruzione venga colpito ... ma non lo fa mai. Non dopo aver ripristinato IIS, non dopo il riavvio, non mai. Mi sto perdendo qualcosa? Perché questo metodo non viene mai chiamato?

Se questo è in IIS, l'app può essere avviata prima che il debugger sia collegato. In tal caso, non sono sicuro di poter eseguire il thread sleep abbastanza a lungo da rimanere attaccati.

In Visual Studio, è possibile collegare il debugger a un processo. Puoi farlo facendo clic su Debug >> Allega al processo. Collegati al browser e quindi premi l'applicazione. Per sicurezza, riavvia IIS e vai sul sito. Non sono convinto al 100% che questo risolverà il problema, ma farà molto meglio che attivare una sospensione del thread in App_Start.

Un'altra opzione è temporaneamente ospitata nel server Web incorporato fino al termine dell'avvio dell'applicazione di debug.

Nota: una bella alternativa facile all'utilizzo del "Visual Studio Development Server" integrato o IIS Express (ad es. Perché si sta sviluppando contro IIS e si hanno impostazioni particolari necessarie per il corretto funzionamento della propria app) è semplicemente rimanere in esecuzione in IIS (I utilizzare il server Web personalizzato + voce file host + associazione IIS allo stesso dominio)

1. attendere che la sessione di debug si attivi ok
2. quindi esegui una modifica degli spazi bianchi nel web.config di root e salva il file
3. aggiorna la tua pagina (Ctrl + F5)

Il tuo punto di interruzione dovrebbe essere colpito bene e puoi continuare a eseguire il debug nel tuo habitat IIS naturale . Grande !

Quanto segue aiuta in ogni caso (non importa se si utilizza IIS, Cassini o altro):

1. Imposta il punto di interruzione in Application_Start
2. Inizia il debug (molto probabilmente il punto di interruzione non viene colpito) -> una pagina viene mostrata nel browser
3. Cambia web.config (es. Inserisci una riga vuota) e salvalo
4. Ricarica la pagina nel browser -> breakpoint is hit!

Perché funziona? Quando web.config viene modificato, il server Web (IIS, Cassini, ecc.) Esegue un riciclo, ma in questo caso (per qualsiasi motivo), il processo mantiene lo stesso, quindi ti colleghi ad esso con il debugger (Visual Studio ).

Ho troppi problemi con i punti di interruzione in application_start con IIS un'app ospitata. Una buona soluzione alternativa sta usando Debugger.Break (); nel codice anziché nel punto di interruzione VS.

Ho lo stesso problema. Ho apportato molte modifiche al nome nella mia soluzione. Dopo di ciò ho ottenuto due applicazioni Web non funzionanti e diverse altre applicazioni Web erano a posto. Ho riscontrato un errore nel fatto che ho percorsi sbagliati. Quando ho provato a impostare il punto di interruzione nel Application_Startmetodo e quindi a riavviare IIS, VS non ha interrotto l'esecuzione. Con le applicazioni web funzionanti, la rottura funzionava. Poi ho ricordato che "soluzione pulita" e "ricostruisci" non eliminano gli assembly che sono rimasti dopo la ridenominazione. E quella era la soluzione! Ho pulito manualmente le bindirectory delle mie applicazioni buggy-web e poi ho visto un nuovo errore Global.asax Inherits=""nell'attributo a cui faceva riferimento la vecchia dll. L'ho cambiato su nuovo e la pausa ha iniziato a funzionare. Supponiamo che, durante la ridenominazione di Global.asax non sia stato aggiornato,

Aveva lo stesso problema in un Progetto che avevamo rilevato dopo che un altro fornitore lo aveva realizzato. Il problema era che mentre c'erano un numero di comandi scritti dal precedente fornitore in Global.asax.cs, il che poteva farti credere che fosse in uso, in realtà veniva completamente ignorato. Global.asax non ereditava da esso ed è facile non vedere mai questo file se è presente il file .cs: devi fare clic con il tasto destro del mouse su Global.asax e fare clic su Visualizza markup per vederlo effettivamente.

global.asax:

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

Necessario essere modificato in:

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

Dove ProjectNamespace è qualunque sia lo spazio dei nomi della tua classe Global.asax.cs (di solito il nome del tuo Progetto).

Nel nostro caso il file conteneva un mucchio di codice inline, alcuni dei quali erano stati incollati dal file .cs, altri no. Abbiamo appena scaricato il codice inline nel file .cs e unificato gradualmente le nostre modifiche.

Prova a cambiare la modalità della pipeline gestita per il pool di app in "Classico" anziché "Integrato". Ciò ha risolto il problema per me. Esaminando il motivo ora ...

(I suggerimenti per questa risposta appartengono a Flores (vedi il suo commento sulla sua stessa risposta), volevo solo fornire questo come una risposta separata per attirare più attenzione su di esso)

Assicurati che global.asax non sia in una sottodirectory. Deve essere posizionato a livello di radice nel progetto.

Abbiamo avuto un problema simile, in cui global.asax.cs veniva ignorato.

Si scopre che il sito è stato aggiornato da un sito Web .NET 2 precompilato a un sito .NET 4.0. Sul server, il PrecompiledApp.configfile non era stato eliminato dalla cartella principale. Dopo averlo eliminato e riciclato il pool di app IIS e toccato web.config per riavviare l'applicazione, il codice in Global.asax.cs ha iniziato a funzionare correttamente.

Una volta ho avuto un problema in cui Global.asax e Global.asax.cs non erano effettivamente copiati nella cartella IIS dagli script di distribuzione ... Quindi ha funzionato durante il debug sul server di sviluppo, ma non in IIS.

Un'entrata in ritardo ...

Per verificare se l'applicazione IIS viene avviata prima che il debugger abbia avuto abbastanza tempo per collegarsi, basta aggiungerlo all'inizio o alla fine di GLOBAL.ASAX Application_Start.

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

Quando dici "debug", intendi effettivamente avviare l'applicazione dal server web incorporato di Visual Studio per il debug o intendi collegarti al processo in IIS? Se è il primo, dovresti premere Application_Start, ma se è il secondo, può essere difficile essere in procinto di prenderlo abbastanza presto.

Chiudi Visual Studio ed elimina le cartelle bine objnel tuo progetto web (o tutti i progetti nella soluzione).

Ecco i comandi per eliminare queste cartelle da tutti i tuoi progetti:

rm *\bin -r
rm *\obj -r

Avevo apportato alcune modifiche in base a "Analisi del codice sulla build" di Visual Studio. Analisi del codice ha suggerito "CA1822 Contrassegna membri come statici" per Application_Start () in Global.asax. L'ho fatto e ho finito con questo problema.

Suggerisco di sopprimere questo messaggio di analisi del codice e di non alterare la firma di metodi / classi creati automaticamente dalla piattaforma utilizzata per l'avvio automatico dell'applicazione. La firma del metodo Application_Start probabilmente non era statica per un motivo.

Sono tornato a questo metodo-firma e Application_Start () è stato sparato di nuovo:

    protected void Application_Start()
    { ... }

Ho riscontrato questo problema durante l'utilizzo di una pagina statica (ad esempio index.html) come pagina di avvio - Application-Start non viene chiamato. Ho scoperto che servire una pagina statica in realtà non avvia l'applicazione. Richiesta di una pagina aspx fa.

Assicurarsi che gli spazi dei nomi in Global.asax e Global.asax.cs siano uguali. Se sono diversi, non genererà alcun errore ma non colpirà il punto di interruzione anche perché non esegue affatto application_start.

Penso che l'evento di avvio dell'applicazione venga generato solo quando viene effettuata la prima richiesta, stai colpendo il tuo sito Web (ovvero effettuando una richiesta)?

Ho riscontrato questo problema in un progetto .net 4 moduli web vs2010 e ho provato tutto quanto menzionato in questa pagina. Ho finito per rimuovere e aggiungere global.asax in realtà risolto il problema per me.

Ho lo stesso problema, non riesco a catturare Application_Start. E il motivo era che non si stava eseguendo il fuoco a una mancata corrispondenza nel file di markup. Il file di markup Global.asax stava ereditando un'altra classe ...

Hai controllato le impostazioni del progetto? Ho riscontrato questo problema e l'URL di avvio è andato su una porta diversa rispetto alla porta specifica del mio server. Mi ci è voluto troppo tempo per capire ...

Dopo aver provato tutte le altre risposte applicabili nella mia situazione e non ho avuto fortuna con nessuna di esse, sono entrato nelle proprietà del progetto Web (il progetto lato server per un'app Silverlight che utilizza RIA Services), ho fatto clic su "Web" e modificato il server selezionato da "Local IIS" a "IIS Express". (Nota che sto usando VS2013.) Questo ha risolto il problema. Application_Start viene eseguito in "IIS Express" ma non in "Local IIS". Interessante...

Stavo cercando di scorrere il codice in RegisterRoutes () chiamato dall'avvio dell'applicazione e non colpire il mio punto di interruzione. Ho determinato che Application_Start non veniva chiamato. Ho dovuto apportare una modifica per apportare una modifica superficiale ad App_start / RouteConfig.cs e salvarlo prima che Application_Start venisse chiamato. Immagino che questi file vengano memorizzati nella cache da qualche parte e non vengano chiamati a meno che non venga apportata una modifica.

Il mio stesso problema è stato risolto aggiungendo il riferimento System.Web.Routingdell'assembly nel progetto

Se si utilizza System.Diagnostics.Debugger.Break (); soluzione alternativa (che a mio avviso va bene per un utilizzo temporaneo) ed è "semplicemente non funzionante" sul tuo computer con Windows 8. Il motivo è un bug nel "Debug just in time" di Visual Studio.

La correzione è la seguente è quella di correggere la chiave per "Debugger just-in-time di Visual Studio"

Apri regedit e vai a HKEY_CLASSES_ROOT \ AppID {E62A7A31-6025-408E-87F6-81AEB0DC9347} per il valore di registro 'AppIDFlags', imposta il flag su 0x8

Maggiori informazioni qui: http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

Nel mio caso, l'uccisione dell'istanza del server di sviluppo ASP.NET integrata tramite la barra delle applicazioni ha risolto il problema.

Roba strana e folle ... ma il debug su una macchina server e un altro utente hanno lasciato IIS Express in esecuzione sulla loro sessione. Ho dovuto disconnettere quell'utente per terminare i suoi processi IIS Express in esecuzione. Questo sembra aver risolto il problema!

Aggiornare

Dopo aver trascorso più di 1 ora a cercare ciò che stava causando il problema ... ecco l'affare: in qualche modo sono riuscito a digitare un sall'interno della <appSettings>sezione in Web.config. Visual Studio ha cercato di avvisarmi nella Error Listfinestra con un avviso . Confesso che raramente controllo gli avvisi ... dovrei iniziare a controllarlo da ora in poi. : D Non appena ho rimosso l'infrazione, sil punto di interruzione è stato colpito Application_Start.

Ho avuto questo problema durante il tentativo di inizializzare log4net. Ho deciso di creare un costruttore statico per Global.asax

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

Il problema si verifica principalmente quando si tenta di spostare il file Global.asax in un'altra directory della soluzione. Riposizionare il file Global.asax nella posizione predefinita. Funzionerà come previsto.

Nessuna delle soluzioni sopra descritte ha funzionato per me. Tuttavia reinstallare il pacchetto

Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

usare nuget gui è un walkaround (non troppo bello)