This is an example of how perplexing the interaction of the different SharePoint components creates confusing debugging scenarios for developers. I describe the process I went through to diagnose an elusive HTTP 404 error. If you just want the solution, find the section titled “The Solution” near the end.
I had a working SharePoint farm solution with two application pages. I developed the relatively simple solution mostly using Entity Framework. I understand that touching the SharePoint database is an anti-pattern, anything that goes around the official reliable API is a bad anti-pattern. I wasn’t touching the database, just looking J. It was an experimental project anyways. But which database I was accessing, is not related to the issue I was facing:
I deployed the application successfully to a different server. Everything is working fine.
The environment of the test server changes much dynamically than a relatively static very stable production server. For some reason, going back to this project after a while, I run the solution and navigate to one of the SharePoint application pages. To my unpleasant surprise, I get an HTTP 404. Everything is working except my two pages.
What could be going wrong? The solution is deployed successfully and I can find my application pages in the SharePoint layouts folder (defaults to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\). I traverse the possible-solution-treeor graph, no, it’s actually a maze (at least to someone like me who is not a Microsoft MVP SharePoint consultant with 15 years of experience).
I added try-catches everywhere, even though I had a big try-catch wrapping the main part of my code. No exception was caught, so I thought there is some exception handled by an internal component of SharePoint, and that component is totally invisible to me. Speaking of S = A + B in one of my previous posts, we have S = A + B + C where C is a component that is just invisible to you!
I also tried to recreate the application pages and re-adding them as maybe some SharePoint project build configuration got messed up somehow, then I tried to recreate the whole project to the same result: HTTP 404. I was stunned because there is no configuration or deployment issues and no apparent problems with my code, which was working before!
Suspecting again the problem is with the code, I created an empty SharePoint application page to my project, and to my surprise it worked. This points that I am indeed doing something wrong with my application pages, yet no exception is thrown that I can catch! And what is this HTTP 404 for an application page that is actually there?! Chrome’s debugging console simply just shows that the application page is being requested but not found.
I remember how sometimes Visual Studio debugger fails to catch some kind of errors, either because it is configured not to do so, or it just fails: COM Exception and Visual Studio crashing. But this doesn’t seem to be a Visual Studio problem.
Then I checked the SharePoint logs… What a nightmare trying to find your way there.
What I’m trying to illustrate here is that checking the various components in a system in an attempt to diagnose errrrrors involves considering different scenarios and options. I tried many options until…
The Solution
I discovered that the primary difference between my application pages that caused the server to return a 404, and the other empty application page is the reference to EntityFramework. When the runtime tries to load EntityFramework.dll, a System.IO.FileNotFoundException is thrown because the DLL is not deployed in the right way with the solution.
A SharePoint solution is dissimilar to a regular Web Application project in the way it is deployed. When a web application is deployed, the application can find the libraries that it references in the same location of the application’s DLL or in the machine’s GAC.
In my case, and for some reason, the SharePoint solution was not able to find EntityFramework.dll. It’s a file, and because of the System.IO.FileNotFoundException, either ASP.NET or SharePoint environment found it appropriate to just return a 404. This is simply does not follow the HTTP protocol where a 404 means that the client requested the wrong location. The server not being able to find files required for the page to operate correctly is in fact a 500 server side error!
Deploying EntityFramework.dll in the GAC solved the issue. I must remark that part of the possible-solution-treehas something to do with running Visual Studio with Administrator privileges.