Just 4 months ago I posted about a weird bug with ASP.Net/IIS 6 around compiling in the UK and releasing to a different time zone. I got hit again by it again, after a customer release we discovered parts of the system werent working correctly, several controls weren’t styling or working correctly. It took almost an hour of diagnostics to remind myself of my original blog post, so I defiantly need to write a second post on the subject.
The problem is caused when you deploy to a timezone that’s behind you, i.e. you live in the UK and you are deploying to the USA, and it only effects iis6/server 2003 or below. When you have assemblies that return content from a webresource.xsd it will throw an exception when the dll timestamp is in the future.
You have a couple of ways to fix this:
- Don’t use old Servers/IIS6, can be tricky if you are maintaining older code, or restricted by server choice.
- Make sure you leave enough hours between compiling and deployment to make up for the time difference
- Make sure your server time/computer time is set at –12 timezone time
- After you deploy to a customer site, re-timestamp the dlls
The only sensible Option
So it appears the only sensible option is to re-timestamp the DLLs, you could do this on your CI server so this never happens (but telling your CI to compile and timestamp the dlls in the future may be tricky), or you could do it on the customer site after deployment when you hit the problem. The command to touch/re-timestamp dlls can be done from the command line. It involves copying the dlls over the top of themselves, and applying the correct timestamp when you do it. The command to do this is almost more crazy than the problem:
copy /b *.dll +,,
yeah…. you need the + and the two ,, for it to work, crazy problem, crazy solution