Question

Well…I feel absolutely stupid. Here’s why:

I have been using some library functions I wrote 2 years ago. Buried a few levels deep, I was using these functions to help build the path I wanted:

System.Web.HttpContext.Current.Request.ApplicationPath
System.Web.HttpContext.Current.Server.MapPath

Instead of using this:

HttpRuntime.AppDomainAppPath

System.Web.HttpContext.Current will be certainly null because there is no http context. And, of course, no exceptions were being thrown because I was trapping and ignoring them.

You don’t know how many hours I was staring at my project wondering what the heck was wrong!

Please forgive me for wasting everyine’s time. This is so embarassing!!!

Answer 1

It is discouraged to spawn threads in ASP.NET applications. I know it can technically be done, but there are lots of gotchas that you have to account for. The recommended best practice is to create a Windows service to run your background tasks. Then your ASP.NET app can issue requests to the service, which handles them in the background.

Updated with references

From comments on multi threading on asp.net:

One warning about using background processing on ASP.NET sites. IIS can recycle the application at any given moment and will kill any running background thread while doing this. So there is no guarantee that your thread pool threads will run succesfully. If that’s a problem, it is better to use a Windows service to do the background processing.

Additionally, SO user Mr. Disappointment goes into detail here, saying:

Windows services are designed to be long running, and if something goes wrong you’ve generally got more to worry about than your individual service.