These silly .NET Framework errors are the ones that really bug me, you spend SOOOOO much time trying to track down these things but the error messages are so vague that it's just an exercise in frustration most times. Here's another one of my favorites – getting the error "Could not load file or assembly". Now I'm used to seeing this when your app is configured to use one version of .NET and you are trying to reference an assembly built for a previous version. I'm not saying that's the only case where that happens, but for those of you who remember when we rolled out SharePoint 2010 and Visual Studio 2010, the way the defaults were set up in Visual Studio this happened to folks all over the place and was VERY difficult to track down; I know a lot of people that spent a lot of time fiddling with this.
So…when I saw this error recently that was the first thing I went looking for. My application was a custom claims provider for SharePoint 2013, and I had used NUGET to install the package for Windows Azure storage. I had done this originally with a simple .NET winforms application when I was testing out some code, and it was all working great there. So when I got this error with my custom claims provider, it was perplexing to say the least: the exact error message was Could not load file or assembly
'Microsoft.WindowsAzure.Storage, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. After a couple of hours trying completely random ideas (isn't that what we all end up doing with these kinds of error messages??), I finally had a brief and fleeting thought that proved to be the winner. I realized the difference between my custom claims provider and my winforms app is that I have to register my custom claims provider in the GAC. So, what I ended up doing was going through all of the assemblies that NUGET added to my project and doing a gacutil -i to install each of them. One IISRESET later, everything finally loaded up. I just wanted to capture it here in the hopes that someday, somewhere, a search engine will save you some random debug time trying to track this down.