ASP.NET: WebResource.axd call 404 error: how to know which assembly/resource is missing or responsible?

Question

I get a 404 HTTP status error (not found) on a specific WebResource.axd call inside an ASP.NET 3.5 (AJAX) web application. I guess the error is thrown because a specific referenced assembly is missing in the bin folder/GAC. But I don't know which, since the page which requests the resource is very complex (I'm using third-party controls and ASP.NET Ajax.)

Is it possible to know from the encrypted "d" querystring parameter of the query, like:

.../WebResource.axd?d=...

which assembly should create the content and is possibly missing?

Note: There are other WebRequest.axd calls which execute with success.

Thanks!

Answer 1

Here is a very brief but helpful article on the subject.

Answer 2

Is your project missing any references?

Are there any references set to CopyLocal=False (common with Infragistics or GAC'ed refs) that dont make it to the destination?

A utility like reflector or dependency walker will tell you if your main assembly is missing any dependencies that are not immediately obvious.

Does the Application_Error handler in global.asax have a catch that is producing any error info (FileNotFoundExceptions)?

Did you set custom errors to 'remote only' and browse the site from the local machine?

Answer 3

I just spent hours on a similar issue. Due to the great article pointed out by Diadistis I was able to decrypt the WebResource url and find out that my WebResource was translated into a wrong assembly pointer, recognizable by the garbage in front of your resource name. After many struggles I found out that this was because I was using the Page.ClientScript.GetWebResourceUrl in a class deriving from another class which resided outside of the assembly my resource was in. Confusing thing was that my class WAS in the same assembly, though the class deriving from was NOT. The this.GetType() parameter many articles state is a must, turned out not to be so much of a must at all in my situation. Actually, it needed to be replaced with a typeof() and it worked! Hope this may prevent others from getting the same headache as I got from this bugger.