Distribuire ASP.NET MVC 2 a IIS 7.5 targeting .NET 3.5

Question

Ho creato un'applicazione ASP.NET MVC 2 in Visual Studio 2008. Ho impostato il build di rilascio per passare attraverso il compilatore ASP.NET per precompilare tutte le viste, ridimensionare Javascript e CSS, ripulire il web.config, ecc. Poiché la distribuzione di produzione sta per un server IIS6, ho impostato la distribuzione pseudo-produzione sul mio computer Windows 7 per fare in modo che il pool di applicazioni esegua in modalità classica il runtime 2.0 . Ho impostato il gestore senza estensione nel web.config che è necessario e tutto ha funzionato alla grande.

Il problema è venuto quando ho aggiornato la soluzione a Visual Studio 2010. sto ancora targeting 3,5 quadro, ma ora sto usando MSBuild 4.0 dato che è quello di Visual Studio 2010 utilizza. Tutto ancora viene compilato correttamente perché funziona correttamente con Cassini, ma quando lo distribuisco nella stessa posizione (stesso pool di applicazioni, identità, ecc.) Ora si comporta diversamente. Ho ancora il gestore extensionless in web.config, ma ora quando navigo alla radice dell'applicazione esegue la navigazione in directory e tutte le rotte che aveva precedentemente gestito ora tornano come errori 404 gestiti dal gestore StaticFile in IIS . Sono in perdita per ciò che è cambiato e sta causando la rottura.

Ho visto this question, ma ho già verificato che tutti i componenti prerequisiti siano installati.

Answer 1

Hai provato a eseguire il debug dei percorsi utilizzando Phil Haack route debugger sul server?

Edit:
In IIS 7.5 non voi bisogno di alcuna speciale gestore senza estensione, questo viene gestito automaticamente, non c'è bisogno di cambiare nulla. È necessario solo su IIS 6 per quanto ne so. Potrebbe essere questo il problema? cosa succede se rimuovi quel gestore speciale? forse questo è ciò che lo ferma per calciare il motore del percorso.

Edit:
Ho ricontrollato, e come pensavo, a partire dal IIS7, la modalità predefinita di un dominio di applicazione è modalità integrata. Ciò significa che lo stack Asp.net prende il via ad ogni richiesta, mentre in modalità classica, asp.net è stato chiamato solo quando un'estensione specifica dove è stata chiamata (aspx ashx axd è mappata per impostazione predefinita al filtro aspnet_isapi).
UrlRoutingModule si avvia a ogni richiesta senza richiedere nulla da te perché è un HttpModule e non un gestore. (deve solo essere registrato nel file di configurazione della tua applicazione, non è necessario mapparlo a un'estensione, ma è di default in un'app MVC. Puoi aprire il tuo file Web.Config e verificare di avere sotto a nodo

<modules runAllManagedModulesForAllRequests ="true"> 
... 
<add name="UrlRoutingModule" type=.../> 
</modules> 

Sei sicuro di distribuire gli assembly MVC al server? Verificare che System.Web.Mvc, System.Web.Routing e System.Web.Abstraction riferimenti hanno la copia La proprietà locale è impostata su true per essere certi di utilizzare gli stessi assembly localmente e sul server di produzione ...

Se tutto ciò è corretto, non so come aiutarti di più ... Spero che questo ti aiuterà, o almeno ti metterà sulla buona strada.

EDIT: Oww ... basta leggere il tuo ultimo commento ... scusate mi mancava quell'elemento sulla modalità classica. Il tuo titolo parla di IIS7.5 e ho assunto troppe cose.è per questo che mi sono confuso.

In questo momento, ho dovuto esaminare il libro di Steven Sanderson. Ha una lista di controllo per la risoluzione dei problemi di implementazione di IIS6. So che stai dicendo che è solo quando si utilizza MSBuild 4 che non riesce, ma potrebbe essere ancora utile

Verificare che Default.aspx sia impostato come pagina di contenuto predefinita. Questa potrebbe essere la fonte di 404.

Quindi per disporre di URL senza estensione, l'ultima volta che ho distribuito su IIS6 ho usato una semplice mappa jolly e non ho mai avuto un problema ... Se sei ancora nei guai mi dispiace che io aiuto potrebbe'nt ... non che io fatto provare :) buona fortuna

Answer 2

idee Coppia di provare

• avete eseguire qualsiasi tipo di confronto tra l'uscita del VS2008 e VS2010 progetti? Verificando semplicemente che l'aggiornamento della soluzione non ha modificato nulla .
• È disponibile l'attributo web.config targetFramework nell'elemento ?
• Sei sicuro di non eseguire in qualcosa come l'esecuzione di un'applicazione x86 in un pool di app x64?

Immagino che tu stia bene, ma poiché Cassini non ha problemi con l'applicazione, mi prendo ancora in considerazione i problemi di web.config. Avete i vostri moduli/gestori registrati correttamente nell'elemento? Poiché stai utilizzando la modalità classica, avrai bisogno sia del "vecchio" che del "nuovo" (reference 1, reference 2).

Answer 3

Ho già postato questa soluzione in un'altra discussione, ma mi ripeterò. Usa classica modalità pipeline di AppPool:

alt text http://img823.imageshack.us/img823/3684/20100612135212.png

dot't anche dimenticare di installare il modulo HTTP reindirizzamento in Accendere funzionalità di Windows on o off.

Answer 4

Ho riscontrato questo problema oggi, in uno scenario simile.

Il problema nel mio caso era dovuto al fatto che 32 bit di asp erano registrati invece dei 64 bit, causando il problema con il routing.

È stato risolto digitando quanto segue nella riga di comando

CD c:\windows\microsoft.net\framework64\v4.0.30319 
aspnet_regiis -i