SmtpClient 身份验证失败的原因分析
最近几日做的一个软件,需要利用邮箱的SMTP服务,发送邮件。但是用SmtpClient时,出现了身份验证失败的问题。
用outlook express测试后,可以正常发送。看来原因还是出在SmtpClient中。
由于机器原因,抓包很费劲,也就不自己找原因了,直接上网搜索,找到一篇文章(地址),内含抓包情况,查看后的结论,是由于协议问题,看来用SmtpClient是无法正常发送了。
想想,还有个web.mail可以发送邮件,一会试试去。
最近几日做的一个软件,需要利用邮箱的SMTP服务,发送邮件。但是用SmtpClient时,出现了身份验证失败的问题。
用outlook express测试后,可以正常发送。看来原因还是出在SmtpClient中。
由于机器原因,抓包很费劲,也就不自己找原因了,直接上网搜索,找到一篇文章(地址),内含抓包情况,查看后的结论,是由于协议问题,看来用SmtpClient是无法正常发送了。
想想,还有个web.mail可以发送邮件,一会试试去。
也许你用过一些“所见即所得”网页编辑器来进行网站的设计开发,但是却无法保证网站的访问者“所得即你所见”。那么你需要深入测试你的网站以确保访问者有一个良好的体验,不至于看都不想看就把它关掉。这里推荐了几种有用的工具来测试你的网站(网页)。
Browsershots
Browsershots提供了为你测试网页的在线服务,能够在不同的操作系统和不同的浏览器之中自动的捕获你的网站的截屏。你也可以选择是否在这些环境预览网页中的Flash,Java程序和JavaScript。
Browsershots现在是如此受欢迎以至于你在使用他们的截屏服务时不得不等待好几分钟的时间才能看到结果。

IE NetRenderer
IE NetRenderer是另一种工具,虽然速度比Browsershots快很多,但是只支持Internet Explorer的几种版本。基于Mac OS设计的网站则可以选择BrowsrCamp来测试,和Browsershots类似,但是只支持MAC OS的浏览器。
想看看你的网站在移动设备(BlackBerry or Windows Mobile)的小屏幕上是什么效果?Ok,让我们试试BrowserCam.另外一个比较好的选择是Opera Simulator,它可以让你在桌面上体验到Opera的Mobile版本。
相关信息: 使用 Opera Simulator 来解决网站受限的问题
一些上网者仍然在用很慢很原始的拨号上网,在发展中国家这些人群仍不在少数,且不容忽视。所以我们在设计网站时,要权衡考虑大多人网速的问题,不要滥用Javascript广告, 图形, CSS, Flash 动画这些元素让你的网站变得越来越慢哦。

Pingdom 是一种能够模拟网页如何被浏览器载入的工具。它能够显示一些动态数据(文件大小,载入时间)等等所有有可能导致你的网站变慢的因素。

其他的工具:
FireBug: 为Firefox设计,能显示让网站变慢的元素。

