为便于将WebGIS应用系统方便的部署在笔记本上做演示用，特意制作了一个虚拟机服务器环境，需要时只要把虚拟机vhd,vmc文件（Virtual PC 2007）拷贝到目标机器，安装虚拟机程序即可，省去了部署GIS服务器、WEB服务器、数据库等一系列软件，非常方便快捷。此方法一经试用用，备受欢迎，已多次在用于在笔记上部署复杂应用系统。
近日将一配置好的Web应用程序以服务器虚拟机形式部署在一台笔记本上，罕见的遇到问题。部署好后，在本上访问，IE7.0连爆三个脚本错误：
1、Asp.net ajax客户端框架未能加载
2、‘Sys’未定义
3、‘Sys’未定义（但不在同一行）
试验：
1、用另外机器的ie、ff、ietester等访问均存在问题；
2、将同一虚拟机部署在其他数台计算机上均未发现此问题（此前已在数台笔记本上跑过，未发现问题）；
3、经Baidu、Google后，试验了：改webconfig，关防火墙、关杀毒、配置ie安全选项，设置iis身份认证等均未解决问题。
经以上试验，采用排除法，可以排除不是虚拟机的问题、不是浏览器问题，只可能是笔记本环境的问题。
而笔记本是新的X200，正版XP系统，之前在同样环境机器上部署过几次都未发下问题。
崩溃之际，只有打算用一个正常情况下的机器的XP系统Ghost笔记本的系统。
最后时刻再次查看出错网页源码，将类似“<script src="/ScriptResource.axd?d=jNIytBNJCfUTy70eBg_LNlQ9wgtGeS579E4Uf__GgQPICXHl8yDxXLmmzSKUxulSOHo4joq_PpUDjHshbgRnkSDrwSc-SLcpSHxCVi8jHMo1&t=ffffffffdcd72ae2" type="text/javascript"></script>”
语句放在IE中执行，收到如下错误：
指定的参数已超出有效值的范围。 参数名: 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
再次将“HttpCachePolicy.UtcSetLastModified”作为关键字Google到这篇篇帖子“asp.net utcDate 指定的参数已超出有效值的范围。求具体解决方法！"http://topic.csdn.net/u/20090305/12/abfaf0b3-e0ad-46f7-b64c-a9df9d336ec5.html
其中关键一段如下：
因为通常这时候网页并不会加载错误，所以我们可以很明确的知道并不是页面生命周期内发生了异常。如果是脚本资源，通常我们打开IE的脚本调试功能会弹出对象无法初始化的错误以及一些脚本异常。如果是css文件则会出现样式丢失的现象。既然不是页面生命周期内发生了错误，我们没有理由去检查代码，特别是当代码曾一度辉煌，我们更没有理由去那么怀疑。这时候我们有理由想到托管我们代码的IIS，仔细观察提示我们应该对utcDate有一个比较深的印象。如果我们的资源是在未来创建的呢？oh，这不可能，但是当我们将系统的时间改成比资源文件的创建时间更早的时候就有理由相信这一切就成为可能了。 解决方案： 1、通过修改服务器系统时间，让其比Assembly的时间要晚，则可以了。（这适合于Assembly是别人创建的时候，当然也适合自己拥有源码的时候）。 2、通过修改Assembly的创建时间，让其早于服务器的时间，则可以了。（这适合于服务器是别人的，当然也适合于服务器是自己的情况）。
赶快查看笔记本系统时间，晕倒！竟然是2006年7月1日，今天的正确日期是2010年7月27日啊。不知道谁改的，害我晚上加班，找到他打屁股。
改了时间，一切复归正常。
总结原因，就和上边引用的一样：客户端Assembly缓存机制依赖Assembly时间戳，实践中务必保证服务器当前时间大于所依赖类库的创建时间。
参考资料：
1、http://topic.csdn.net/u/20090305/12/abfaf0b3-e0ad-46f7-b64c-a9df9d336ec5.html
2、http://blog.csdn.net/lvzhqi/archive/2009/03/02/3949459.aspx