Perché dovresti usare WebDev integrato invece di IIS locale

3

Da quando ho iniziato a sviluppare progetti ASP.NET mi sono familiare semplicemente toccando F5 per il debug. Penso che molti di noi siano appresi in questo modo?

Da allora e molto più tardi ho imparato a convivere con la dedica del numero di porta spettrale, xx istanze multiple di WebDevXX.exe nella mia barra di notifica e il tempo di caricamento relativamente lento. In parte dalla start-up e in parte anche dalla navigazione e dai test. Chi ha evitato qualsiasi tipo di problema con percorsi di file PDB errati? (Il punto di interruzione non può essere colpito) Non io!

Non ho mai avuto una vera ragione per contestarlo. Ma la scheda delle impostazioni del progetto è sempre stata lì. Scheda "Web", "Server". Non l'ho mai toccato A volte ho inserito manualmente un numero di porta o un percorso della pagina iniziale. Server Web IIS personalizzato? Server Web personalizzato? Quell'opzione sembrava troppo spettrale al tatto.

Ora ho preso il passo per dare un calcio a questa cosa assurda "WebDev", rinfrescare la mia installazione locale di IIS e collegarla al mio ambiente Visual Studio per vedere e decidere cosa mi lascerà perdere su questo ...

Sorprendentemente, Ho appena premuto F5. La pagina web si apre sorprendentemente veloce (rispetto a webdev). I punti di interruzione sono stati colpiti immediatamente. Esplorare e testare l'app Web è quasi la stessa velocità di implementazione.

Ho pensato, "OK mi sono perso con IIS quando si trattava di eseguire il debug del contenuto lato client" Ancora una volta, sono rimasto sorpreso. Inserisco punti di interruzione in una riga di JavaScript. Ho ottenuto un'interruzione superfice del codice e in seguito Visual Studio mi ha mostrato il punto di interruzione.

La mia domanda per la discussione è, perché usiamo in modo automatico Cassini e quali sono gli svantaggi dell'IIS locale? Lo dico perché so che molti sviluppatori lo fanno, inclusi alcuni esperti.

    
posta Independent 15.04.2011 - 09:23
fonte

2 risposte

3

Lo svantaggio principale dell'utilizzo di IIS per eseguire il debug è che è necessario eseguire come amministratore o turno di UAC per abilitare il debug. Inoltre, devi installare IIS, che è facile da fare ma non predefinito su Windows 7, ad esempio, Cassini sarà lì con VS quindi nessun lavoro extra.

Sembra che IIS Express sarà effettivamente una scommessa migliore in futuro. Maggiori dettagli qui dal Gu.

    
risposta data 15.04.2011 - 10:09
fonte
0

Ho impostato la risposta di Steve come accettata perché ha un buon ragionamento sull'uso di debugger alternativi. Ho usato l'IIS fornito con i client Windows (XP / Vista / 7 qualunque) per un mese.

Il mio voto per IIS come debugger è molto alto. È possibile configurare facilmente applicazioni in IIS all'interno dello stesso VS2010 e caricare lo stato di debug molto velocemente da F5. Ci sono anche due importanti vantaggi. Uno è che i siti sono completamente navigabili senza l'ambiente VS. Il secondo è importante per me, tu sai che i file all'interno della cartella pubblica di IIS locale, sono della struttura e della dipendenza che i reali vogliono.

Utilizzando il processo w3wp e IIS, è anche più facile collegare i debugger dei processi esterni per misurare il tempo del kernel e così via. Questa non è la mia area più strong, ma comunque.

Ho trovato un bug, che sembra perdere / collegare i riferimenti ai simboli e ai file dll usati da VS Debugger. Il risultato è che non puoi interrompere il breakpoint (non può attualmente non essere colpito - avviso). Alcuni di voi potrebbero averlo provato da WebDev. In questo caso IIS devo forzare l'arresto dei processi di w3wp ed eliminare i file all'interno di " c:\windows\Microsoft.NET\Framework\vX.X.XXXXX\Temporary ASP.NET Files\ ", quindi di nuovo n di nuovo in esecuzione.

    
risposta data 11.05.2011 - 22:03
fonte

Leggi altre domande sui tag