升级到ASP.NET AJAX正式版之后,一般来说重新编译不会有什么问题,不用做什么修改,这是个好消息。不过在执行时就会出现问题了。因为在正式版的程序集中,删除了兼容UpdatePanel的Validator那些类,因此TagMapping时就无法找到需要的类了。如果您在您的项目中没有使用到那些Validator(确切地说,是没有在UpdatePanel中使用那些Validator),那么只要在web.config文件中删除下面的这个元素就可以了:
如果有朋友使用了这些兼容UpdatePanel的Validator,也不用着急,Matt Gibbs已经给出了解决方案。从他的文章里我们得知,那些兼容的Validator将通过Windows Update对于.NET Framework进行升级。虽然我不知道为什么要这么做,但是我们似乎只能这么接受。照目前来说,我们就要下载那些Validator,编译这个项目,并将所得的Validators.dll复制到网站的Bin目录下去。然后在web.config中configuration/system.web/pages节点中添加(或修改)如下的元素:
总的来说,正式发布的版本修改的地方还不是很大,移植起来应该还是比较轻松的(Control Toolkit还没有尝试过)。
Feedback
asp.net ajax以后有可能成为framework的一部分,这样做也是一件好事
@aspajax
其实我觉得……和现在相比有很大区别吗?
为什么在异步提交页面时会报这个错: pagerequestmanagerparsererrorexception
如果使用Validation控件可以更改这个控件的EnableClientScript=false。就可以使用了。
呵呵,老赵够快的!
我项目还没进行升级呢,迟点再升级成正式版,现在用的还是旧版本。
希望升级的过程不要那么痛苦!
@阿一
不可能那么快上Production的,只是移植试试看,呵呵。
具体还要再测试一下,我看了一些关键的代码,细节方面变了一些。功能上没有看出什么很多区别,不过Control Toolkit还是不清楚。:)
我也看到了那篇文章了,可是我就觉得奇怪了,既然Validator在UpdatePanel不能正常使用,而上一个版本中提供的方法不是很好吗?干嘛还要去掉呢?
@阿不
其实现在这个Validator的Solution就是从以前的版本剥离出来的。
据说现在要用Windows Update升级.NET Framework,不知道原因……
@阿不
Windows Update不一定是修补bug的,呵呵。
比如IE7,Media Player 11都是可以通过Windows Update进行更新的。
UpdateProgress没有UpdatePanle时的js Bug修复了吗?
@马哥
可以认为是“修复”了,现在只要EnablePartialRendering为true就一定会加载那个js,即使页面没有UpdatePanel和UpdateProgress,呵呵。
蛮保险的做法,但是也是需要注意的,让用户下载了多余的js就不好了。
@Jeffrey Zhao
UpdatePanel和UpdateProgress是用于轻量级的AJAX解决放案的,多下载js也就不是什么大问题了吧。
@Cat Chen
嗯……不过还是注意些好,毕竟一个MicrosoftAjaxWebForms.js的Release版本也有几十K,呵呵。
这个问题我想可以通过发起一个活动逐渐得到解决: 由某一个大家都信任的网站提供一个长期不会变化的IP指向大家搞得一个没什么价值的公用域名,然后包装一下js的输出,大家都取自同一地址。
其实很想给微软提这个建议,因为如果再加上分布在各大洲的服务器,对这个域名动态分配IP,加上AJAX带来的数据量传输的减少,对于使用微软技术的网站,应该能大大增加浏览器用户的体验。至于版本和过期问题的解决方案也都很成熟了...
应该是“IP上的地址被大家搞得一个没什么价值的公用域名所指向,然后包装一下JS引用地址字串的输出" :)
@Jeffrey Zhao
昨天晚上项目升级,正好涉及到了Validator问题,这篇文章给了我极大的帮助,非常感谢!
@怪怪
其实这个做法并不保险吧,无法保证在任何地方任何上网条件的人都能够访问。
还是使用网站本身来的保险,这样能够访问的网站的人就可以正确下载脚本了。
@TerryLee
我也是正好遇到,顺手写篇短文。:)
我在安装调试时, 异步把数据保存到数据库后, 在更新页面的时候出现如下提示:
有哪位朋友遇到这种提示没有?
@赵兄
为何照你的方法做了之后
运行提示:
配置错误
说明: 在处理向该请求提供服务所需的配置文件时出错。请检查下面的特定错误详细信息并适当地修改配置文件。
分析器错误信息: 未能从程序集“Validators”中加载类型“Microsoft.Web.UI.Compatibility.CompareValidator”。
行 39: <add tagType="System.Web.UI.WebControls.CompareValidator" mappedTagType="Microsoft.Web.UI.Compatibility.CompareValidator, Validators"/>
@freetofly
不会阿,这个做法很简单,没有什么特别的……
@Jeffrey Zhao
没有非法字符,数据都保存到数据库里了, 就是在更新的页面的时候提示这个错误!
@发哥
您在异步postback后作了哪些事情呢?
@赵兄
就是下来这个包,然后编译
之后把编译过的DLL放到BIN下
再把
<tagMapping>
<add tagType="System.Web.UI.WebControls.CompareValidator"
mappedTagType="Microsoft.Web.UI.Compatibility.CompareValidator, Validators"/>
<add tagType="System.Web.UI.WebControls.CustomValidator"
mappedTagType="Microsoft.Web.UI.Compatibility.CustomValidator, Validators"/>
<add tagType="System.Web.UI.WebControls.RangeValidator"
mappedTagType="Microsoft.Web.UI.Compatibility.RangeValidator, Validators"/>
<add tagType="System.Web.UI.WebControls.RegularExpressionValidator"
mappedTagType="Microsoft.Web.UI.Compatibility.RegularExpressionValidator, Validators"/>
<add tagType="System.Web.UI.WebControls.RequiredFieldValidator"
mappedTagType="Microsoft.Web.UI.Compatibility.RequiredFieldValidator, Validators"/>
<add tagType="System.Web.UI.WebControls.ValidationSummary"
mappedTagType="Microsoft.Web.UI.Compatibility.ValidationSummary, Validators"/>
</tagMapping>
加上,把原来的tagMapping删除掉
@freetofly
不清楚了……应该没有问题的阿……
@Jeffrey Zhao
正常的数据处理!没有做别的事情!
@发哥
能否作一个重现问题的小示例发到我的邮箱呢?
以前还真的不知道有个专门为UpdatePanel设计的Validator。
今天试着用了一下,终于达到了预期的效果,解决了困扰很多天的问题。
谢谢 Jeffrey Zhao
@赵兄
发现问题所在了
您提供的那个项目的的命名空间为Sample
而配置文件里的为Microsoft
统一一下就OK了
嘿嘿
还有个小问题啊
当提页面提交后/如何把提交按钮变为不可用呢?如果用客户端脚本,那验证一但不通过,那就OVER了。
如果在服务器端执行完方法后写上Btn_Save.Enable = false;这时如果服务器端执行时间比较长,那这个基本上就不怎么起作用。
不会非要在服务器端开多线程吧
@freetofly
阿哦……我这倒没有注意。
您可以使用JS,把按钮的disabled设为false
@赵兄
使用客户端脚本如果有验证控件呢?
验证失败了呢?
@freetofly
那么就不会出现PostBack了。
@freetofly
才发现,一定是ASP.NET AJAX的人突然改掉了,我用的时候还是Microsoft.XXX,呵呵。
老赵,我的也出现了这个问题,用你的方法编译过去了,但是好像UpdatePanel不工作了,还是回传给服务器了。。。
奇怪
还有其他地方需要注意么?
@数据绑定者
没有啊,UpdatePanel工作的好好的。
@Jeffrey Zhao
什么人都能访问没问题啊,只有公用的库才会用同一套地址,不给大家修改和覆盖的权限就行了。每个人自己的库当然不会往第三方主机上放,倒不是因为安全,输出到浏览器的就是给别人白看的,主要是对别人不见得有用,反而白占一个URI。
存在的问题就是万一有这台服务器控制权的人决定把大家都给瘫痪了怎么办,这样就应该有不止一台的服务器,如果服务器A失效或文件被改动,就把地址换为其它的服务器。但还是有个万一,即用户A下载了伪装的JS,Cache了,然后如何验证,解决了这个问题我想就不存在任何问题了。不过估计难度较高所以说,微软做这个事最好..
P.S. 这两天长来你这里逛,就等着你的AJAX文章的后续呢 :)
@怪怪
您是说ScriptManager的OnResolveScriptReference事件的作用吧?
其实我的意思就是说,只有自己host的脚本才是保证能够访问的,别的都可能瘫痪之类的。虽然可能比如微软,利用优秀的fail over机制可以避免瘫痪,但是还有网络问题呢,比如有些拨号如果只能上国内呢?还有……台湾的地震呢?呵呵。所以共有的script链接感觉无甚大用,怎么做都不够保险。
P.S. 多谢捧场。:)
象Google那样的分布式就好了吗 :),况且可以所有共享JS库都不能用的话,就由自己的主机发送。其实我想这个,就是怕那些慢速网络或者未来Atlas的包功能进一步扩充,加上图片等资源最终变得比Flash还大。因为如果带宽足够,就你这几天这几篇文章的解决方法合理利用,已经帮大家铲平了很好的道路了。
园子里厉害的人很多,不过我在你这里驻留的时间最多 :),深度和实用性都足够好,不怕大家不捧场~
@怪怪
可能可行,不过还要在技术上进行思考,比如怎么做可以“所有共享JS库都不能用的话,就由自己的主机发送”。
不过的确可以作为一个发展方向。:)
太兴奋了。。就是因为验证这问题让我调试了大半天一直没找到问题。。晚上回来从BAIDU搜索到此文章。。呵呵。。现在问题解决了。。兴奋啊。。
太无私了!
好在查到了,不然光这个问题,我就不想升级或研究AJAX了。
我为了解决这个问题,只好在最后放个ValidationSummary,然后设置ShowMessageBox="True".这样的话,出来的alert的确很不好看.现在终于看到了很好的解决方法.谢谢老赵!!
赵兄
这个方案一月份就提出了
为什么到现在都没有看到微软官方的hotfix出来呢
请问就只有这个解决方案了吗?
请问现在这个补丁出来了吗?我也是找了很久没找到啊?如果现在用这种暂时的解决办法,以后补丁出来了还要再更新一遍验证控件啊 那岂不是很麻烦?