Impossibile avviare il debug sul server web. Impossibile avviare il debug di ASP.NET VS 2010, II7, Win 7 x64

Utilizzo Visual Studio 2010 (come amministratore), IIS 7 su Windows 7 x64. Sono in grado di eseguire il sito Web ASP.NET in IIS 7 senza eseguire il debug correttamente, ma quando premo F5 per eseguire il debug, ottengo:

Impossibile avviare il debug sul server web. Impossibile avviare il debug di ASP.NET. Ulteriori informazioni potrebbero essere disponibili avviando il progetto senza eseguire il debug.

Sfortunatamente il link della guida non mi aiuta molto e conduce a un grande albero di cose.

Ho controllato quanto segue:

• Requisiti di sicurezza: non ricordo di dover fare nulla di speciale prima. Il processo di lavoro in IIS7 è w3wp.exe. Dice che se è in esecuzione come ASPNET o SERVIZIO DI RETE, devo disporre dei privilegi di amministratore per eseguire il debug. Come faccio a sapere se devo cambiare qualcosa qui?

• Pagine delle proprietà del sito Web> Opzioni di avvio> Debugger> ASP.NET è selezionato. Usa server personalizzato è impostato sull'URL del sito (che funziona bene senza debug).

• Il debug è abilitato in web.config.

• L'applicazione utilizza ASP.NET 3.5 (alla fine voglio passare alla 4.0 ma devo affrontare la migrazione).

• Pool di applicazioni: Classing .NET AppPool (provato anche DefaultAppPool).

Qualche idea su cui posso controllare dopo?

Sicuramente non dovrebbe essere così difficile installare IIS, VS, creare un sito web e iniziare a testarlo?

Grazie in anticipo.

Prova ad andare su IIS e verifica che il pool di app che stai utilizzando sia avviato. Molte volte, genererai un errore che arresta il pool di app. Devi solo fare clic con il pulsante destro del mouse e avviare e dovresti essere a posto.

Si scopre che il colpevole era il modulo IIS Url Rewrite . Avevo definito una regola che reindirizzava le chiamate a Default.aspx (che era impostato come pagina iniziale del sito web ) alla radice del sito in modo da poter avere un URL home canonico. Tuttavia, apparentemente VS ha avuto un problema con questo e si è confuso. Questo problema non si è verificato quando stavo usando Helicon ISAPI_Rewrite, quindi non mi è nemmeno venuto in mente di controllare.

Ho finito per creare un sito web completamente nuovo da zero e portare progetti / file poco a poco nella mia soluzione e ricostruire il mio web.config finché non l'ho scoperto! Bene, almeno ora ho un sito leggermente più pulito che utilizza .NET 4.0 (finora, spero di non incappare in nessun muro) - ma che dolore!

Visual Studio, all'avvio, tenterà (per qualche motivo) di accedere all'URL:

/debugattach.aspx

Se hai una regola di riscrittura che reindirizza (o altrimenti cattura), ad esempio, .aspxfile, da qualche altra parte, otterrai questo errore. La soluzione è quella di aggiungere questa sezione per l'inizio della vostra web.configs' <system.webServer>/<rewrite>/<rules>sezione:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

Ciò assicurerà di catturare questa particolare richiesta, non fare nulla e, cosa più importante, interrompere l'esecuzione in modo che nessuna delle altre regole venga eseguita. Questa è una soluzione robusta, quindi sentiti libero di tenerla nel tuo file di configurazione per la produzione.

A beneficio degli altri, nel mio caso avevo configurato il pool di applicazioni per utilizzare le mie credenziali di Windows per accedere a una condivisione di risorse di rete. Dall'ultimo debug della soluzione ho reimpostato la password di Windows. Password modificata memorizzata nel pool di app e bada bing.

Se ApplicationPool Identity è impostato su un account personalizzato e la password del computer viene modificata, è necessario aggiornare la password

Per il mio scenario sono state apportate modifiche alla sezione httpErrors in web.config, impostandola in questo modo:

<httpErrors mode="Custom"> 

ha causato il problema "Impossibile avviare il debug sul server Web". L'impostazione di nuovo al valore precedente di "DetailedLocalOnly" ha risolto il problema. Scavando un po 'più a fondo ho scoperto che in realtà era solo l'impostazione dell'errore 401 a causare questo:

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

