2011-08-09 14 views
6

La aplicación se divide en dos hilos; la aplicación web principal y una secuencia secundaria utilizada para el manejo de eventos asíncronos. El subproceso secundario recibe un evento donde necesita enviar un correo electrónico con una URL completa de la aplicación principal (más argumentos de ruta adicionales) dentro de él.¿Cómo resuelvo una URL de la aplicación desde una cadena de fondo en ASP.NET MVC?

Por ejemplo. http://Server.com/App/RouteData?AdditionalArguments

Por supuesto, el hilo de fondo no tiene el lujo de usar HttpContext.Current para resolver una Url, porque no hay ninguna solicitud. No HttpRequest, no HttpContext ...

Descubrí que la mayoría de los métodos que utiliza ASP.NET (incluso con MVC) para construir URL se basan en HttpContext. ¿Existe una forma de construir una URL de aplicación totalmente calificada en ASP.NET sin utilizar HttpContext ni ninguno de sus derivados?

Busco un método seguro para subprocesos como:

UrlHelper.GetApplicationtUrl() 

alguna idea? Tus sugerencias son muy apreciadas.

Respuesta

1

Tuve este problema exacto. Terminé almacenando la url en el archivo web.config. Hice la mía, así:

<appSettings> 
    <!-- Urls --> 
    <add key="AppDomain" value="http://localhost:1273/" /> 
    <add key="ConfirmUrl" value="http://localhost:1273/Auth/Confirm/?code={0}" /> 
</appSettings> 

y lo llamó así en la capa de servicio:

string confirmUrl = string.Format(ConfigurationManager.AppSettings["ConfirmUrl"], confirmCode); 
+0

Después de mucha experimentación, encontré que esta es la mejor solución. Usar System.Web.Mvc.UrlHelper en Application_Start para encontrar el URL de la aplicación, luego asignarlo a una variable estática en un singleton o pasarlo como un argumento de constructor usando la inyección de dependencia también funciona. Sin embargo, las fallas imprevistas entran en juego al usar esta solución, como recibir una url base de servidor proxy para equilibrar la carga. La configuración parece ser la mejor solución porque la dirección del servidor de destino (y el protocolo) no siempre se puede determinar en tiempo de ejecución. Lo mejor es preestablecerlo. Gracias Shawn :) – Nautic20

0

Si no se puede simplemente utilizar el archivo de configuración, al crear el hilo, utilice el delegado ThreadStart para proporcionar la información básica que necesita al nuevo hilo.

+0

Pensé en esto también, pero ¿qué pasa si algo más que una solicitud web llama al método de servicio? O algo así como un rol de trabajador para Windows Azure. (bueno, para mi caso de todos modos). –

+0

De acuerdo con @Shawn Mclean. Al abordar la situación desde esta ruta, el momento ideal para invocar HttpContext (para obtener una url base) no sería ThreadStart porque eso supondría nuevamente que tiene recursos que podrían no estar disponibles en ese momento. Yo prefería obtener la url base en Application_Start; que ocurre durante una solicitud y es el mismo momento en que suscribo el evento al controlador de eventos. – Nautic20

Cuestiones relacionadas