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.
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.
I’ve been meaning to write a post on this for ages but I’ve always forgotten to take a screenshot until now. If you ever get this error thrown from your .NET application:
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application’s trust level in the configuration file.
Exception Details: System.Security.SecurityException: Request failed
This always means that you need to set your trust level to “Full” in your web.config file in order to correct the problem. I’ve included the correct XML markup that you need to add/modify in your web.config file below:
< ?xml version="1.0" encoding="UTF-8"?>