The .NET 2.0 framework changed the way clientside JavaScript is delivered to the browser. Previously, ASP.NET 1.1 used the aspnet_client directory whereas now 2.0 uses WebResource.axd.
When things go wrong, you'll see JavaScript errors about missing functions, including the now infamous 'WebForm_PostBackOptions is undefined'. After having this problem in one of my applications, doing a lot of googling on it, and eventually fixing it, I feel it's my turn to add to the fray of people writing about this in the hope that it helps someone.
There are a few things which can go wrong with WebResource.axd. Some of these are specific to compression (and in my case, the compression I'll be writing about is pretty specific to the Blowery module, however you might find some of the symptoms apply to other compression techniques), some are specific to Network Load balancing (NLB), and some are specific to IIS.
A few key things which can cause issues with WebResource.axd:
- Missing compression exclusion
- Slight error with compression module
- Missing MachineKey / ValidationKey
- Bad IIS setup, specifically the Application extension mapping
If you're lucky like I was, then you could have elements from all of the above in your environment. This makes for a lot of fun, especially given that the client errors can be somewhat intermittent. Unfortunately, I haven't managed to find much of a pattern to it. Some clients work, and some don't. You can break a working client, and you can fix a broken one, but it's kinda random. I know that's a fairly useless way to start out, but it gets better, I promise.
The first thing to do if you're having the JavaScript errors is to determine if they're being caused by a "missing" WebResource.axd. Simply view the source of the page which is breaking and find the js include line which references WebResource.axd. Copy the url, and paste it into your browser. You'll get a blank file loaded. Do this in a client which is working, and you'll get a file filled with JavaScript functions - funny that.
During my googling, I came across a few people who recommended simply getting the WebResource.axd from the cache of a working client, and copying it to the root of your application. I really don't advise this. On it's own, this didn't work for me anyway. My only thought is that these people intended you to update all the pages in your application and included a hardcoded reference to this file. Nasty. If you view the source of a lot of your pages, you'll notice that the include to WebResource.axd is made only on pages which need it. It's nice to let the .NET Framework decide these things rather than having to go through an entire application and work it out.
Compression
If you're running compression, you can confirm whether it's causing the problem by temporarily disabling it entirely. If you're using Blowery, then simply remove the httpmodule line in web.config (or web.configs if you're running in a load balanced environment), save, and test.
Disabling compression isn't really a great long term solution, so lets deal with this in a slightly more permanent way. First thing to do, is too add an exclusion for WebResource.axd in your web.config. If you're using blowery, it will look something like this:
<httpCompress preferredAlgorithm="deflate" compressionLevel="high">
<excludedMimeTypes>
<add type="image/jpeg"/>
<add type="image/gif"/>
</excludedMimeTypes>
<excludedPaths>
<add path="WebResource.axd"/>
</excludedPaths>
</httpCompress>
This is needed, however in my case it wasn't fixing all clients. It fixed some, but not all. After some frustrated googling and testing, I downloaded the latest version of Blowery (Blowery HttpCompress v6 for .net 2.0), and applied a small code change to line 85 of HttpCompress.cs:
From:string realPath = app.Request.Path.Remove(0, app.Request.ApplicationPath.Length+1);
To:string realPath = Path.GetFileName(app.Request.Path);
I found this code change via the DNN Forums: Http Compression and WebResource.axd.
Bad IIS Setup
If you're seeing 404 errors in your IIS logs (If you don't know where your application's logs are kept, then check Website Properties in IIS manager to find out. Clicking on 'Properties' next to the Enable Logging checkbox will bring up a dialog that will show you were the logs for this application are located.) then it's possible you need to make a change to your IIS config. From IIS Manager, select the properties for your application's website, and goto the 'Home Directory' tab. Click 'Configuration', then bring up the list of extension mappings on the 'Mappings' tab. You're obviously looking for .AXD, and if that's not there you need to create it. The important thing is to make sure "Verify File Exists" is deselected, as shown here:
If you have load balanced servers, then make sure you repeat this for all servers. Also you can probably do this at your top level website if you wanted to - the servers I was working on had a mix of ASP.NET 1.1 and 2.0 applications, so I tried to limit my changes to the end level website.
Network Load Balancing (NLB)
NLB is also known to cause issues with WebResource.axd. Even without thinking of clustering issues, it means you need to have your IIS setup properly twice. If you're having problems intermittently, then double check your config across both servers first and make sure they're identical. You can also hardcode an entry in your hosts file to specifically point to a single server in order to see if it works on one and not another. If you wanted to be incredibly drastic you could even break the NLB cluster, however I don't particularly recommend that option.
If your IIS setup is identical and you're still having issues, then check your MachineKey and ValidationKey nodes in your web.configs. They must be set to the same value on all nodes. If you're using something like SQL Session State, then this is probably going to be the case already. Here are a couple of useful links about MachineKey and ValidationKey:
Hopefully you'll find your symptoms and their solution in this article. If your problem turned out to be something different, please leave a comment or drop me a line so I can add your symptoms and solution here.
Update: If you're having AXD related problems with the SQL Server Report Viewer web control under Longhorn/IIS7, then this link might be of help to you.
