Home > .NET Framework > Embedded Web Resources related Javascript errors

Embedded Web Resources related Javascript errors

It is sort of a long rant, feel free to jump to the end if you want to read the findings alone.

We had been running into this issue for more than an year now. I have been postponing getting to the bottom of the issue because we found some solution which works. We did not know why. A healthy prod by my client forced me research on the issue further.

The problem: Javascripts from embedded resources within assemblies were not getting downloaded and we used to get errors like ‘YAHOO’ is undefined, ‘xyz..’ is undefined etc. Initially I was thinking that the assembly has gone corrupt during the file transfer and used to retransfer the assembly to the server. And it used to work. Sometimes even a retransfer of file doesn’t work. After that we tried using reflector on the so called ‘corrupt’ assembly, but it opened like a charm indicating the file hasn’t gone corrupt. We also used to zip the files and when we transfer the files without zipping things used to work.

We thought the problem was with the zipping tool used to create the zip file and tried different options but in vain. A uncompressed file transferred directly used to work where as a zipped file fails, even though it opens fine in reflector. After some frantic searching yesterday I found the real reason. Initially I was on a wild goose chase around the lines of “The not so mysterious problem around webresource.axd”. I also created a sample to simulate the issue, but it vain.

Today morning I ran into “Web Resources Troubleshooting” from the Telerik folks. After reading the article I realized I had seen the error earlier in one of the dev boxes due to the date being in the future. I created a small sample to reproduce the issue and bingo! But it did not answer the question how retransfer was fixing the issues. We always zip the files and transfer the website. When 1 or 2 odd dlls go missing we do not zip that during the transfer.

The source and destination machines were in different time zones / times. The following conditions had to be true to get a the exception.

  • If the assembly build time happens to be within the time difference
  • and you zip the assembly for transferring
  • and for unzipping you use Windows Explorer Compressed folder feature 

the issue will occur

I did some more research and found the following facts.

Findings: Different applications use different philosophies when it comes to handling datetime stamps (Date Created & Date Modified). I tried the following applications

  • Windows explorer copy & paste to destination folder (from an ftp site).
  • Internet explorer saving the file from a web site
  • Windows Explorer Compressed folder feature to extract files.
  • 7Zip Extract files feature

The Windows Explorer Compressed folder extract files uses the timestamp of the source machine as is where as the other scenarios the local machine’s timestamp was used (I am overly simplifying it, you can try this on your own).

You can use Fiddler / firebug to see if any webresource / scriptresource are not getting downloaded. Here is the original error.

"Specified argument was out of the range of valid values. Parameter name: utcDate"
The assembly containing the embedded resources is probably built in the future (its last modified time is later than the current time). This can occur when deploying in a different time zone. In such case run the following command line statement (the commas and plus at the end are important!):
copy /b <path to assembly which is built in the future>+,,”

A little reflectoring lead me to AssemblyResourceLoader.GetAssemblyInfoWithAssertInternal which was using File.GetLastWriteTime rather than GetLastWriteTimeUtc. Is this the cause for the exception? I didn’t look deep enough to figure that.

Advertisements
Categories: .NET Framework
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: