Directorio de trabajo actual en ASP.NET code-behinds - ¿podemos confiar en él?

Question

¿Podemos depender del directorio de trabajo actual en ASP.NET code-behinds? O, en otras palabras, ¿podemos usar rutas relativas y asegurarnos de que funcionen?

Si, en una página de un sitio web, configuré el directorio de trabajo actual como algo específico, ¿seguirá siendo el mismo la próxima vez que se cargue otra página en el sitio web? ¿Cuándo se carga la misma página en el sitio web?

Si configuro el directorio de trabajo actual como algo específico, en Page_Load(), ¿puedo estar seguro de que seguirá siendo el mismo cuando se llame a Page_PreRender()? ¿O podría otra página en el mismo sitio web cambiarlo en mí, en el medio? ¿Podría una página en un sitio web diferente en el mismo grupo de aplicaciones cambiarla en mí? ¿Una página en un sitio web diferente en un grupo de aplicaciones diferente?

En otras palabras, ¿cuál es el alcance del directorio de trabajo actual en IIS? ¿Es específico para una página? ¿Es específico para un sitio web? ¿O se comparte entre todas las páginas de un grupo de aplicaciones?

¿Dónde, entre página, sitio web, grupo de aplicaciones y servidor, están los límites que aíslan los diferentes valores del directorio de trabajo actual?

Answer 1

Environment.CurrentDirectory es un simple envoltorio en torno a las funciones GetCurrentDirectory y SetCurrentDirectory WinAPI. De hecho, intentar establecer el directorio requiere permisos UnmanagedCode. Siempre que una función impida que su sitio se ejecute en confianza parcial, tiene razón al desconfiar de depender de ello. :)

De la documentación SetCurrentDirectory:

Cambia el directorio actual para el proceso actual.

La mejor explicación que puedo encontrar que cubre la relación entre el proceso de w3wp.exe y un sitio ASP.NET es this answer. Cualquier otra página dentro de su sitio podría potencialmente cambiar el directorio de trabajo actual de su página. Cualquier página en cualquier otro sitio bajo el mismo grupo de aplicaciones podría potencialmente cambiar el directorio de trabajo actual de su página. Estos cambios externos al directorio de trabajo actual pueden ocurrir en cualquier momento durante la ejecución de su página. Por otro lado, una página en un sitio bajo un grupo de aplicaciones diferente no cambiará el directorio de trabajo actual de su página. La razón por la que digo "podría ser potencialmente" es que se vuelve aún más complicada si se consideran los escenarios de los jardines web, donde puede haber más de un proceso para un solo sitio ASP.NET.

Ahora consideran que SetCurrentDirectory no es seguro para subprocesos:

aplicaciones multiproceso y compartieron código de la biblioteca no debería utilizar la función SetCurrentDirectory y debe evitar el uso de nombres de ruta relativa . El estado directorio actual escrito por la función SetCurrentDirectory se almacena como un variable global en cada proceso, por lo tanto, aplicaciones multitarea, no pueden utilizar de forma fiable este valor sin posible corrupción de datos de otros hilos que también pueden estar leyendo o establecer este valor. Esta limitación también se aplica a las funciones GetCurrentDirectory y GetFullPathName. La existencia cuando se garantiza la aplicación excepción a estar en ejecución en un solo hilo , por ejemplo, el análisis nombres de archivo de la cadena de argumentos de línea de comandos en el hilo principal antes de crear cualquier hilos adicionales. El uso de nombres de ruta relativos en aplicaciones multiproceso o códigos de biblioteca compartidos puede generar resultados impredecibles y no es compatible.

más probable es que que no quiere depender del directorio de trabajo actual. Habiendo dicho eso, dado cuán tonto es confiar en el directorio de trabajo actual, puede estar razonablemente seguro de que ningún otro código lo tocará. :) Un rápido vistazo a Reflector muestra que ningún código de framework .NET lo cambia. Sin embargo, algunas funciones sí lo comprueban, así que ten cuidado con ellas. Si controla el entorno de despliegue, puede asegurarse de que su sitio se ejecute en su propio grupo de aplicaciones. Con la técnica de sincronización adecuada, debe poder de forma segura actualizar el directorio de trabajo actual. Sin embargo, no lo consideraría más que un hack.

Answer 2

Los enlaces deben ser creados en relación con la raíz del sitio mediante la tilde (~) del operador:

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

Dentro de un servidor, un grupo de aplicaciones aísla completamente su sitio de modo que si algún otro sitio se estrella en el mismo servidor , no derribará su sitio con él. IIS es bastante específico del sitio con los beneficios de aislamiento añadidos de los grupos de aplicaciones. No veo uso práctico para tratar de cambiar un enlace en una página del código subyacente en otra (o tal vez no entiendo muy bien la pregunta).

He aquí un resumen de la arquitectura de IIS:

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

Answer 3

AppDomain.CurrentDomain.RelativeSearchPath le dará la ruta física a la carpeta bin