Work Around to Clearing ASP.NET Temp Folder for a Specific Site

Sorry I haven’t had time to blog in over a year. I’ve been busy working on a MongoDB project. I just came across this issue with a customer the other day and couldn’t find the answer to this question:

How do I find and delete the ASP.NET temp folder contents for a specific site while leaving the other temporary files for other sites alone?

Sometimes, ASP.NET will return an error with the specific path in the ASP.NET temp folder showing a conflict in two .dll files. In this case, it’s easy. Just delete the files. But what do you do when it just tells you there is a conflict in assemblies but doesn’t show the path? Here is the work around solution I came up with:

1) Rename the web.config file temporarily to something else like web.config.bak.
2) Reload the site to force a recompile.
3) Rename web.config.bak back to web.config.
4) Reload the site again to force a recompile.

This should clear out the ASP.NET temp folder contents for that specific site each time the site is recompiled.

Simple Code in C# to Convert DateTime object to the “datetime-local” type used in input controls with MongoDB Driver

As the title suggests, the following code converts a DateTime object to the “datetime-local” type used in HTML5 input controls (i.e. format 2016-10-30T00:00:00.00).  I developed this while working on a personal application using C# and MongoDB.  It uses the ToJson() function/method of the MongoDB Driver.

using MongoDB.Driver;
using System;

Datetime dt = new DateTime();
var dtLocal = dt.ToJson().ToString().Replace("ISODate(\"", "").Replace("Z\")", "");

Hopefully by posting this, it will help others save time.

Another Cause for the Resource interpreted as but transferred with Error

In a previous article, I described what could cause this error.  While helping a customer the other day, we discovered another culprit, password protecting a directory.  The solution is to put the resources (i.e. .css, .js, image files, etc.) in a location which is publicly accessible (i.e. not under directory tree which has been password protected).  I also think this error may be particular to Chrome’s Developer  Tools.  The customer was using Internet Explorer, and this was the error that was thrown instead:

SEC7113: CSS was ignored due to mime type mismatch.