WebResource.axd gives 404

My colleague, Michael Knudsen, has been struggling with a customer & partner for several hours now with an annoying problem on an EPiServer 4.62 site just moved to a production server. Finally, after browsing through half the web and getting valuable feedback from most supporters / developers known to man, a simple solution was discovered.

To save other people the agony he's gone through he persuaded me to post the solution here...

 

Problem symptoms:

When clicking on a button in a webform the following javascript error occurs: Webform_Postbackoptions is undefined. A little simple debugging later it turns out that the page in fact did get a 404 when requesting a web resource (javascript) from the server - which is where the method is defined.

<script src="/WebResource.axd?d=14ZW9Y1So0D_eFk6_pguuw2&amp;t=633359999849186250" type="text/javascript"></script>

If you don't know what webresources does there's a good intro here. This problem had us all stunned for a while - lots of theories going through our heads...."It must be a web.config problem - some handlers are interfering with each others", "Perhaps asp.net isn't properly installed on the server", "But it's working on my machine", "Is this using AJAX?", "Can't we just put the dev. server where it works into production", etc. were some of the thoughts going through our heads as the problem took over our common sense.

 

Solution:

Uncheck this checkbox in IIS:

 

 

Skype and Port 80

This is probably old news to a lot of people, but I just ran into an error message in IIS7 on my Vista saying that "The process cannot access the file because it is being used by another process" whenever I tried to start my default website.
Ah well, I thought...Better shut down various other applications although I was wondering what file it could possibly be that there was a sharing conflict on. So, all other app's seemingly shut down, but I still couldn't start my website.
Before I got the error I had been spending numerous hours getting more and more annoyed at IIS7 so I concluded that this was probably something caused by yet another pseudo-paranoid default security setting somewhere - and I guessed that the error was probably misleading and in fact not related to files at all.
Luckily at this point Ruwen came to my rescue and pointed out the obvious that I somehow had missed:
Ruwen: "it could be skype blocking the port 80"

And it turned out that he was (as always) right. Skype listens by default on port 80 and thereby blocks the device (LISTEN on 80) that IIS is using when starting a site.
After visiting Skype's advanced settings and turning off that obscene feature saved my day.