This was tricky to track down and hopefully the troubleshooting information will help you should you run into this type of error and can't track it down.
If using 3rd party ASP.Net controls, you may see errors similar to the following:
ASP.Net Error related to 3rd party control
Unable to find script library '/aspnet_client/basicframe_webcontrols_basicdatepicker/1_1_1959/bdplite.js'. Try placing this file manually by uploading the /aspnet_client directory to your web application root.
Typically the aspnet_client directory can be found at the following path:
Looking at the IIS logs will show that requests to these pages are serving correctly with a 304 or 200 response. Investigation of the .js file in the IE cache or network trace response will show you that there is additional text at the end of the .js files. For example, you have a .js file with the following:
alert('The JS File loaded');
However, in the netmon or IE cache, you see the following:
alert('The JS File loaded');
} <div>Confidential Information</div>
Check the IE cache to see if there is extra data appended to the .js file.
- Tools | Internet Options in IE
- General Tab | Settings button under Browsing History
- Click View Files
- Sort by Internet Address and find the URL to your site
- Do you see the .js file being requested? If so, open it in notepad and look for extra text at the end or any characters not in the original file on the server.
You can also use a tool that captures the network data (Netmon 3, Ethereal, Fiddler, Web Development Helper, HttpWatch, Firebug, etc). However, if IE is caching the page, you will see a request with the If-Modified-Since header coming from the client and the server will return a response with a 304 status code which will not contain the script. The If-Modified-Since header indicates the browser has the file in cache, and is asking the server if it has a newer copy. In order to avoid this behavior, you can force IE to always request the actual page instead of using cache. This way you can see the 200 response coming from the server with the contents of the .js file to see if anything extra is added to your script.
- Open IE
- From Tools menu, select Internet Options
- Click Settings under Browsing History (IE7)
- Click Every Time I Visit the Web Page, click OK
- Use network capture tool and browse the page.
In this particular scenario, the "Enable document footer" option in IIS was enabled on the folders serving the .js files. This option appends text to the end of any static documents served:
- Open IIS Manager
- Right-click the folder hosting the test pages, select Properties
- Click the Documents tab
- Uncheck "Enable document footer".
Anything in the pipeline could potentially cause this. Isapi filters, proxy servers, HttpModules/handlers(if .js is mapped to aspnet_isapi.dll), etc.