Commentando anche la riga di errore 401 ha risolto il problema, ci sono andato poiché posso quindi mantenere la gestione degli errori personalizzata e iniziare con il debug.

Non ho ancora idea del perché stia succedendo.

Plase controlla il pool di applicazioni. se è fermato. riavviarlo.

Si è verificato lo stesso problema durante il debug di un modulo DNN (Dot Net Nuke). Si è scoperto che devi avere compilation debug = "true":

<compilation debug="true" strict="false" targetFramework="4.0"> 

nel tuo web.config. Per impostazione predefinita, è falso in DNN. Fonte originale qui: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Ho esattamente lo stesso problema dopo aver implementato il modulo di riscrittura.

Se rimuovo le voci di riscrittura dal mio file web.config, il debug funziona perfettamente.

Per aggirare questo problema, devo solo commentare i tag di riscrittura durante il debug, in questo modo ...

<rewrite>
    <rules>
        <rule name="LowerCaseRule_1" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" />
        </rule>
        <rule name="RedirectDefault.aspx_1" stopProcessing="true">
            <match url="(.*)default.aspx" />
            <action type="Redirect" url="{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Quindi rimuovo i commenti dopo il debug.

Deve essere un bug in Visual Studio 2010.

Ho ricevuto lo stesso errore da quando il pool di applicazioni è stato interrotto in IIS. Dopo aver avviato il pool di app, il problema è stato risolto.

Ecco cosa ho fatto per cancellare l'errore che hai notato. Individua la cartella web per l'app all'interno del file system, vai su Proprietà => Sicurezza fai clic sul pulsante Avanzate quindi fai clic sulla scheda Proprietario , fai clic sul pulsante Modifica e cambia il proprietario (con le autorizzazioni corrette) della cartella e seleziona l'opzione " Ripristina proprietario su sottocontenitori e oggetti "casella di controllo. Fare clic su " Applica " e poi ero in affari (in grado di eseguire il debug).

Spero che questo funzioni per qualcun altro.

Finalmente ho risolto questo problema per la mia unica soluzione che aveva questo. Due dei progetti nella soluzione sono stati impostati come siti in IIS. Sono entrato e ho abilitato la rappresentazione di ASP.Net in autenticazione per entrambi i progetti ... e VIOLA! FINALMENTE, niente più di questo fastidioso errore!

Ricevo lo stesso messaggio di errore in VS 2012, ma non ero in esecuzione come amministratore. Quando ho eseguito l'app come amministratore, ho ricevuto un messaggio diverso e leggermente più utile (che sono riuscito a capire). HTH

Se il pool di app ha problemi a riavviarsi o semplicemente non vuole riavviarsi, verificare se Windows ha effettuato un aggiornamento recente su ASP.NET v4.0 o altro pool di app. Questo è ciò che è successo nel mio caso. Ho semplicemente riavviato il mio computer, quindi riavviato il pool di app ASP.NET v4.0 e tutto ha funzionato di nuovo!

Dan,

Oltre ai suggerimenti di Aaron, prova quanto segue

• Verificare che l'autenticazione Windows integrata sia selezionata nel sito Web IIS
• Puoi eseguire il debug utilizzando Cassini invece di IIS?

Ha avuto lo stesso problema con Windows 10 quando sono state attivate tutte le funzionalità di Windows IIS. Sono passato a Windows 8.1 e ho riscontrato di nuovo il problema. La radice era nel nome del sito web " http: //MySite.local " (non correlato alla versione del sistema operativo).

E la soluzione è semplice

• Modifica il file hosts in formato %SystemRoot%\System32\drivers\etc\

• Aggiungi riga con associazione ip: 127.0.0.1 MySite.local

Ho riscontrato questo errore oggi a causa di un difetto nel codice che è stato inviato indietro un'enorme quantità di volte causando l'inondazione di IIS di richieste. Questo essenzialmente ha bloccato IIS e quindi quando ho provato a eseguire il debug, è "scaduto" il tentativo di avviare il debugger. Ho semplicemente riavviato IIS, che ha richiesto alcuni minuti e ha risolto il problema.