Print CSS:模拟PDF和打印效果。
1、在URL中中文字符通常出现在以下两个地方:
(1)、Query String中的参数值,比如http://search.china.alibaba.com/search/offer_search.htm?keywords=中国
(2)、servlet path,比如:http://search.china.alibaba.com/selloffer/中国.html
2、出现乱码问题的原因主要是以下几方面:
(1)、浏览器:我们的客户端(浏览器)本身并没有遵循URI编码的规范(http://www.w3.org/International/O-URL-code.html)。
(2)、Servlet服务器:Servlet服务器的没有正确配置。
(3)、开发人员并不了解Servlet的规范和API的含义。
二、基础知识:
1、一个http请求经过的几个环节:
浏览器(ie firefox)【get/post】------------>Servlet服务器------------------------------->浏览器显示
编码 解码成unicode,然后将显示的内容编码 解码
(1) 浏览器把URL(以及post提交的内容)经过编码后发送给服务器。
(2) 这里的Servlet服务器实际上指的是由Servlet服务器提供的servlet实现ServletRequestWrapper,不同应用服务器的servlet实现不同,这些servlet的实现把这些内容解码转换为unicode,处理完毕后,然后再把结果(即网页)编码返回给浏览器。
(3) 浏览器按照指定的编码显示该网页。
当对字符串进行编码和解码的时候都涉及到字符集,通常使用的字符集为ISO8859-1、GBK、UTF-8、UNICODE。
2、URL的组成:
域名:端口/contextPath/servletPath/pathInfo?queryString
说明:
1、ContextPath是在Servlet服务器的配置文件中指定的。
对于weblogic:
contextPath是在应用的weblogic.xml中配置。
<context-root>/</context-root>
对于tomcat:
contextPath是在server.xml中配置。
<Context path="/" docBase="D:/server/blog.war" debug="5" reloadable="true" crossContext="true"/>
对于jboos:
contextPath是在应用的jboss-web.xml中配置。
<jboss-web>
<context-root>/</context-root>
</jboss-web>
2、ServletPath是在应用的web.xml中配置。
<servlet-mapping>
<servlet-name>Example</servlet-name>
<url-pattern>/example/*</url-pattern>
</servlet-mapping>
2、Servlet API
我们使用以下servlet API获得URL的值及参数。
request.getParameter("name"); // 获得queryString的参数值(来自于get和post),其值经过Servlet服务器URL Decode过的
request.getPathInfo(); // 注意:pathinfo返回的字符串是经过Servlet服务器URL Decode过的。
requestURI = request.getRequestURI(); // 内容为:contextPath/servletPath/pathinfo 浏览器提交过来的原始数据,未被Servlet服务器URL Decode过。
3、开发人员必须清楚的servlet规范:
(1) HttpServletRequest.setCharacterEncoding()方法 仅仅只适用于设置post提交的request body的编码而不是设置get方法提交的queryString的编码。该方法告诉应用服务器应该采用什么编码解析post传过来的内容。很多文章并没有说明这一点。
(2) HttpServletRequest.getPathInfo()返回的结果是由Servlet服务器解码(decode)过的。
(3) HttpServletRequest.getRequestURI()返回的字符串没有被Servlet服务器decoded过。
(4) POST提交的数据是作为request body的一部分。
(5) 网页的Http头中ContentType("text/html; charset=GBK")的作用:
(a) 告诉浏览器网页中数据是什么编码;
(b) 表单提交时,通常浏览器会根据ContentType指定的charset对表单中的数据编码,然后发送给服务器的。
这里需要注意的是:这里所说的ContentType是指http头的ContentType,而不是在网页中meta中的ContentType。
三、下面我们分别从浏览器和应用服务器来举例说明:
URL:http://localhost:8080/example/中国?name=中国
汉字 编码 二进制表示
中国 UTF-8 0xe4 0xb8 0xad 0xe5 0x9b 0xbd[-28, -72, -83, -27, -101, -67]
中国 GBK 0xd6 0xd0 0xb9 0xfa[-42, -48, -71, -6]
中国 ISO8859-1 0x3f,0x3f[63, 63]信息失去
(一)、浏览器
1、GET方式提交,浏览器会对URL进行URL encode,然后发送给服务器。
(1) 对于中文IE,如果在高级选项中选中总以UTF-8发送(默认方式),则PathInfo是URL Encode是按照UTF-8编码,QueryString是按照GBK编码。
http://localhost:8080/example/中国?name=中国
实际上提交是:
GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA
(1) 对于中文IE,如果在高级选项中取消总以UTF-8发送,则PathInfo和QueryString是URL encode按照GBK编码。
实际上提交是:
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
(3) 对于中文firefox,则pathInfo和queryString都是URL encode按照GBK编码。
实际上提交是:
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
很显然,不同的浏览器以及同一浏览器的不同设置,会影响最终URL中PathInfo的编码。对于中文的IE和FIREFOX都是采用GBK编码QueryString。
小结:解决方案:
1、URL中如果含有中文等非ASCII字符,则浏览器会对它们进行URLEncode。为了避免浏览器采用了我们不希望的编码,所以最好不要在URL中直接使用非ASCII字符,而采用URL Encode编码过的字符串%.
比如:
URL:http://localhost:8080/example/中国?name=中国
建议:
URL:http://localhost:8080/example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
2、我们建议URL中PathInfo和QueryString采用相同的编码,这样对服务器端处理的时候会更加简单。
2、还有一个问题,我发现很多程序员并不明白URL Encode是需要指定字符集的。不明白的人可以看看这篇文档:http://gceclub.sun.com.cn/Java_Docs/html/zh_CN/api/java/net/URLEncoder.html
2、 POST提交
对于POST方式,表单中的参数值对是通过request body发送给服务器,此时浏览器会根据网页的ContentType("text/html; charset=GBK")中指定的编码进行对表单中的数据进行编码,然后发给服务器。
在服务器端的程序中我们可以通过Request.setCharacterEncoding() 设置编码,然后通过request.getParameter获得正确的数据。
解决方案:
1、从最简单,所需代价最小来看,我们对URL以及网页中的编码使用统一的编码对我们来说是比较合适的。
如果不使用统一编码的话,我们就需要在程序中做一些编码转换的事情。这也是我们为什么看到有网络上大量的资料介绍如何对乱码进行处理,其中很多解决方案都只是一时的权宜之计,没有从根本上解决问题。
(二)、Servlet服务器
Servlet服务器实现的Servlet遇到URL和POST提交的数据中含有%的字符串,它会按照指定的字符集解码。下面两个Servlet方法返回的结果都是经过解码的:
request.getParameter("name");
request.getPathInfo();
这里所说的"指定的字符集"是在应用服务器的配置文件中配置。
(1) tomcat服务器
对于tomcat服务器,该文件是server.xml
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="150" connectionTimeout="20000"
redirectPort="8443" URIEncoding="GBK"/>
URIEncoding告诉服务器servlet解码URL时采用的编码。
<Connector port="8080" ... useBodyEncodingForURI="true" />
useBodyEncodingForURI告诉服务器解码URL时候需要采用request body指定的编码。
(2) weblogic服务器
对于weblogic服务器,该文件是weblogic.xml
<input-charset>
<java-charset-name>GBK</java-charset-name>
</input-charset>
(三)浏览器显示
浏览器根据http头中的ContentType("text/html; charset=GBK"),指定的字符集来解码服务器发送过来的字节流。我们可以调用HttpServletResponse.setContentType()设置http头的ContentType。
总结:
1、URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的,我们的程序不能设置,不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集。
所以我们建议URL中不要使用中文等非ASCII字符,如果含有非ASCII字符的话要使用URLEncode编码一下,比如:
http://localhost:8080/example1/example/中国
正确的写法:
http://localhost:8080/example1/example/%E4%B8%AD%E5%9B%BD
并且我们建议URL中不要在PathInfo和QueryString同时使用非ASCII字符,比如
http://localhost:8080/example1/example/中国?name=中国
原因很简单:不同浏览器对URL中PathInfo和QueryString编码时采用的字符集不同,但应用服务器对URL通常会采用相同的字符集来解码。
2、我们建议URL中的URL Encode编码的字符集和网页的contentType的字符集采用相同的字符集,这样程序的实现就很简单,不用做复杂的编码转换。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/yzhz/archive/2007/07/03/1676796.aspx
post与get的区别
最近一直看qq的协议,发现post和get真的是很重要。而且可以搞很高深的东西,但如果你不了解这两个东西的话,有的时候是很麻烦的。
表单提交中Get和Post方式的区别有5点
1. get是从服务器上获取数据,post是向服务器传送数据。
2.get是把参数数据队列加到提交表单的ACTION属性所指的URL中,值和表单内各个字段一一对应,在URL中可以看到。post是通过HTTPpost机制,将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
3. 对于get方式,服务器端用Request.QueryString获取变量的值,对于post方式,服务器端用Request.Form获取提交的数据。
4. get传送的数据量较小,不能大于2KB。post传送的数据量较大,一般被默认为不受限制。但理论上,IIS4中最大量为80KB,IIS5中为100KB。
5. get安全性非常低,post安全性较高。
HTTP请求:GET与POST方法的区别
HTTP 定义了与服务器交互的不同方法,最基本的方法是 GET 和 POST。事实上 GET 适用于多数请求,而保留 POST仅用于更新站点。根据 HTTP 规范,GET 用于信息获取,而且应该是安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。换句话说,GET 请求一般不应产生副作用。幂等的意味着对同一 URL的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。从根本上讲,其目标是当用户打开一个链接时,她可以确信从自身的角度来看没有改变资源。比如,新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻,该操作仍然被认为是安全的和幂等的,因为它总是返回当前的新闻。反之亦然。 POST请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例,读者对文章的注解应该通过 POST请求实现,因为在注解提交之后站点已经不同了(比方说文章下面出现一条注解);
在FORM提交的时候,如果不指定Method,则默认为GET请求,Form中提交的数据将会附加在url之后,以?分开与url分开。字母数字字符原样发送,但空格转换为“+“号,其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII(或ISOLatin-1)值。GET请求请提交的数据放置在HTTP请求协议头中,而POST提交的数据则放在实体数据中;
GET方式提交的数据最多只能有1024字节,而POST则没有此限制。
在表单里使用”post”和”get”有什么区别
在Form里面,可以使用post也可以使用get。它们都是method的合法取值。但是,post和get方法在使用上至少有两点不同:
1、Get方法通过URL请求来传递用户的输入。Post方法通过另外的形式。
2、Get方式的提交你需要用Request.QueryString来取得变量的值,而Post方式提交时,你必须通过Request.Form来访问提交的内容。
仔细研究下面的代码。你可以运行之来感受一下:
代码
<!--两个Form只有Method属性不同-->
<FORM ACTION=“getpost.asp” METHOD=“get”>
<INPUT TYPE=“text” VALUE=“Hello World”></INPUT>
<INPUT TYPE=“submit” VALUE=“Method=Get”></INPUT>
</FORM>
<BR>
<FORM ACTION=“getpost.asp” METHOD=“post”>
<INPUT TYPE=“text” VALUE=“Hello World”></INPUT>
<INPUT TYPE=“submit” VALUE=“Method=Post”></INPUT>
</FORM>
<BR>
<BR>
<% If Request.QueryString(“Text”) <> ““ Then %>
通过get方法传递来的字符串是: “<B><%= Request.QueryString(“Text”) %></B>“<BR>
<% End If %>
<% If Request.Form(“Text”) <> ““ Then %>
通过Post方法传递来的字符串是: “<B><%= Request.Form(“Text”) %></B>“<BR>
<% End If %>
说明
把上面的代码保存为getpost.asp,然后运行,首先测试post方法,这时候,浏览器的url并没有什么变化,返回的结果是:
通过Post方法传递来的字符串是: "Hello World"
然后测试用get方法提交,请注意,浏览器的url变成了:
http://localhost/general/form/getpost.asp?Text=Hello+World
而返回的结果是:
通过get方法传递来的字符串是: "Hello World"
最后再通过post方法提交,浏览器的url还是:
http://localhost/general/form/getpost.asp?Text=Hello+World
而返回的结果变成:
通过get方法传递来的字符串是: "Hello World"
通过Post方法传递来的字符串是: "Hello World"
提示
通过get方法提交数据,可能会带来安全性的问题。比如一个登陆页面。当通过get方法提交数据时,用户名和密码将出现在URL上。如果:
1、 登陆页面可以被浏览器缓存;
2、 其他人可以访问客户的这台机器。
那么,别人即可以从浏览器的历史记录中,读取到此客户的账号和密码。所以,在某些情况下,get方法会带来严重的安全性问题。
建议
在Form中,建议使用post方法。
get与post的区别2
Get:是以实体的方式得到由请求URI所指定资源的信息,如果请求URI只是一个数据产生过程,那么最终要在响应实体中返回的是处理过程的结果所指向的资源,而不是处理过程的描述。
Post:用来向目的服务器发出请求,要求它接受被附在请求后的实体,并把它当作请求队列中请求URI所指定资源的附加新子项,Post被设计成用统一的方法实现下列功能:
1:对现有资源的解释
2:向电子公告栏、新闻组、邮件列表或类似讨论组发信息。
3:提交数据块
4:通过附加操作来扩展数据库
从上面描述可以看出,Get是向服务器发索取数据的一种请求;而Post是向服务器提交数据的一种请求,要提交的数据位于信息头后面的实体中。
很理论化,但是很标准,method=“get”并不是从服务器上获取数据,get和post 只是发送机制不同,并不是一个取一个发!
get方法会在IE地址栏里显示表示你提交时候所带的值;post方法不会
<form method="get" action="a.asp?b=b">跟<form method="get"action="a.asp">是一样的,也就是说,action页面后边带的参数列表会被忽视;而< formmethod="post" action="a.asp?b=b">跟<form method="post"action="a.asp">是不一样的。
另外,Get请求有如下特性:它会将数据添加到URL中,通过这种方式传递到服务器,通常利用一个问号?代表URL地址的结尾与数据参数的开端,后面的参数每一个数据参数以“名称=值”的形式出现,参数与参数之间利用一个连接符&来区分。
Post请求有如下特性:数据是放在HTTP主体中的,其组织方式不只一种,有&连接方式,也有分割符方式,可隐藏参数,传递大批数据,比较方便。
post 地址栏不会出现一大串?bjnghfgreygt这样的东西
如果是get,就会出现了
1、Get 方法通过 URL 请求来传递用户的数据,将表单内各字段名称与其内容,以成对的字符串连接,置于 action 属性所指程序的 url后,如http://www.mdm.com/test.asp?name=asd&password=sad,数据都会直接显示在 url 上,就像用户点击一个链接一样;Post 方法通过 HTTP post 机制,将表单内各字段名称与其内容放置在 HTML表头(header)内一起传送给服务器端交由 action属性能所指的程序处理,该程序会通过标准输入(stdin)方式,将表单的数据读出并加以处理(2、3删除了)
4、 Get 方式提交数据,会带来安全问题,比如一个登陆页面,通过 Get 方式提交数据时,用户名和密码将出现在 URL上,如果页面可以被缓存或者其他人可以访问客户这台机器,就可以从历史记录获得该用户的帐号和密码,所以表单提交建议使用 Post 方法;Post方法提交的表单页面常见的问题是,该页面如果刷新的时候,会弹出一个对话框
Google,每天的IT新闻里总会出现至少一次Google这个词语,好像没有了Google,互联网就失去了一个支柱。Google是可能吧里文章最多的一个tag,因为无论我们在互联网上干什么,我们几乎都离不开Google。当然,Google的每个服务都能找到替代品,为什么要选择Google的?为什么有那么多人愿意免费为Google写“软文”(实际上并不是软文,可能是个人体会)?
下面是我使用Google服务的一些情况:
1、打开电脑,我首先打开Gmail检查邮件。
2、然后我打开Google Reader,开始漫长的阅读战,信息过载从这时开始。
3、在看Reader期间,我会打开Gtalk,看看有没有人要找我或我要不要找某人。
4、当在阅读器里遇到某些不理解的东西,又或者一些想更详尽了解的信息,我会使用Google搜索。
5、博客每篇文章都要插图,因此每次我都要用Google图片搜索。
6、每天我都用Google博客搜索来关注某些方面的最新动态。
7、当我想了解一些书籍的内容时,我使用Google图书搜索。
8、有时会用Google财经看看某些股票的走势。
9、我用Google生活搜索买到了一张预定不到的火车票。
10、我在Google地图搜索来查看两地行车距离。
11、我使用Google Earth来“环游”世界,看世界奇观。

12、遇到非中文的网页,我会使用Google翻译来将其翻译成中文,即便其翻译质量较差,但总比看完全不懂的语言要好。
13、我利用Google Apps来获得最个性化的邮箱名。
14、我利用Google文件来创建文档和幻灯片,以及调查表。
15、我将图片存放到Google Picasa相册里,与朋友分享。
16、有时我用Google趋势来查看关键词搜索趋势。
17、我在博客上摆放Google的Adsense广告。
18、我使用Google Adwords在其它网站投放广告。
19、我使用Google Analytics来查看网站流量情况。
20、Google Groups里有不少我几天看一次的论坛。
21、我使用关键词订阅Google资讯的内容。
22、由于浏览器的书签无法在线保存,于是我使用Google的在线书签。
23、每隔一段时间,我需要打开Google网站管理员工具来查看Google抓取我的博客的情况。
24、我用Website Optimizer来做网站优化实验。
25、我利用Google Co-op来搭建属于自己的站内搜索。
26、我利用Google日历来作行事历,做公开日历和奥运赛程表。
27、Google提供很多API服务,这些服务都是很优秀的,例如Google AJAX Feed API。
28、有时我会用code search来搜索wordpress的一些代码。
29、现在,我还可以使用谷歌音乐来在线听歌。
30、我在Google Youtube上看视频。
...还有很多很多。
我对Google的依赖是非常严重的,一天花在Google所有服务的时间可能占我上网时间的80%以上。如果有一天Google倒闭了,我必须得一个一个地去寻找替代品。而这个过程可能是反复和持久的。
为什么选择使用Google的服务?
1、Google搜索最为优秀。
首先,这是很主观的,因为我在使用过程中发现只有Google才明白我的搜索意图,只有用Google,我才会被人误认为是高手。但事实上在盲测里也能看到这样的事实。

既然如此,为什么在中国百度的份额还是比Google高?原因就不需我再作说明了,很多blogger都已经阐述过。
2、我不相信国内服务的隐私保护。
是的,我担心。我怕我的QQ聊天记录被偷看,我怕我的隐私被揭露。不是说我崇洋媚外,如果国内网站有明确规定:“不管什么情况,我们打死都不会监视你的聊天内容,也不会向第三方(包括但不限于官方)泄露你的隐私。”我肯定会支持国内的服务。
3、安全
4、浏览体验好
Google的服务界面布局通常都是比较端庄清新的,使用起来体验非常良好。
5、没有诱惑性广告
在中国上网,谁没见过那些诱惑点击的广告?
6、分享的精神
分享是Web2.0的精神。Google的开放API是最多的,而且大多数你在使用过程中都不需要标明基于Google。这是一种无私共享的精神。
这一分享的精神也可以在Gmail里看出,没封邮件都可以无条件转发到其它邮箱。试问其它哪个邮箱服务可以做到这一点?
7、Gmail确实好用
Gmail是我用过最好的邮箱系统,怎么个好法?用过都知道。当然,即使用过或许你未必做到这8件关于Gmail的事。
8、多种服务都提供RSS输出
Google资讯、博客搜索、Gmail等都提供RSS输出,这为我们将信息统一到一个平台提供了便利的条件。
9、免费
很多其它提供商需要收费提供的服务,Google都将其变成免费。比如Analytics、网站管理员工具(在Google之前,提交多个URL到Yahoo!等搜索引擎是需要收费的)等等。
谁不喜欢免费?
10、依赖
当你使用某些Google服务时,你可能会由于依赖于这个服务而试用另一个相关的服务,从而进入恶性循环。
Google不是神
似乎上文将Google神化了,它不是神,但互联网上没有比它更大度的公司。
一个形象好、大度、开放的公司,必定受人所赞扬、推崇。这些方面Google的口碑是非常好的,所以很多人愿意免费给Google写推荐性文章。
依赖于Google可以是危险的
这主要有两方面的原因:
1、Google的服务很容易被和谐,稳定性受某第三方影响严重。在只许看图不许联想(2)里已经将这个问题说得很清楚了。
2、过分依赖于同一个人(企业)永远不是好事,当这个依赖对象失去后,你需要很长时间的去寻找替代品。
我知道,肯定有人会在下面骂我,肯定会有人说这是枪文,好吧,你喜欢怎么想就怎么想吧,你要那么想我也没办法。

图(1)

图(2)

图(3)
微软今天发布了 Visual Studio 2010 和 .NET 框架 4 正式版,并且 Silverlight 4 正式版将在本周末提供下载。
![]()
新版本 Visual Studio 2010 内置了 Windows 7 多点触控和 Ribbon 界面支持、IntelliTrace“时间机器”特性、多显示器支持、Windows Azure 开发、以及 Windows Phone 7 应用开发。.NET 框架 4 新增了更多业界标准的支持、更多语言、支持高性能中间件应用,与 .NET 框架 3.5 共存,以及更小的运行时安装包。
而本周末才可以下载到的 Silverlight 4 正式版,将提供更多媒体和商业应用方面的功能,超过 60 款的可自定义的预置控件。而 Pivot 技术的整合还是会在今年夏天推出。
Silverlight 4 首次演示是在去年 9 月,微软在 PDC 09 上发布了 Silverlight 4 Beta,随后又在今年的 Mix 10 上推出了 Silverlight 4 RC 版。
另外,微软上个月推出了一名为“Develop for Windows”的站点,Windows 开发者不妨去看看,内含 Windows 7 开发范例等资源。
更多信息: Visual Studio 2010 | .NET 框架 4 | Silverlight 4
官方公告: Microsoft Visual Studio 2010 and Microsoft .NET Framework 4 Available
微软在 Wave 3 时推出了基于 ActiveX 的 Windows Live 上传工具,可方便上传文件。等到 Wave 4 发布后,大家就可以看到已经基于 Silverlight 技术 Windows Live SkyDrive 的文件上传控件。
界面与 Windows Live Wave 3 时代的版本相同,支持批量上传、照片分辨率选择:
另外,新版 Windows Live Wave 4 上传控件的整个区域都是支持拖拽文件的,无论是否已经添加了文件。并且,拖拽进区域的文件即刻开始上传。
更新: 该 Windows Live 上传控件支持所有已安装 Silverlight 的浏览器,也支持 Mac 平台。
最新评论