Hi,

The issue is not caused by our code, but something in your server settings or the environment. In fact this issue is happening to a lot of people across the whole world with all sorts of products, including Microsoft own DLLs, and there is no ultimate solution that would handle that for all scenarios. If you type "thread was being aborted" or "could not load file or assembly access denied" into Google, you will get results to a lot of forums where people are trying to solve that, here are just some of them to prove that:

stackoverflow.com/questions/1433448/thread-was-being-aborted
forums.asp.net/t/1343157.aspx/1
www.dotnetnuke.com/Community/Community-Exchange/Question/142/How-to-solve-Thread-was-being-aborted-error.aspx

http://forums.asp.net/t/1365076.aspx/1
http://csharpguild.blogspot.com/2007/12/could-not-load-file-or-assembly-access.html
http://forums.iis.net/t/1157415.aspx
http://stackoverflow.com/questions/809144/could-not-load-file-or-assembly-someproject-or-one-of-its-dependencies-access
http://crmbusiness.wordpress.com/2011/05/24/could-not-load-file-or-assembly-or-one-of-its-dependencies-access-is-denied/


I will at least try to help you out by what I learned about this so far, so you don't stay stranded not knowing how to continue. Just in case I am not successful, I recommend you to approach Microsoft support, because if your server is setup right, they are the only ones that may help since it is their framework afterall. If some of these advices will help you, please let us know which one so we can have some more information to other people that may eventually approach to the same issue. Here are causes that I found feasible so far from what people were trying with other products:


1) Windows account under which the Application pool is running may not have enough permissions to access the ASP.NET temporary folder. It seems like under certain curcumstances, when the application is being recycled, it runs with not enough privileges to access the DLLs while under others, it is able to do that.


2) Somehow messed up ASP.NET temporary files or Global Assembly cache. Some people figured out that if they clean their servers from the old temporary ASP.NET files or remove duplicities of the DLLs vith other versions from GAC, the issue disappears. I am a little sceptical about this, because this action actually restarts the process so it may get another chance of loading with proper permissions as mentioned above, so it may not be a long term solution. Anyway, it is worth a try.


3) Sometimes people weren't able to fix it with these, and in that case various other professionals were giving suggestions such as re-registering the ASP.NET within IIS, applying windows or .NET patches, etc. I cannot really give you my opinion about this because there is mostly no feedback whether some of that helped or not, but you may definitely try the same application on another machine to see if that issue is somehow environment specific.


I am sorry that we cannot help you with this more and give you an ultimate solution. I must say we are very upset about this as well, since Microsoft clearly didn't handle this properly and we already had to explain several people how come that this is not something we can fix even if we would love to, it simply isn't our code causing it.


Please let me know it any of that helped, so we can provide some more expertise to potential future clients that will be in the position to solve it.

Best regards,
Juraj Ondrus