The following code results in our Visual Studio 2012 development web server, or the alternative IISexpress, effectively killing the AppDomain of our WebApp by executing a Thread.Abort in all of it’s constituent threads from the threadpool. What I do not understand is why? I cannot find anything documented which specifically states under what circumstances the web server would do this. Also, there is precious little from the "verbose" output of the web server itself.
This took several days worth of effort to track down. Normal debugging techniques proved worthless. I eventually had to resort to the tried and tested method of commenting out method bodies until I reached that "ah-ha" moment.
One of our developers had inadvertently created a temporary file and then closed it again deep within one of our ASP.NET services.
FileStream fs = File.Create(strFilePath);
The strFilePath was accidentally set to the same location as the WebApp’s assembly location. Namely:var basePathUri = new Uri(Assembly.GetExecutingAssembly().CodeBase);
var strFilePath = Path.GetDirectoryName(Uri.UnescapeDataString(basePathUri.AbsolutePath));
It’s worth saying, that this error is now corrected by correctly writing to the system temporary file space.
So once, again, we know this is bad practice, but why does the Visual Studio web server behave as it does?
PS I know there is a deployment difference between a development web server and a production web server (e.g. apache or nginx) with regard to copying all content to a temporary ASP.NET location. In fact, this problem does not manifest in deployment.