"The specified parameter has exceeded the valid value range. Utcdate Solution

Many of my friends are used to using embedded resources for resource output during component or page development. These benefits include, it is to cache these files by using the relevant mechanisms of Some browsers instead of loading them every time. They usually use a timestamp to indicate that the content should be cached (locally on the client) and the timestamp is followed by the link to download the resource.

Generally, users are in a standalone environment during testing, so there is usually no problem, but there will be some problems in the production environment or migrated to another machine.

The specified parameter has exceeded the valid value range.
Parameter Name: utcdate

Note:An error occurred while executing the current Web request. Check the stack trace information to learn about this error andCodeDetailed information about the cause of the error.

Exception details:System. argumentoutofrangeexception: the specified parameter has exceeded the valid value range.
Parameter Name: utcdate

Source error:

An unhandled exception is generated during the execution of the current Web request. You can use the following exception stack trace information to determine the cause and location of the exception.

Stack trace:

[Argumentoutofrangeexception: the specified parameter has exceeded the valid value range. Parameter Name: utcdate] system. web. httpcachepolicy. utcsetlastmodified (datetime utcdate) + 3352419 system. web. httpcachepolicy. setlastmodified (datetime date) + 47 system. web. handlers. assemblyresourceloader. system. web. ihttphandler. processrequest (httpcontext context) + 1904 system. web. callhandlerexecutionstep. system. web. httpapplication. iexecutionstep. execute () + 358 system. web. httpapplication. executestep (iexecutionstep step, Boolean & completedsynchronously) + 64

Version: Microsoft. NET Framework Version: 2.0.50727.1433; ASP. NET version: 2.0.50727.1433

Because the webpage does not load errors at this time, we can clearly understand that there is no exception in the page lifecycle. If it is a script resource, we usually enable the script debugging function of IE to bring up the error that the object cannot be initialized and some script exceptions. If it is a CSS file, the style will be lost. Since there is no error in the page lifecycle, we have no reason to check the Code, especially when the Code was once brilliant, we have no reason to doubt it. At this time, we have reason to think of the IIS hosting our code, and carefully observe the prompts that we should have a deep impression on utcdate. What if our resources are created in the future? Oh, this is not possible, but when we change the system time to a time earlier than the resource file creation time, we have reason to believe that this is all possible.

Solution:

1. You can modify the server system time to make it later than the assembly time. (This is suitable for assembly when others create it, and of course it is also suitable for their own source code ).

2. Modify the Assembly creation time so that it is earlier than the server time. (This is suitable for servers that are owned by others, and of course the server itself ).