July 2007 - Posts
【原文地址】 ASP.NET AJAX in .NET 3.5 and VS 2008
【原文发表日期】 Monday, July 30, 2007 12:06 AM
在过去，我曾在《VS 2008 JavaScript Intellisense》 和 《 VS 2008 JavaScript debugging》 中讨论过JavaScript和AJAX方面的改进。下面是作为VS 2008和.NET 3.5一部分发布的一些ASP.NET AJAX运行时特性的几个备注，以及你在VS 2008中打开现有ASP.NET AJAX 1.0项目时需要知道的几个重要事项。
包括在.NET 3.5中的ASP.NET AJAX
ASP.NET AJAX 1.0是以可以在ASP.NET 2.0之上安装的单独一个下载的形式发布的。从.NET框架3.5开始，所有这些特性都成为ASP.NET所固有的，这意味着在构建或部署应用时，你不再需要下载和安装单独的ASP.NET AJAX安装文件。
当你在VS 2008 中创建针对.NET框架3.5的新ASP.NET应用或网站项目时，VS会自动在你的web.config 文件里添加适当的AJAX注册设置，而且核心ASP.NET AJAX 服务器控件会出现在你的工具箱里。
随.NET 3.5发布的ASP.NET AJAX 版本有不少很好的改进 - 包括对可与WebPart一起使用的UpdatePanel的支持，对基于WCF的JSON结点的支持，对在JavaScript中使用ASP.NET用户数据，角色和登录应用服务的支持，以及N个缺陷修补和性能改进。
理解ASP.NET AJAX的版本
ASP.NET AJAX 1.0和.NET 3.5两者可以在同个机器上并行安装。ASP.NET AJAX 1.0是在System.Web.Extensions.dll 的V1.0程序集中实现的，而包括在.NET 3.5中的ASP.NET AJAX实现存在于System.Web.Extensions.dll 的V3.5程序集中。System.Web.Extensions.dll 的V3.5版本是个完全兼容于1.0版本的扩展集（这意味着你不要改动任何代码就可以使用它）。
机器上的每个ASP.NET应用都可以选择使用任何一个ASP.NET AJAX 版本来构建和运行。这是通过在web.config文件中<system.web.extensions>部分节点，以及应用编译时所引用的System.Web.Extensions.dll程序集版本来配置的（在网站项目中，这些引用是注册在web.config文件中的<assemblies>部分的，而web应用项目则是通过项目文件来指定这些引用的）。
你将能使用VS 2008来开发针对ASP.NET AJAX 3.5的应用，以及使用新的VS 2008多定向支持来构建使用ASP.NET AJAX 1.0的ASP.NET 2.0应用。在下面的部分，我将讨论怎么做。
重要的Beta 2信息
在我们在web上发布Beta2前几天，我们发现了一个并行安装ASP.NET AJAX的问题。如果你读过我原先的《VS 2008和.NET 3.5 Beta 2发布了》的博客贴子的话，你会记得下面这个我特别指出的来修正这一问题的安装后补丁步骤：
你应该下载和运行这个批文件。这只要几秒钟就可以运行完，它修补了这个星期早些时候我们发现的System.Web.Extensions.dll版本政策的问题，该程序集包含了 ASP.NET AJAX。如果你不运行这个批文件，那么用ASP.NET AJAX 1.0 和 VS 2005构建的现有的ASP.NET 2.0项目就会自动地运载随 .NET 3.5 Beta2发布的新ASP.NET AJAX 版本。这会工作而且运行良好，但会不小心导致你的VS2005应用依赖于.NET 3.5。运行这个批文件会改变新的System.Web.Extensions.dll 程序集的版本绑定政策，确保你只在你明确构建.NET 3.5项目时才使用新的.NET 3.5 ASP.NET AJAX版本。
好消息是，这会修正我们发现的并行安装问题，使得我们可以安全地在同一台机器上使用VS 2005和VS 2008同时开发ASP.NET AJAX应用。
但有一个问题是，在VS 2008中第一次打开老的ASP.NET 2.0项目时，它会导致VS 2008不正确地检测出所用ASP.NET AJAX的版本，特别地，它会导致VS 2008认为当前项目已经使用了.NET 3.5。这要求你在VS 2008 Beta2中第一次打开现有的ASP.NET AJAX 1.0网站项目时，采取额外的步骤来更正这个问题。在VS 2008的最终版本中， 你将不需要采取这些步骤。
把ASP.NET AJAX 1.0应用升级到使用ASP.NET AJAX 3.5
当你使用VS 2008 打开使用了ASP.NET AJAX 1.0的现有ASP.NET 2.0 应用时，你可以选择将应用升级到使用.NET 3.5（以及包含在其中的ASP.NET AJAX 版本）。
VS Web工具组最近发表了《Upgrading ASP.NET AJAX 1.0 Websites and Web Applications to .NET Framework 3.5》的博客贴子，其中描述了怎么使用VS 2008 Beta2来实现升级的逐步指令。好消息是，把ASP.NET AJAX 1.0应用更新到.NET 3.5时，不要求你改动任何代码，只需要花几分钟就可以完成。
作为升级ASP.NET AJAX 1.0应用到.NET 3.5的一部分，你要更新你也许在用的编译过的ASP.NET AJAX控件库。ASP.NET AJAX 控件工具包开发组刚发表了AJAX 控件工具包的ASP.NET AJAX 1.0和.NET 3.5 版本，你可以在这里下载：
《Upgrading ASP.NET AJAX 1.0 Websites and Web Applications to .NET Framework 3.5》博客贴子讨论了如何将AJAX 控件工具包的ASP.NET AJAX 3.5版本加到VS 2008工具箱里。
使用VS 2008 构建ASP.NET AJAX 1.0应用（使用多定向）
当你使用VS 2008打开使用了ASP.NET AJAX 1.0的现有ASP.NET 2.0 应用时，你也可以选择不升级到.NET 3.5，而是使用VS 2008中新的多定向特性来构建使用了ASP.NET 2.0 和ASP.NET AJAX 1.0的应用。
VS Web工具组最近发表了《Using VS 2008 to Target ASP.NET AJAX 1.0》的博客贴子，其中描述了如何使用VS 2008 Beta2来实现这个开发的逐步指令。
在该博客贴子里，还包括了几个你要在Beta2中采取的手工步骤，来把ASP.NET AJAX 1.0和ASP.NET AJAX控件工具包服务器控件填充到VS 2008工具箱中。在VS 2008的最终版本中，我们会发布一个安装包来自动化这个过程，以及在VS 2008中添加可为你所用的ASP.NET AJAX 1.0项目和文件模板。
你也许在想，为什么使用VS 2008来针对ASP.NET AJAX 1.0应用，而不就用VS 2005呢? 好处是，它允许你构建能在你现有的服务器上工作的ASP.NET AJAX 1.0应用(不必马上把它们升级到.NET 3.5），同时，还允许你利用VS 2008 IDE的一些新特性，象JavaScript Intellisense, JavaScript Debugging，更棒的所见即所得的HTML设计器，CSS管理，改进的代码编译器，VS Professional中的单元测试，TFS中的连续集成支持，等等。
结语
.NET 3.5现在包括了对所有ASP.NET AJAX 1.0特性的内置支持。我会在将来撰写更多的博客贴子，描述如何利用它提供的新特性。
你可以使用VS 2008针对用ASP.NET AJAX 1.0开发的现有ASP.NET 应用，也可以针对内置于.NET 3.5的ASP.NET AJAX的新版本。上面提到的VS Web工具组的博客贴子在这2个方面的逐步指导应该对你有所帮助。
希望本文对你有所帮助，
Scott
【原文地址】 VS 2008 and .NET 3.5 Beta 2 Released
【原文发表日期】 Thursday, July 26, 2007 2:11 PM
我非常高兴地宣布，VS 2008和.NET 3.5的Beta2版本可以下载了。你可以在这里下载Visual Studio 2008产品。你也可以在这里下载较小的VS 2008 Express版本。
VS 2008 和 Visual Web Developer 2008 Express可以与VS 2005并行安装。.NET 3.5 Beta2还包括一个go-live许可，这允许你构建和部署基于这些产品之上的生产性的应用。
非常重要的注意事项： 请阅读本博客贴子下面的“安装注意事项”，内含安装之后你必要采取的几个步骤，以保证一切运行良好。其中一个步骤修正了并行安装造成的ASP.NET AJAX问题。
一些Web开发新特性之快速指南
在过去的几个月里，我写过几个博客贴子，讨论这个版本里的一些新的改进。下面是我已经讨论过的几个改进的概述列表。这个列表并不详尽，还有很多很多东西我还没有机会在博客里讨论（敬请收看以后的贴子！）：
VS 2008的多定向支持
VS 2008允许你构建针对多个.NET框架版本的应用。你可以从下面的博客贴子里进一步了解其中的工作原理：
VS 2008 Web设计器和CSS支持
VS 2008包含一个显著改进的HTML web设计器。该设计器提供了分割视图编辑，嵌套母板页，以及出色的CSS集成。下面是我对此作了详述的2篇文章：
ASP.NET还提供了一个新的<asp:ListView>控件，不久的将来我将在博客里讨论该控件。该控件对数据UI场景提供了非常灵活的支持，允许对输出的标识做完全的定制，与VS 2008中的新CSS支持还有良好的协作。
ASP.NET AJAX和JavaScript支持
.NET 3.5 内置提供ASP.NET AJAX，还添加了支持WebPart的UpdatePanel，支持JSON的WCF，以及N个缺陷修补和性能改进等方面的新特性。VS 2008还对集成JavaScript和AJAX进你的应用提供了极棒的支持:
在接下来的几天内，我将撰写一个博客贴子，讨论其中几个特定于ASP.NET AJAX的改进，以及如何将现有ASP.NET AJAX 1.0应用升级来使用这些改进。
语言改进和LINQ
VS 2008中的新VB和C#编译器对这些语言做了显著的改进。两者都添加了函数式编程概念的支持，允许你编写更干净，更简洁，更具有表达性的代码。这些特性还促成了我们称之为LINQ（语言级集成查询）的新编程模型，使得查询和操作数据成为.NET中的一等编程概念。
下面是我撰写的一些讨论这些新语言特性的文章（用C#作为示例）：
LINQ to SQL中的数据访问改进
LINQ to SQL是.NET 3.5中内置的OR/M (对象关系映射器)。它允许你使用.NET 对象模型对关系数据库进行建模。然后你可以使用LINQ对数据库进行查询，以及更新、插入，删除数据。LINQ to SQL完整支持事务，视图和存储过程。它还提供了一个把业务逻辑和验证规则结合进你的数据模型的简易方式。下面是一些我讨论如何使用LINQ to SQL的文章：
我会在以后的几周内再往这个系列里添加几篇文章。我认为你会发现LINQ to SQL显著地简化了构建非常干净的数据模型以及编写极其干净的数据代码。
说不尽的其他改进
上面的列表只是所做改进的一小部分。针对客户端开发，VS 2008 包含了WPF设计器和项目支持。ClickOnce 和WPF XBAPs现在在FireFox中也工作了。WinForms和WPF项目现在也能使用ASP.NET 应用服务(成员，角色和用户数据)来漫游用户数据了。办公开发也更加丰富了，包括对Office 2007 Ribbon的集成支持。WCF和Workflow项目和设计器也包括在VS 2008中了。单元测试的速度大为提高，而且单元测试的支持现在包括在VS Professional版本（而不仅仅是VSTS版了）中了。连续集成支持现在也内置于TFS中了。AJAX web测试（单元和压力）现在也由VS Test产品支持了。还有许许多多多的改进，这里无法一一提及了。
重要的安装注意事项 - 务必阅读一下！
在安装VS 2008 和.NET 3.5 Beta2之后，还有2件重要的事情你应该马上做：
1) 你应该下载和运行这个批文件。这只要几秒钟就可以运行完，它修补了这个星期早些时候我们发现的System.Web.Extensions.dll版本政策的问题，该程序集包含了 ASP.NET AJAX。如果你不运行这个批文件，那么用ASP.NET AJAX 1.0 和 VS 2005构建的现有的ASP.NET 2.0项目就会自动地运载随 .NET 3.5 Beta2发布的新ASP.NET AJAX 版本。这会工作而且运行良好，但会不小心导致你的VS2005应用依赖于.NET 3.5。运行这个批文件会改变新的System.Web.Extensions.dll 程序集的版本绑定政策，确保你只在你明确构建.NET 3.5项目时才使用新的.NET 3.5 ASP.NET AJAX版本。
2) 假如你曾经在你的机器上安装过Orcas或VS 2008的早期版本（Beta1 或某个CTP 版本）的话，你需要在安装Beta2后重新设定你的VS 2008设置。如果你不这么做的话，有些设置会非常奇怪（一些窗口在出现在奇怪的地方），你也有可能看到一些IDE性能问题。你可以在命令行上对VS 2008的IDE版本键入“DevEnv /resetsettings”来重新设定你的配置：
结语
在VS 2008和.NET 3.5中，我希望你会发现许许多多非常有用的新改进和功能增强。敬请在下几个星期里收看我的博客，我将对这些新特性做详细讨论以及讨论如何充分利用这些新特性。
谢谢，
Scott
Visual Studio 2008 Beta2中的Class Designer终于支持C++了，上面是一个MFC程序的类图，可以看到已经支持扩展MFC的宏了，可惜只能看不能重构代码。尽管Class Designer这功能相当不错，但是设计师们可能还是更习惯IBM 的Rational Rose Developer for Visual Studio和UML。我用Class Designer的Ｃ＃支持的时候也就是加加注释而已，重构我更习惯用DevExpress提供的工具Refactor来做，类则用XSD.exe生成，因为Class Designer生成的属性只会扔NotImplementedException异常。
Visual C++项目组在做下一个版本的市场调查，有兴趣的可以去提提要求。
【原文地址】 First Look at IronRuby
【原文发表日期】 Monday, July 23, 2007 8:45 AM
过去的几年里，我们一直致力于使得.NET和CLR成为出色的动态语言环境。大概14个月前，在我的开发团队内，我们组成了一个专门的开发组，专注于增加对动态语言的丰富CLR运行时支持，以及推出流行动态语言的第一流.NET实现。
DLR 背景知识
今年春天，我们发布了我们称之为“动态语言运行时（Dynamic Language Runtime）”（简称为DLR)的新.NET库的第一个预览版。该库提供了一组建立在CLR基础之上，特为动态语言场景而设计的特性。这些特性包括，一个共享的动态类型系统，语言宿主模型，以及能产生快速动态代码的基础设施支持。这些特性极大地简化了高质量的动态语言的.NET实现的构建。这些实现可以访问和使用.NET框架中的任何API，还可以轻松地与用任何一门.NET语言编写的代码进行互操作。譬如，你可以编写一个Ruby类，在其中调用一个C#类，这个C#类进而调用一个Python类。
今年春天，在MIX 07大会上，我们宣布了微软将发布四门动态语言的.NET实现：
- IronPython
- IronRuby (新)
- Javascript
- 动态 VB (新)
我们的IronPython实现的源代码，以及底层的DLR库的源代码四月份已经在CodePlex上发布。你现在就可以在IronPython codeplex网站上下载这2者的源代码。所有的源代码都是在MSPL permissive license许可下发布的，该许可提供了网站的商业性和非商业性改动代码的权利。
IronRuby Pre-Alpha 发布
今天，我们发布了我们的IronRuby实现的第一个公开预览版。你可以在John Lam这里的博客贴子里进一步了解如何下载源代码，如何编译，以及如何试验这个预览版。
今天这个IronRuby预览版还是一个非常早期的版本，几个语言特性和大部分的库还没有实现（所以我们称之为“pre-alpha”版呢）。但它确实实现了大部分的核心语言支持，而且可以使用标准的.NET类型和API。
IronRuby是被设计来利用一个我们称之为“Dynamic Sites”的新DLR特性的，该特性提供了一个快速的,可适应性的(adaptive) call-site方法缓存的实现。它还使用了CLR的轻量级代码生成特性。轻量级代码生成允许动态语言的实现在运行时创建内存中的IL，继而JIT为本机代码，而不用在硬盘上保存什么东西。这可以导致比解释性代码好得多的运行时性能，轻量级代码生成特性确保了一旦用完JIT过的代码之后，我们可以将其垃圾回收以避免内存泄漏。
我们今天发布的这个预览版主要是针对那些对语言实现有兴趣的开发人员的，这样他们可以开始研究IronRuby源代码，以及了解它是如何实现的。有兴趣把玩Ruby的.NET实现早期版本的开发人员也可以下载相应代码，尝试一下它的功能。
IronRuby 项目计划
下个月，我们将把IronRuby源码库移到RubyForge上。同时我们也将开放这个项目，允许非微软开发人员加入这个项目的开发，以及贡献源码。然后我们将继续实现剩下的语言特性，修正随着更多的库和源代码移植过来时发现的兼容性问题。
其结果将是一个建立在.NET之上的，任何人都可以免费使用的，兼容性良好的，快速的，和灵活的Ruby实现。
IronRuby "Hello World" 控制台例程
如果你下载和编译了IronRuby源码，你大概在想“我该如何开始使用它呢”？
想上手的最简单的方法就是运行rbx.exe，一个交互性控制台应用，默认情形下是编译在\bin\release目录里的：
这个控制台shell提供了交互性编写Ruby代码的功能。在写完每一行后，这个shell就会立刻执行相应代码。
例如，我们可以键入 puts "Hello World" 来输出“hello world”：
想连续输出这个字符串10次，我们可以键入下列代码：
要在IronRuby中使用Windows Forms功能的话，我们可以键入一个require语句，来引用System.Windows.Forms程序集，然后使用MessageBox.Show方法来在一个模态对话框里显示消息：
IronRuby "Hello World" WPF 例程
在.NET之上实现一门语言的一个好处是，它允许使用该语言的开发人员完整地访问.NET框架提供的丰富的框架库。
作为对这个好处的一个简单示范，我将建一个HelloWPF.rb文本文件，在其中输入下列Ruby代码：
上面的代码使用了WPF UI框架，建立一个窗口，内含一个StackPanel布局管理器，开始时只包含一个按钮。按钮被点击后，创建了一个新的标签控件，加到StackPanel中 (导致该控件在Window中自动流动到相应位置）。
然后我可以将HelloWPF.rb文件作为参数传给rbx.exe来运行上面这个应用：
当我运行它时，我将得到一个内含一个WPF按钮的窗口（注意上面，我在上面的代码里给这个按钮加了一个好看的DropShadowBitmapEffect效果）：
我每按一下这个按钮，一个新的标签控件就会添加进上面的窗口中：
可以使用所有的.NET API自然威力无比，但你也可以注意到，在我们编写的代码中，是如何自然地将.NET API集成进其他的语言句法的:
在上面的代码片段里，我使用了Ruby的block语言特性（类似于C# 3.0和VB9中的Lambda表达式），来实现WPF按钮的Click事件处理方法。注意在该block里，是如何使用标准的Ruby命名模式来访问任何.NET API的。比如，不是使用WPF Label控件的“FontSize”属性，我们用了“font_size”作为属性访问名字来访问该属性。IronRuby自动处理这样的命名转换，允许开发人员使用一致的命名模式来编程，而不用管他们所选择的语言。
结语
如果你有兴趣试验一下IronRuby这个早期版本的话，你可以在这里下载和编译其源码。
然后，你可以在这里下载我上面的WPF例程，自己运行一下（注:你必须预先安装了.NET 3.0 或 3.5，因为这些版本才提供WPF API）。想进一步了解WPF的话，我强烈推荐Adam Nathan的优秀著作《WPF Unleashed》（阅读一下Amazon上该书的评语就知道我推荐的理由了）。
希望本文对你有所帮助，
Scott
以前弄个了用于AD OU、帐号和组等对象的几个类（见《活动目录操作类更新》），现在对这个再进行一点改进和增加一些功能。貌似gotdotnet workspace已经无法使用，过些日子我把更新后的类库发布在codeplex上再发布个具体链接出来。
修改/增加的地方：
1、权限机制：摒弃在配置文件中配置域管理员帐号密码的方式，而采用重新用COM+安全身份来执行整个AD操作。
2、用户：修正Lock/UnLock和Enabled/Disabled，Mail-Enabled/Mailbox-Enabled的用法。
3、组：修正创建组时无法指定Group Scope/Group Type的问题，增加对各类型组的创建支持。同时支持更改组Owner，和设置管理Membership list的属性。
其中更新Membership list属性的更改比较有意思。因为在AD中并没有一个属性与之对应，只能通过修改访问规则来设置：
ActiveDirectorySecurity ads = myGroup.ObjectSecurity;
ActiveDirectoryAccessRule accessRule = new ActiveDirectoryAccessRule(
new NTAccount(Domain, samAccountName),
ActiveDirectoryRights.WriteProperty,
AccessControlType.Allow,
new Guid("bf9679c0-0de6-11d0-a285-00aa003049e2"));
ads.AddAccessRule(accessRule);
myGroup.ObjectSecurity = ads;
myGroup.CommitChanges();
4、Mail相关：增加了对Exchange Server/StoreGroup/MailStore/Mailbox的各类操作（相关见《
枚举Exchange Server, StoreGroups, MailStore》）。同时支持对proxyAddresses等属性的修改设置。
其中更新proxyAddresseses并设置 Primary proxyAddress也比较有意思，摘出供参考：
private void UpdateProxyAddresses(DirectoryEntry userEntry, ArrayList emailAddresses)
{
PropertyCollection properties = userEntry.Properties;
PropertyValueCollection proxyAddresses = userEntry.Properties["proxyAddresses"];
if (proxyAddresses != null)
{
for (int i = 0; i < emailAddresses.Count; i++)
{
string emailType = emailTypes
;
string emailAddress = emailAddresses.ToString();
int schemaIndex = Array.IndexOf(emailTypes, emailType);
if (schemaIndex > -1)
{
// Is it the primary address
if (schemaIndex == 0)
userEntry.Properties["mail"].Value = emailAddress.ToString();
string emailPrefix = emailPrefixes[schemaIndex];
bool found = false;
for (int j = 0; j < proxyAddresses.Count; j++)
{
string proxyAddress = proxyAddresses[j].ToString();
if (proxyAddress.StartsWith(emailPrefix + ":"))
{
proxyAddresses[j] = emailPrefix + ":" + emailAddress;
found = true;
}
}
if (!found)
proxyAddresses.Add(emailPrefix + ":" + emailAddress);
}
userEntry.Properties["proxyAddresses"].Value = proxyAddresses.Value;
}
}
}
public void MakePrimaryProxyAddress(DirectoryEntry userEntry, string newMailAddress)
{
System.DirectoryServices.PropertyCollection properties = userEntry.Properties;
PropertyValueCollection proxyAddresses = userEntry.Properties["proxyAddresses"];
if (proxyAddresses != null)
{
bool found = false;
for (int j = 0; j < proxyAddresses.Count; j++)
{
string proxyadd = proxyAddresses[j].ToString();
if (proxyadd.StartsWith("SMTP:"))
{
found = true;
string[] proxyparts = proxyadd.Split(':');
proxyAddresses[j] = "smtp:" + proxyparts[1];
}
}
if (!found)
{
proxyAddresses.Insert(0, "SMTP:" + newMailAddress);
userEntry.Properties["proxyAddresses"].Value = proxyAddresses.Value;
}
}
}
发现很多情况下，msn传输文件比qq要慢，倒不是说msn没有快的时候，但是大部分的时候是真的比QQ慢，连我这种神经比较大条的人都注意到了，google了一下，早就有人做了解答，基本上就是说msn传输文件是使用TCP，而QQ使用UDP，剩下的事情就是论证TCP传输文件没有UDP快。大概的就是下面的几个观点：
1. TCP是可靠的，需要验证数据是否到达和是否正确，而UDP是不可靠的，少做了很多事情，所以MSN的文件传输比QQ慢。
我看了当时就想笑，也用了QQ不少时日了，从来也没有发现传输文件有问题的，用UDP作协议也很久了，不做应用层验证重传的代码，我还真不敢写。这个理由，失败。
2. TCP建立连接需要3次握手，而UDP不需要，所以TCP慢。
3次握手这个事实倒是千真万确，还好我没有那么容易被忽悠，两个人谈话之前要握握手的确要稍微费上几秒钟，但是这个关谈话的语速啥事情？假如网络的ping值达到300ms，各位看官喜欢网络游戏的，估计都不会玩了，否则垂死的boss会高兴的发现你忽然变成了木偶可以随便殴打不还手，最后你只能骂骂电信网通然后再复活几分钟后又是一条好汉。但是对于TCP，这样的ping值，3次握手绝对不需要1秒钟，把这个定为文件慢慢传的罪魁祸首，似乎太不靠谱了，这个理由还是失败。
3. TCP一旦建立链接,路由就确定了,而UDP是不确定的路由方式,谁速度快走谁的线路。
这样说就说明没有作者好好理解TCP/IP协议了，TCP的链路只是一个逻辑的，又没有建立物理链路，下面跑的还是IP包，这个包走这条路，那个包完全可能走另外的路，这点TCP和UDP没有两样。理由继续失败。
4. msn服务器在国外？
有些道理，但是我听一个美国的朋友说他也喜欢用QQ传文件的。
那到底是怎么回事呢？是因为微软没有做好？（题外话，个人的确觉得MSN相比QQ的飞速进步而显得动作迟缓）QQ的Fans开始摩拳擦掌，一些不那么喜欢M$的估计就要开始丢板砖了。不管立场如何，事实还是要探寻一下，本着不求甚解，薄积薄发，浅入浅出的精神，我认为有几个可能原因：
1. 两个传文件客户端都在NAT后面的时候 (你不知道NAT啥意思？比如多个人通过路由器共享一个猫上网，那么你们一般就是在NAT后面了)，UDP只要开始几个穿越NAT的协商包需要服务器转一下，后面的文件数据可以两个客户端之间直接传输搞定，但是TCP就只能全程由服务器中转了，你说哪一个会比较快？ 为什么TCP一定要服务器中转？先看看NAT吧，听说有高人可以用raw sock搞定，反正我没有中间服务器搞不定。
2. 但是即使上面的条件不成立，msn还是一般比QQ慢的。问题还是在出在前面提到的验证数据可靠性上面，TCP是可靠的，UDP是不可靠的，但是用UDP做传输文件这档子事情，肯定要在应用层写一个验证的协议，否则传过来的文件缺胳膊少腿，会被用户骂死的。说是协议，其实也不难，打个比方吧：
long long ago，贾宝玉在北京，林黛玉在长沙，怎么互诉衷肠呢，派家丁送信！路途遥远，怎么知道信收到没有？打电话问一下是不行的，只能看家丁是否带了回信来了。假如发现一个家丁一个月还没有回，那就多半迷路堵车遭遇打劫或者开小差到扬州快活去了，再派一个人送吧！ TCP就是这么做的，UDP一般也这么做，但是实现上有时候往往有区别。
北京到长沙之间的路，并不是只有一个人跑的，常常很拥堵，假如发现家丁好久没有回了，TCP版的贾宝玉再派人送信是要的，但是他会比较识大体，他会少写信，降低发送速度，原来一天一封，现在可能一周一封了。他想，大家假如都这样，路就不会那么拥挤了。这做法很有道理，假如塞车了大家都想见缝插针，只能越来越塞，最后大家都动不了，还不如彼此容让慢慢排队。而UDP版本的贾宝玉假如也这么集体主义，那么他就叫做TCP友好流，就假如它只管自己拼命挤，就是非TCP友好的。
所有的TCP协议假如发现拥塞，都会马上降低自己的发送速度。假如基于UDP的协议不这么做的话，原来拥塞的IP包加上重发的包，网路只会越来越拥塞，最后所有的集体主义的TCP流都会做出牺牲，把带宽让给一些非TCP友好的UDP流。
我怀疑（仅仅是怀疑而已，我也没有条件和时间验证），QQ的文件传输机制是不那么TCP友好的，它抢带宽更加"我能"，这样虽然对于整个网络负荷不是什么好事，但是对于单个用户，就见仁见智了，就好像大家看多线程下载或者p2p一样。
我好像很久之前就说要写一篇专门介绍新的SharePoint权限系统的博客文章……今天就给大家尽量详细的介绍一把，我也争取把这个“补习班”系列继续下去……
说到权限控制，其实包含了这样几个内容：“谁”对“什么内容”有“什么权限”。
在SharePoint里，“谁”用“User Token”来代表，“什么内容”其实就是权限控制范围“Scope”，而“什么权限”（权限级别，Role Definitions）则是一组对网站内容的具体操作（比如，读取、新建、修改、管理等等）。
看看这张图：
“谁”对“什么内容”有“什么权限”（User Token）：
AD里的用户或用户组（当然也可以是你自己定义的membership provider中的用户或用户组）都可以加入到SharePoint中作为一个使用权限的实体，即上图中的“Users”。而SharePoint中的“组”（即上图中的“Groups”），并不是你在AD中的安全组，它仅仅是SharePoint为方便权限的批量设置而定义的一个快捷方式。所以你可以把AD里的用户和安全组通通加到某个SharePoint组里，统一设置SharePoint权限。
“谁”对“什么内容”有“什么权限”（Scopes）：
SharePoint中，可以被单独赋予权限控制的范围为：网站、列表（文档库）、文件夹、列表条目（文档）。可以看到，最细的粒度是达到了条目级，也就是说，在一个列表（或文档库）里，不同的文件夹、不同的列表条目（或文档）可以被赋予不同的权限。
“谁”对“什么内容”有“什么权限”(Role Definitions)：
在WSSv3中，我们不能直接把某一个或几个权限（Rights，即读取、新建、修改等等）直接分配出去，而必须先经由“Role Definitions”的组合。这个“Role Definitions”其实就是我们在网站中可以管理的“权限级别”。SharePoint内置了“读者”、“讨论参与者”、“网站设计者”等几个权限级别，每个级别都包含了一组权限，管理员也可以对某个网站设置自定制化的权限级别。
Role Assignments
“Role Assignments”是用来把“权限级别”、“User Token”和“权限作用范围（Scope）”关联起来的对象模型，即把“谁”、“什么内容”和“什么权限”关联起来。在通过浏览器操作SharePoint的时候是看不到这个对象的，但它隐藏在了管理员的设置权限操作里。
所以，其实在SharePoint中，角色（Role）包含两个内容，一个是权限级别（Role Definition），另一个是权限分配（Role Assignment）。
角色分配继承
Role Assignments是可以沿权限范围继承的，比如网站可以继承父网站的权限分配，列表可以继承网站的，列表条目可以继承文件夹或列表的，这种继承关系可以被断开，并设置新的独立权限设置，也可以由独立设置恢复为继承关系。
权限级别继承
权限级别是可以在网站之间继承的，一个网站可以继承顶级网站的权限级别设置，也可以断开继承，编辑其自己的权限级别。
这样讲了半天，也不知道大家能不能看懂，最后举个简单的例子说明：
一个叫“陈曦”的用户对“部门日历”有“讨论参与者”的权限，其中“讨论参与者”包含了“添加列表条目的权限”。
今天写代码的时候发现一个警告（下面是模拟的代码和警告）：
warning CS3005: Identifier 'ClassLibrary1' differing only in case is not CLS-compliant
而'ClassLibrary1' 是我的命名空间。当时我就头大了，命名空间也会报not CLS-compliant。
分析后，结果发现是我命名空间书写的时候，一个写成了大写，一个写成了小写，类似如下代码：一个写成了 ClassLibrary1，一个写成了 Classlibrary1
AssemblyInfo.cs 文件有以下定义
[assembly: CLSCompliant(true)]
代码文件：
namespace ClassLibrary1
{
public class Class1
{
}
}
namespace Classlibrary1
{
public class Class2
{
}
}
这篇博客把这种情况记录下来，让以后碰到类似情况的人，也好有所帮助。
目前市面上还没有一本系统阐述微软软件开发流程, 也就是所谓的Microsoft Solution Foundation (简称MSF)的书籍, 做为世界上最成功的软件公司之一, 它的开发流程不可谓不具有很好的借鉴和学习价值. 那么我们如何才得以一窥其全貌呢?
幸运的是, 一本软件工程书籍《移山之道-- VSTS软件开发指南》即将由博文视点出版上市. 这本书根据虚拟的"移山软件公司"成立 -> MSF和TFS培训 -> 开发技能培训 -> 项目实战开发这一时间主线, 撷取一个虚拟团队"移山群侠"由forming->storming->norming->performing各个阶段中的典型场景, 分享MSF最佳实践的经验, 摆脱刻板的说教, 让读者不光觉得MSF提倡这样做, 而且这样做真的有道理, 可以解决实际问题. 从而为我们将MSF方法论的思想融会贯通, 一一道来. 书中的场景都非常具有代表性, 可能是一次Team meeting, 一次Brain Storm, 一次开发人员间的争吵, 一次培训, 甚至是一次Team building(腐败), 通过这些典型的场景引出软件开发中的典型问题, 引起读者思考, 而后根据作者的经验介绍MSF的实践做法, 来逐一解答这些典型问题. 同时还穿插介绍了如何使用Visual Studio Team System来支持整个开发生命周期各个阶段的活动.
作者邹欣是微软公司的资深经理, 曾经参与Outlook和VSTF产品的开发管理工作, 目前是微软亚洲研究院的研发经理, 在博客堂上的昵称是"关心", 他在软件开发管理和开发技能培训方面有着极其丰富的经验, 他用充满幽默和智慧的笔调为我们奉献了这部软件领域的"移山群侠传", 告诉我们如何把理论上的正确transfer成实践上的正确, 用作者自己的话说"这是一本中国人写给中国人看的怎样在中国搞软件开发的书". 我十分有幸阅读了这本书的初稿, 通过阅读, 使我对MSF方法论有了更直观的认识, 扫掉了心中积郁的一些疑问, 相信当它出版时, 能够为读者带来不一般的阅读感受.
关于这本书的更多信息, 请访问其官方网站: http://yishan.cc, 在上面还可以发现成书过程中的一些趣闻轶事, 还有邹欣老师最后在修改阶段细致入微地进行多次迭代, 修改书中的bug的有趣经历. 相信它们能帮助你更好地了解这本书的质量和内容. 而且, 在http://yishan.cc上注册账户之后, 还有机会访问更多有价值的文档内容.
书籍部分章节试读, 请访问: http://book.csdn.net/bookfiles/443/#c1
有趣的延伸阅读:
移山群侠传
故事的背景
<移山外传>之--(1)技术部来的新美工(根据真实故事改编)
VSTS TFS 网上资源
引子(1)
引子(2)
在新的SharePoint环境中，我们可以借助SharePoint Designer非常轻松的为某个列表设计并加载一个工作流。
这种方式的优点是快捷方便，无需任何代码，支持条件判断和多级流程，并且微软提供了丰富的操作选项，用户也可以扩展自己新的工作流操作。但缺点也十分明显：无法重用。微软没有给我们内置的方法把一个SPD设计的工作流转化成一个工作流模板，从而应用到其他列表中。
SharePoint Designer Team最近发布了一篇文章，简单介绍了如何把SPD工作流导入到VS2005的工作流工程里，这样我们就可以在这个SPD工作流的基础之上，开发所需的工作流模板了。
基本步骤为：
1、在VS里创建一个工作流工程
2、把SPD工作流生成的xoml文件和rules文件拷贝到VS工程里
3、基于XOML文件生成.cs代码文件（非必要步骤）
4、基于现有的这些文件继续开发、部署、调试工作流模板
原文链接如下：
http://blogs.msdn.com/sharepointdesigner/archive/2007/07/06/porting-sharepoint-designer-workflows-to-visual-studio.aspx
终于下定决心，把家里笔记本的操作系统装成了Win2008。（Windows Server 2008 June 2007 CTP）。在安装使用中，碰到了一系列的问题，特整理如下，避免后来者被这些问题所阻挡。
一、Win2008中的Internet Explorer 增强安全性设定
Win2003我们如果不是作为运维环境的服务器，而是开发机使用的时候，安装好Win2003后，第一件事情就是卸载Internet Explorer 增强安全性设定（Internet Explorer Enhanced Security Configuration）。
但是你在Win2008中可能会碰到问题，因为Win2008中这个组件不再可以卸载了，而是变成了针对用户组设置启用不启用了。参见下面两幅图。
Win2008中的设置位置如下:
开始菜单 --> Administrative Tools --> Server Manager
在 Server Manager 中的 Security Information 中点击 Configure IE ESC ，就会出现下图。
比如，我这台电脑是用的Administators组的用户登录的，那我就只需要关闭Administrators用户组的IE ESC。
二、无线网卡（Intel(R) PRO/Wireless LAN 2100 3A Mini PCI Adapter ）的驱动问题
我的笔记本是Dell Inspiron 600m，无线网卡为：Intel(R) PRO/Wireless LAN 2100 3A Mini PCI Adapter
这个无线网卡在Vista以及Win2008中都有问题，早期版本的驱动都没法使用，你如果想安装驱动，你需要去Intel站点下载一个最新的驱动。
请参看如下Intel文章：
http://support.intel.com/support/wireless/wlan/sb/CS-010623.htm
参考资料：
http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=800610&SiteID=17
三、Win2008无线功能默认是不启动的，你需要添加对应功能才能启用无线网络。
启动配置地方仍然是 开始菜单 --> Administrative Tools --> Server Manager 中。
在 Features Summary 中，点击 Add Features。然后如下图，选择 Wireless LAN Service。
下图中是因为我已经安装了这个功能，所以显示的是灰体，同时后面括号中有个单词Installed。
参考资料：
http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1800013&SiteID=17
Symbian 中也有类似Windows COM的机制，用来作为二进制的模块间接口标准。
ECom比起windows COM来要简单得多，没有GUID 没有IUnknown，没有marshal，没有其他好多东西。。。
那么，，，还剩下什么呢？逐个说一下
首先 和COM一样你的DLL要注册，这样别人才能找到你，不同的是，不是注册到注册表，DLL也没有引出注
册反注册的函数（没有类似DllRegisterServer and DllUnregisterServer的东西），而是写一个RSS文件，
里面写上你的ECom的注册信息，这个RSS文件编译后生成RSC文件，放到系统的ECom插件注册目录下，这样
系统就可以通过这个文件中的信息找到你的ECom DLL.这个RSS不难写，基本上抄一个改个ID就好了。
唯一要注意的是，RSS编译后产生的RSC文件名要和DLL文件名一样。
*注意: 这里的RSS和Blog那个rss不是一个概念，Symbian 里面的资源文件的展名就是RSS。
然后，你的DLL必须实现一个引出函数
EXPORT_C const TImplementationProxy* ImplementationGroupProxy(TInt& aTableCount)；
这是必须的，这个函数返回一个结构数组，描述了这个DLL所包含的所有对象的ID 和 工厂函数的指针。
通常这个函数是返回一个DLL里的全局变量比如：
const TImplementationProxy ImplementationTable[] =
{
IMPLEMENTATION_PROXY_ENTRY(0x13457890, CFoo::NewL)
};
CFoo::NewL会返回一个，CFoo*，而CFoo一定是实现了 ID 0x13457890 对应的接口。
就是这么简单，和Windows的COM比起来非常原始，但是ECom在Symbian 和 S60里面应用非常广泛。
因为手机系统需要极强的定制能力，大多数功能都是靠ECom实现的，不同版本的差异很多是靠发行
的时候采用不同的ECom来做的。ECom的DLL在制作成手机的ROM的时候和其他一般的DLL是有些不
一样的，ECom会拥有一个单独的区域，并且编制索引来保证ECom的加载会比其他DLL要快一些。
所以有些时候会把一些数据文件做成ECom，就是因为加载比较快。
最后借这里放个招聘广告，如果你对于手机平台，Symbian 系统开发有兴趣，想深入了解S60，甚至希望
参与到S60的设计和开发，或者对于s60相关的项目管理有兴趣。现在有个不错的工作机会，不要求你有
Symbian或者手机平台的开发经验，但需要你对技术有热情。
Software Engineer
http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/C31D75074228F5F6C22572BF0028BCAD?OpenDocument&Lang=Global
Project Manager
http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/749DDCA528A35375C22572BF00285178?OpenDocument&Lang=Global
More Posts
Next page »