asp.net utcDate 指定的参数已超出有效值的范围。求具体解决方法！
近日，将一asp.net项目转移到自己的本本上开发，在本本上(xp系统)安装iis,vs2008时系统的时间是错误，比当前时间超前三天，结果开发环境部署好了后，运行项目时出现以下的错误:

指定的参数已超出有效值的范围。
参数名: utcDate 
说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 

异常详细信息: System.ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。
参数名: utcDate

源错误: 

执行当前 Web 请求期间生成了未处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。  

堆栈跟踪: 

[ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。 参数名: 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  


--------------------------------------------
版本信息: Microsoft .NET Framework 版本:2.0.50727.1433; ASP.NET 版本:2.0.50727.1433 

网上搜索得到以下一篇文章：

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~关于“指定的参数已超出有效值的范围。参数名 utcDate”的解决方案 
很多朋友已经习惯了在组件或者页面开发时使用内嵌资源的方式进行资源输出，这样的好处包括如下一点，就是利用部分浏览器的相关机理来缓存这些文件而不必每次都加载，它们通常通过一个时间戳来表示该项内容是应该从缓存（客户端本地）中读取还是重新下载（远端服务器），而这个时间戳就被跟在了下载该资源的链接上了。

按说大家通常在测试的时候都是单机环境，因此通常不会发生什么问题，但是在生产环境中或者迁移到别人的机上就会出现一些问题了。

指定的参数已超出有效值的范围。
参数名: utcDate 
说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 

异常详细信息: System.ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。
参数名: utcDate

源错误: 

执行当前 Web 请求期间生成了未处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。  

堆栈跟踪: 

[ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。 参数名: 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  


--------------------------------------------
版本信息: Microsoft .NET Framework 版本:2.0.50727.1433; ASP.NET 版本:2.0.50727.1433 

因为通常这时候网页并不会加载错误，所以我们可以很明确的知道并不是页面生命周期内发生了异常。如果是脚本资源，通常我们打开IE的脚本调试功能会弹出对象无法初始化的错误以及一些脚本异常。如果是css文件则会出现样式丢失的现象。既然不是页面生命周期内发生了错误，我们没有理由去检查代码，特别是当代码曾一度辉煌，我们更没有理由去那么怀疑。这时候我们有理由想到托管我们代码的IIS，仔细观察提示我们应该对utcDate有一个比较深的印象。如果我们的资源是在未来创建的呢？oh，这不可能，但是当我们将系统的时间改成比资源文件的创建时间更早的时候就有理由相信这一切就成为可能了。

解决方案：

1、通过修改服务器系统时间，让其比Assembly的时间要晚，则可以了。（这适合于Assembly是别人创建的时候，当然也适合自己拥有源码的时候）。

2、通过修改Assembly的创建时间，让其早于服务器的时间，则可以了。（这适合于服务器是别人的，当然也适合于服务器是自己的情况）。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

阅读后貌似找到的问题的所在，但是不知道具体的解决方法，修复vs2008后问题依旧，请高手赐教！

------解决方案--------------------
检查你的程序，断点调试一下
------解决方案--------------------
因为通常这时候网页并不会加载错误，所以我们可以很明确的知道并不是页面生命周期内发生了异常。如果是脚本资源，通常我们打开IE的脚本调试功能会弹出对象无法初始化的错误以及一些脚本异常。如果是css文件则会出现样式丢失的现象。既然不是页面生命周期内发生了错误，我们没有理由去检查代码，特别是当代码曾一度辉煌，我们更没有理由去那么怀疑。这时候我们有理由想到托管我们代码的IIS，仔细观察提示我们应该对utcDate有一个比较深的印象。如果我们的资源是在未来创建的呢？oh，这不可能，但是当我们将系统的时间改成比资源文件的创建时间更早的时候就有理由相信这一切就成为可能了。

解决方案：

1、通过修改服务器系统时间，让其比Assembly的时间要晚，则可以了。（这适合于Assembly是别人创建的时候，当然也适合自己拥有源码的时候）。

2、通过修改Assembly的创建时间，让其早于服务器的时间，则可以了。（这适合于服务器是别人的，当然也适合于服务器是自己的情况）。


------解决方案--------------------
时间改正确之后，重新编译一次
------解决方案--------------------