Deploying Asp.Net to a different time zone, Temporal Future Shock! Specified argument was out of the range of valid values. Parameter name: utcDate

by Jon 17. December 2010 09:57

You would have never of thought it but if you compile ASP.NET in a different timezone you could cause yourself some temporal problems.  I recently discovered that parts of ASP.NET are date specific and if you compile an ASP.NET application in one timezone (The UK), and deploy to another timezone (California) you may find that your web application won’t work correctly until the time catches up.  Its all to do with the date stamp in the assemblies, when you install your application onto a server in california the timestamps on the assembly files may be in the future and parts of the ASP.NET framework will refuse to load them.  Just by waiting 8 hours for time to catch up the problem will resolve itself!  Its defiantly worth saying this doesn’t effect all server setups I had no problems with a customer running server 2008 in a different timezone, I only came across this problem with an AJAX enabled system when a customer was running server 2003, but I haven’t had time to test different scenarios

I installed the application the AJAX was ‘working’ however nothing was styling correctly

I viewed the source of the page and started debugging by copying the WebResource.xsd url into different tab, I was surprised to see the following error:

Server Error in '/' Application.

Specified argument was out of the range of valid values.
Parameter name: utcDate

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: utcDate
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

I returned to the system after 8 hours and the site was working and the error was gone! Be careful out there, this was a fully patched server 2003!

Tags: , , , , , , ,

asp.net | Deploy | development | General | IIS | Maintanance | TechSupport | vs2010


500.19 Internal Server Error, There is a duplicate ‘system.web.extensions /scripting /scriptResourceHandler’

by Jon 29. October 2010 22:22

Http Error 500.19 There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’

After shipping your asp.net 2.0, 3.0 or 3.5 application to a new server you get the following error:

There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’

Don’t worry you haven’t done anything wrong, your are just trying to ship to a new server that has been configured to use .NET 4.0 as the default, and lucky for you it is a quick and simple configuration change to fix it:

Change Application Pool to .Net Framework v2.0

  • Open Internet Information Services (IIS) Manager
  • Goto the Application Pools screen
  • Open the Application Pool offending web application(s) are using
  • Change the Application Pool to use dotnet 2.0 instead of .net 4.0
  • Hard Refresh the erroring page with a <Ctrl> F5

Tags: , , , , , , , ,

asp.net | Deploy | IIS | TechSupport


Could not load file or assembly <AssemblyName> or one of its dependencies. An attempt was made to load a program with an incorrect format

by Jon 16. September 2010 22:00

One of the recurring problems I get when installing our ASP.Net system onto customers servers is this cryptic error:

Could not load file or assembly <AssemblyName> or one of its dependencies.  An attempt was made to load a program with an incorrect format


The first time I saw it it really stumped me for a couple of hours to find what the problem was, the stack trace, nothing made any sence.  I eventually tracked the only difference down to the server being 64bit.  IIS can run an asp.net application in either 64 or 32bit mode and most people leave both 32bit and 64bit support enabled when they compile there ASP.Net to automatically give them improved performance on a 64bit machine.  Unfortunatly if you are using a 3rd party componant that is older, perhaps an old non managed library it is more likely to be compiled for 32bit exclusivly.  This 3rd party library means your entire application wont be able to run in 32bit mode, and to make matters worse IIS running under 64bit has 32bit support disabled by default and your Compiled code will attempt to run in 64bits, which in turn causes the nasty error message above.

There are one of two solutions:

1. find the offending library and remove it from your Web Application

2. Enable 32bit support in IIS.  

a. Go to Application Pools in IIS
b. Right click on the relevant application pool
c. Press advanced settings
d. Set Enable 32-Bit Applications to True
e. Restart the Application Pool

This quick fix will buy you time so you can remove the offending library at your leisure

Tags: , , ,

asp.net | development | IIS | TechSupport

Powered by BlogEngine.NET
Original Design by Laptop Geek, Adapted by onesoft, and finally some tiny tweaks by JonAlb