Catch exceptions in ASP.NET resulting from Generic

Question

I am trying to get a different server side stack functioning with my ASP.NET site. My ashx file seems to be throwing a 500 Internal Server Error. How do I figure out what exception this ashx file is throwing or the reason the 500 is being thrown? When I attach to my IIS 7 w3wp.exe process, it doesn't throw an exception, but I'm reading that this is likely the case.

The ashx file lives in the root directory of my ASP.NET site, and the Properties have it set to compile.

GET http://uhc-8:8883/MyApp/ExtDirectProxy.ashx 500 (Internal Server Error) index.html:27
Uncaught TypeError: Cannot read property 'isProvider' of null ext-all-debug.js:74832
allow right click initializing for http://uhc-8:8883/MyApp/index.html rightclick.js:1
allow right click processing http://uhc-8:8883/MyApp/index.html rightclick.js:25

Answer 1

You can use the Application_Error event in Global.asax file to catch that error.

protected void Application_Error(Object sender, EventArgs e)
{
    HttpContext ctx = HttpContext.Current;
    Exception exception = ctx.Server.GetLastError();
    int httpCode = ((HttpException)exception).GetHttpCode(); // check if it is 500
}

Answer 2

If you have a folder called "App_Code", you can go through headaches and migranes. Or simply replace "App_Code" with some random name like "code" or "data" and put your classes in there to fix this. In my case, my project GUID was a Web Application and C# type.

Best Answer:

App_Code folder issues

Note:

I am running the site using IIS with a static port, not using Visual Studio 2012 with a dynamic port. I have specific server configuration on the web server, so I want the site to behave the same way our released site works. So that's why I run it like that.

Answer to my question:

This occurred because we had duplicate versions of the App_Data classes in the bin folder. The "Compile" version of the *.cs, and the website version of the *.cs. The “isProvider” error happens when more than one class with the same name exists. When we deploy the ASP.NET application, we deploy ONLY the compiled version of the *.cs files. The development environment, we keep them set to Properties > Build Action > None.

Not sure of an easy way around that. It might have to do with having things in the temporary and/or obj folder, but not sure exactly. Will take a little more troubleshooting to discover why. In the mean time, here is a list of things to resolve the issue. Not sure if some or all of these were necessary, but it's working now.

Steps to fix:

• change all App_Data *.cs files to Properties > Build Action > Compile
• Fix exceptions they throw to get that build working again - Clean Solution > Build Solution ... one exception was not caught with those set to Properties > Build Action > None, so that's why this was necessary. Essentially, Visual Studio 2012 does not throw an exception and says "Build Successful".
• then change App_Data *.cs files back to Properties > Build Action > None
• remove dlls out of \obj\Debug
• remove dlls out of \bin
• remove temporary ASP.NET files - C:\WINDOWS\Microsoft.NET\Framework\{.NET version}\Temporary ASP.NET Files\
• Build Solution
• restart IIS web site

Now things work great!

EDIT:

Actual problem was that I was referencing an external project in Visual Studio, but there was no dll file for it because the project type was Console Application, not Class Library. The real problem was that Visual Studio says it compiles the code fine (in App_Code) when you have a using statement to that other project, but says Built Successfully, even when the Build Action > Compile option is set for all *.cs files in App_Code. When you run the web application, it has to be set back to Build Action > None for it to work. However, since the *.cs files in App_Code didn't actually compile with the new code (if that's how ASP.NET in IIS treats these App_Code *.cs files), it throws the 500 Internal Server error because there's no good CIL code during runtime. To solve it, I just changed the project type to Class Library, and it still has no errors, but now it can reference the dll to the other project.

The isProvider error always occurs when there are duplicate classes found. So I'm not sure why that occurs, but that essentially goes away once you fix the part above.