Friday, July 13, 2012

Could not load file or assembly [AssemblyName] or one of its dependencies

Yellow Screen of Death Error:
Could not load file or assembly [Assembly Name Here] or one of its dependencies.

The Gripe
I hate this error because it is very misleading with respect to visual studio. You compile and re-reference your code to no avail. I have seen this error RANDOMLY appear for no good reason I could EVER find. I have gotten very good at knowing when this error is a load of bull and when it is a legitimate error. It is a legitimate error in the sense that it is indeed happening, but it really means that IIS7 choked again (surprise surpise).

Why does this happen?
This error can crop up after a physical traumatic computer event such as a random shut down, loss of power, blue screen of death (BSOD) or any variation of those. Either way it @#!#$ up IIS and makes it go stupid. I have seen this error crop up all on its own before without anything ridiculous happening to my host machine before. The cache does just get mucked up.

The Gotcha
No amount of recompiling your code will fix this. The only thing that can happen is that IIS somehow cleans its self up appropriately on its own. You must clean out the IIS Temporary Files.

The Fix
At this point you need to clean out IIS's Temporary Files, as a necessary and paranoid precaution you should clean out all caches regardless of what version of .Net version you are running. I cannot prove this, but for whatever reason windows likes to make copies of your Temp Files in both main flavors of .Net. Why? I am not sure.
  1. Very important, open up cmd and stop IIS. Start > Run > cmd > iisreset /stop
  2. Delete the suspect folders** for your application from the following folders. If you are unsure which folder to delete then just delete them all. It is harmless (usually) to do so since these are just cached versions of your sites and applications. Your working copy (your code) is copied here after compilation by IIS for run time which is one of the reasons why you can't just drop in a dll during run time in production because it has to re-cache your files which kills your application pool.

    x86v2.0C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
    x86v4.0C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
    x64v2.0C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
    x64v4.0C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

  3. Assuming your cmd window is still open - start IIS. Start > Run > cmd > iisreset /start
    Please bare in mind that your site needs to re-cache itself, this can take sometime depending on the size of your site, so be patient. In order to initiate the re-caching effort, just navigate to your site and that will start up the w3wp.exe process which will automatically start caching your site.
**If your application is running as the site and not an application (virtual folder) on the site, then you should delete the folder named "root" as it is the "root application".

Monday, July 9, 2012

Why can't I access the System.Web.HttpUtility Class?

I've run into this problem before and I didn't realize it until right now that I never wrote down the solution, hence the post.

The Problem
So if you found yourself trying to use System.Web.HttpUtility, but the only thing that was popping up in intellisense when you typed "System.Web." was "AspNetHostingPermission, AspNetHostingPermissionAttribute, AspNetHostingPermissionLevel" which is obviously not what you were looking for. Here is a Gotcha!

Not what you wanted.
The Gotcha
You cannot use System.Web.HttpUtility in a static class or static method. So make sure that isn't what you are doing. Now if you cannot switch what you are working on from a static sense into an instance based sense then there is still hope. You can simply throw together a method in a utilities class that is instance based, instantiate it and use the HttpUtility indirectly. Problem solved.

Why is this how this works? I have no idea, but I am sure there is a good reason for it.

The Code
Here is some code to help you get started on cheating the need for an instance.

public class Utilities
{
 //Instance based method 
 public string HtmlDecode(string s)
 { 
  return HttpUtility.HtmlDecode(s); 
 }

 //Instance based method
 public string HtmlEncode(string s)
 {
  return HttpUtility.HtmlEncode(s);
 }

 //Static based method
 public static string SHtmlDecode(string s)
 {
  return new Utilities().HtmlDecode(s);
 }

 //Static based method
 public static string SHtmlEncode(string s)
 {
  return new Utilities().HtmlEncode(s);
 }
}