Sicuramente vorrei che questo errore fosse meno generico, sembra che ci siano diversi modi per produrlo.

Ho avuto lo stesso problema in Visual Studio 2012 e 2013 su Windows 8.1. Per me la soluzione era aggiungere l'autenticazione di Windows a IIS utilizzando "Attiva o disattiva le funzionalità di Windows"

Assicurati che il pool di applicazioni del tuo sito utilizzi la versione del framework corretta . Ho ricevuto l'errore "Impossibile avviare il debug" su un sito ASP.Net 2005. Stava usando in modo errato DefaultAppPool su Windows 7 (che credo stesse usando .Net Framework 4). Ho creato un nuovo pool di app basato su .Net Framework 2 e l'ho assegnato al sito Web del problema. Dopo che il debug ha funzionato bene.

Controlla se il tuo sito web su IIS non è fermo.

L'ho risolto e ho messo in funzione il mio sito web. : D

Ho avuto questo problema e alla fine mi sono reso conto che ASP.net non è registrato correttamente con IIS. Ciò può accadere quando il server IIS viene installato prima di Visual Studio. Per risolvere questo problema, usa il comando aspnet_regiis -i Ulteriori informazioni sono disponibili nel collegamento

ha avuto lo stesso problema. Se hai un certificato SSL installato su IIS e se stai tentando di eseguirne il debug da Visual Studio, devi impostare l'applicazione su IIS per ignorare il certificato.

Ho avuto lo stesso problema e ho scoperto che era causato perché avevo un carattere digitato per errore nel mio Web.configdopo il tag di fine. Il mio Web.configsi presentava così proprio alla fine: </section>h. La "h" era un carattere extra dopo il tag di chiusura.

rimuovere la puntura in questo modo: targetFramework = "4.0" in web.config o modificare AppPool nella versione del framework appropriata.

La disinstallazione dell'estensione IIS UrlScan ha risolto il problema per me.

Avevo affrontato lo stesso problema ma era sul server di sviluppo web di Visual Studios invece che su IIS. Per aggirare il problema, deselezionare l'opzione nella scheda Web sotto le proprietà del progetto, Applica le impostazioni del server a tutti gli utenti (memorizza nel file di progetto.). farà risparmiare tempo prezioso a qualcuno.

Ho avuto lo stesso problema. Tutte le risposte sopra non hanno funzionato per me. La soluzione era eliminare manualmente la cartella bin e obj.

Ho riscontrato anche questo problema, ma era molto simile a quanto spiegato da @Kirk e alla riscrittura dell'URL.

Nel mio caso qualcuno aveva archiviato questa modifica nel file web.config per un progetto MVC:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Poiché le estensioni di file .aspx non erano consentite sul server Web, l' /debugattach.aspxURL è stato negato, impedendo l'esecuzione del debugger. Una volta rimossa questa configurazione, ha funzionato di nuovo.

Ho avuto lo stesso problema quando ho creato l'applicazione in Visual Studio, quindi nelle proprietà ho creato la directory virtuale da utilizzare con IIS locale. Se qualcuno ha questo errore è perché VS crea un'applicazione sotto AppPool sbagliato, cioè sotto AppPool che non si adatta alle tue esigenze.
In questo caso, vai a Gestione IIS, seleziona App, Vai a Impostazioni di base e cambia AppPool per App e sei a posto.

Ho ricevuto lo stesso errore di recente e nel mio caso si è scoperto che c'erano tipi MIME duplicati. Di recente ne avevo aggiunti due che inizialmente non apparivano nell'elenco. IIS mi ha permesso di aggiungerli ed è stato solo quando ho deciso di controllare nuovamente i tipi MIME per il sito come parte del mio processo diagnostico che ho ricevuto un errore anche in IIS. Fa riferimento a duplicati in web.config. Una volta tornato nel file web.config ho notato che era stata aggiunta una nuova sezione chiamata, che includeva i due tipi MIME aggiunti di recente. Eliminata quella sezione e la vita è di nuovo bella! Sperando che questo possa aiutare altri che non sono riusciti a risolvere il problema con nessuno degli altri suggerimenti.