Directory di lavoro corrente nei code-behind di ASP.NET: possiamo dipendere da questo?

Question

Possiamo fare affidamento sulla directory di lavoro corrente nei code-behind di ASP.NET? O, in altre parole, possiamo usare percorsi relativi ed essere certi che funzioneranno?

Se, in una pagina di un sito Web, ho impostato la directory di lavoro corrente su qualcosa di specifico, sarà ancora la stessa la prossima volta che verrà caricata un'altra pagina sul sito web? Quando viene caricata la stessa pagina sul sito web?

Se imposto la directory di lavoro corrente su qualcosa di specifico, in Page_Load(), posso essere sicuro che sarà sempre lo stesso quando viene chiamato Page_PreRender()? Oppure un'altra pagina sullo stesso sito può cambiarla con me, in mezzo? Potrebbe cambiare la pagina su un sito Web diverso nello stesso pool di applicazioni? Una pagina in un sito Web diverso in un pool di app diverso?

In altre parole, qual è lo scopo della directory di lavoro corrente, in IIS? È specifico per una pagina? E 'specifico per un sito web? O è condiviso tra tutte le pagine in un pool di app?

Dove, tra pagina, sito Web, pool di applicazioni e server, sono i limiti che isolano diversi valori della directory di lavoro corrente?

Answer 1

Environment.CurrentDirectory è un semplice wrapper per le funzioni GetCurrentDirectory e SetCurrentDirectory WinAPI. In effetti, il tentativo di impostare la directory richiede autorizzazioni UnmanagedCode. Ogni volta che una funzione impedisce al tuo sito di funzionare con fiducia parziale, hai ragione a diffidare di dipendere da esso. :)

Dalla documentazione SetCurrentDirectory:

cambia la directory corrente per il processo corrente.

La migliore spiegazione che posso trovare che riguarda il rapporto tra il processo w3wp.exe e un sito ASP.NET è this answer. Qualsiasi altra pagina all'interno del tuo sito potrebbe potenzialmente cambiare la directory di lavoro corrente della pagina. Qualsiasi pagina su qualsiasi altro sito sotto lo stesso pool di applicazioni potrebbe potenzialmente cambiare la directory di lavoro corrente della pagina. Queste modifiche esterne alla directory di lavoro corrente potrebbero verificarsi in qualsiasi momento durante l'esecuzione della pagina. D'altra parte, una pagina su un sito con un diverso pool di applicazioni non cambierà la directory di lavoro corrente della pagina. La ragione per cui dico "potrebbe potenzialmente" è che diventa ancora più complicato se si considerano scenari di web garden, in cui possono esistere più processi per un singolo sito ASP.NET.

Ora ritengono che SetCurrentDirectory non è thread-safe:

applicazioni multithreaded e condiviso codice della libreria non dovrebbe utilizzare la funzione SetCurrentDirectory e dovrebbe evitare di utilizzare percorso relativo nomi. L'attuale stato della directory scritta dalla funzione SetCurrentDirectory viene memorizzato come variabile globale in ogni processo, quindi applicazioni multithread non possono utilizzare correttamente questo valore senza la corruzione dei dati da altri thread che può anche essere di lettura o impostando questo valore. Questa limitazione si applica anche alle funzioni GetCurrentDirectory e GetFullPathName. L'eccezione essendo quando l'applicazione è garantito per essere in esecuzione in un singolo filo , ad esempio analisi nomi di file dalla stringa di argomento della linea di comando nel thread principale prima di creare eventuali ulteriori fili. L'utilizzo di nomi di percorso relativi nelle applicazioni multithread o nel codice di libreria condiviso può produrre risultati imprevedibili di e non è supportato.

Le probabilità sono che non si vuole dipendere dalla directory di lavoro corrente. Detto questo, visto quanto è folle affidarsi alla directory di lavoro corrente, si può essere ragionevolmente certi che nessun altro codice lo toccherà. :) Un'occhiata veloce con Reflector mostra che nessun codice .NET Framework lo cambia. Alcune funzioni lo controllano, quindi fai attenzione a quelle. Se si controlla l'ambiente di distribuzione, è possibile garantire che il sito venga eseguito nel proprio pool di applicazioni. Con la corretta tecnica di sincronizzazione, dovresti essere in grado di in modo sicuro aggiornare la directory di lavoro corrente. Però non lo considererei altro che un trucco.

Answer 2

I collegamenti dovrebbero essere creati relativo alla radice del sito utilizzando l'operatore tilde (~):

<a href="~/mysite/somepage.aspx" id="someLink" runat="server">Some Page</a> 

In un server, un pool di applicazioni isola completamente il vostro sito in modo che se qualche altro sito si blocca sullo stesso server , non farà cadere il tuo sito con esso. IIS è praticamente specifico del sito con i vantaggi di isolamento aggiunti dei pool di app. Non vedo alcun uso pratico nel provare a cambiare un link su una pagina dal code-behind in un altro (o forse non capisco abbastanza la domanda).

Ecco una sintesi di architettura di IIS:

http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis-7/

Answer 3

AppDomain.CurrentDomain.RelativeSearchPath vi darà il percorso fisico della cartella bin