2010-01-19 10 views
7

Tengo un código de biblioteca, que debe tener en cuenta si se ejecuta en el contexto de un servidor web o servidor de aplicaciones independiente.¿Cómo puede saber un código .NET si se está ejecutando dentro de una aplicación de servidor web?

Lo más obvio que se me ocurre es verificar el nombre del archivo de configuración de la aplicación y si es web.config, entonces este es un servidor web, de lo contrario, servidor de aplicaciones independiente.

Otra forma es buscar algo así como "Archivos ASP.NET temporales" en la ruta de la carpeta de la sombra.

Pero no me gustan estos dos, ya que parecen demasiado hacky y frágil. ¿Hay una manera robusta de hacer lo que quiero?

Gracias.

P.S.

Uno puede definir una configuración de configuración de aplicación dedicada - IsWebServer, pero no me gusta aún más.

EDIT:

bien en busca de una solución a otro problema, creo que he resuelto éste - los detalles son here

+0

¿Por qué necesita que sea consciente de su contexto? –

+0

Asignamos un significado especial a la primera carpeta en la ruta de exploración privada. La cuestión es que bajo el servidor web nuestra lógica debería funcionar de forma algo diferente, debido a las diferencias en las configuraciones privadas de las rutas de exploración entre un servidor web y una aplicación independiente. – mark

+0

Quizás debería anularlo para que simplemente almacene una implementación de patrón de estrategia en su marco, de modo que el marco en sí no necesite ningún código especial, ¿pero el código reside en su aplicación web? –

Respuesta

8

Tratando de resolver otro problema, encontré una buena solución para esta. Hay un método privado System.Configuration.SettingsPropertyValue.IsHostedInAspnet, que hace exactamente lo que necesito. Al ser un método privado, no quiero llamarlo (aunque podría usar la reflexión), pero su implementación es trivial:

private bool IsHostedInAspnet() 
{ 
    return (AppDomain.CurrentDomain.GetData(".appDomain") != null); 
} 

(de acuerdo con reflector)

Parece que hay una llave especial en los datos de dominio de la aplicación - ".appDomain", que se establece cuando se ejecuta en el servidor web ASP.NET.

Me apegaré a eso.

+0

Realmente creo que esto es terrible. Está usando un detalle de implementación que puede cambiar. ¿Funciona en Mono? No puedo imaginar por qué no harías la opción de configuración. Cada uno para los suyos. –

+0

@NoonSilk Sí, he hecho algunas búsquedas en Google y parece que '.appDomain' no está documentado públicamente. En cuanto a Mono, parece que funcionaría, ya que el código establece explícitamente un valor https://github.com/playscript/playscript-mono/blob/master/mcs/class/System.Web/System.Web.Hosting/ApplicationHost .cs –

7

puede comprobar si hay

HttpContext.Current 

Si se trata de no nulo, entonces se ejecuta desde una aplicación web.

Ver HttpContext.Current Property

+9

Eso solo funcionará si se ejecuta en el mismo hilo que la solicitud; posteriormente, los hilos de fondo generados no tendrán un HttpContext. –

+0

@DrJokepu - precisamente. En mi caso HttpContext.Current es nulo. – mark

1
  • BrowserInteropHelper .. ::. IsBrowserHosted Propiedad

Obtiene un valor que especifica si la aplicación actual (WPF) de Windows Presentation Foundation está alojado navegador .

Eso es como se hace en XBAP

o si tiene un dominio de aplicación hacer reflexión y conseguir algo de ella? utilizando

2

puede averiguar el nombre del proceso actual:

Process p = Process.GetCurrentProcess(); 
string assemblyName = p.ProcessName; 

y después comprobar si este es el ASP.NET process name

+0

¿Y si funciona en mono? –

+0

Creo que la respuesta será la misma. El código se ejecutará en el contexto del proceso de host del servidor web. – sagie

6

La mejor opción es un entorno de configuración .

Es mejor para la capacidad de prueba; es mejor porque es una declaración obvia de cómo funcionará el código, y es mejor porque no depende de los detalles de implementación; usted específicamente se ramifica desde un valor que establece. Puede ser que la decisión que está tomando no sea obvia y su variable/configuración pueda sugerir el razonamiento.

Es la opción que elegiría.

+0

Esto parece ser un poco corto de mi vista. Por ejemplo, como autor de un componente que puede distribuirse y venderse para su uso por otros desarrolladores, quiero que la licencia se comporte de forma diferente para los procesos web que ganar formularios o servicios o aplicaciones de consola. No quiero que el desarrollador de compras pueda "mentir" sobre cómo están usando el componente, y no quiero una referencia a 'System.Web' ya que mi componente funcionará bajo el perfil .Net Client. Quiero detectar un entorno web y cambiar internamente el comportamiento del conjunto en consecuencia. Actualmente estoy investigando la mejor manera de hacer esto. – BenSwayne

0

Creo que lo mejor que se puede hacer es dividir la biblioteca en 2 dlls, uno que es verdaderamente genérico y uno (el que requiere ASP.NET) que solo se carga en el sitio web. Comprobar si se está ejecutando actualmente en ASP.NET parece una especie de hack.

Por supuesto, depende de la situación, ya sea que no pueda hacerlo fácilmente.

Cuestiones relacionadas