对WCF的了解还停留在2006年初看Indigo的地步。当时看了一本MS 2005年出版的《Programming Indigo》电子书，是一本非常棒的书，我只记得当时作为初学者我看第一遍的时候，对其中每个章节中的相关概念定义都能心领神会，这就说明这本书是一本非常棒、值得收藏的书。因为WCF的核心就是接口协议定义，而它做到了让初学者能迅速理解这些接口协议。
对于学习WCF，我个人理解是一定要理解WCF中的接口协议定义和规则约束！了解这些远远比你去看看Code，写写Sample来得重要许多。从某种意义上，学WCF就是学概念、学定义、学规则、学接口协议，而不是让你像学C#或ASP.NET那般追求深入实际应用，然后再去反过来体会C#/ASP.NET原理。
一晃，Indigo更名为WCF并入.net3.0概念中。天天念叨着WCF、WPF、WF，可是除了WF还顺应潮流接点轨外，WCF就停在Indigo阶段，WPF更仅仅只了解其相关的XAML知识。正好最近越忙越是精力充沛，抽空花了两三个小时翻了2007年2月刚出版的《Programming WCF Services》一书，算是在Indigo基础上重新认识了下WCF，感觉还OK，各类细节变来变去，但只要它的接口协议、概念定义没变就好办，剩下的就是从《Programming WCF Services》新书中挑几章自己兴趣的或感觉变化比较大的再细细品味下，也算完成本书的阅读工作了。
昨天我说花了一夜用HTML+Photoshop+Javascript搞了个系统原型，于是有人开始质疑我这个做法是否值得，理由是让美工或其他人搞个比自己搞既快又好。我承认自从99年接触Photoshop 3.0/4.0以来，我的美工水平一直停滞在满足图片的修修补补，让专业美工搞这个自然是快而好。但我想做一件事情，更多的应该是看做这件事情的目的。系统原型相当于建筑行业的图纸，其更多的价值在于迅速构建一个与用户沟通的管道，确保做出客户想要的东西，同时为后面的系统设计提供了基础约束。由于业务复杂，加上时间紧张，自己也弄过ps，就凑合了，最终效果也不错。
MS发布了个Windows Workflow Foundation Web Workflow Approvals Starter Kit，算是给了ASP.NET开发人员一个交待。
最近在做EPM，不过这个EPM没有用Project Server，却是完全用ASPNET + SQLServer搭建，这也是各种原因造就。不然利用 Project Server，一个小时应该可以搭建出一个简单却实用的 EPM 应用出来。恰巧上次和网友讨论过一些 MS 企业服务器产品的主要应用业务，这里也稍微整理下一些我接触过的MS服务器产品，不对的地方还请指正。
- Project Server: EPM
- SPS: Portal
- WSS: Team Work (Document Mgmt)
- BizTalk: EAI
- Commerce Server: EBusiness
- Content Management Server：WCM
- Exchange：Mail, Message platform
- LCS：IM
- MOSS：Portal+WCM+ECM+BI+Search+BPM
Workflow Foundation的问题确实很多，差点把我邮箱爆了，我无法解决所有问题，也无法一一回复。其实网上还有很多资料可以去查找，你可以到http://wf.netfx3.com/学习下载Sample，也可以下载最新的WIndows Vista SDK（内含.netfx3.0 SDK），看本《Essential Windows Workflow Foundation》，或者到 Architecture Journal 去下载06年7期“工作流主题”的杂志，最后有问题解决不了一定要到http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=122&SiteID=1这个Workflow官方论坛或者 SharePoint-Workflow http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1207&SiteID=1 去问，会得到wf相关开发者的回答的。下面从那论坛摘几个比较常见的问题：
- 复杂的审批问题：比较简单的审批问题就是让一个人专门进行审批，如果他批准则通过，拒绝则结束。但是现实中都是复杂的流程，但再复杂的流程也都可以拆分成简单的流程，所以，当很多人都想知道Workflow Foundation是否可以满足他们的工作流场景时，我都会说99%都可以。呵呵，当然具体实施碰到的风险因素按具体项目具体分析了。言归正传，复杂的审批流程一般可以归纳成下面3类：（假设给5个人同时分配一项审批任务）
- 领导一票制：5个人中的那个大老板批准或否决了，则该审批任务不管其他人如何，均按领导意思继续下面流程。
- 全票制：当且仅当5个人都批准或都否决，该审批才会结束并继续下面流程。
- 票数权衡制：5个人中3个人批准则当作批准，或者3个人否则则当否决处理继续下面流程。可以理解为超过50%，或者根据人员角色按一定的权重去处理后，按最终既定标准权重处理流程。
- 实现方法可以参考：
- State-Machine Workflow中的Parallel并行问题：
- Load Balanced负载均衡下的Workflow：
- Workflow 的版本问题：
- 从web.config中获取WorkflowRuntime实例：http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1200209&SiteID=1
- Tracking：http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1188418&SiteID=1
97年在BBS上文豪挥笔，98年Mud边武侠风云，99年OICQ里风花雪月，看着html大普及，asp搅动动态网站……一晃10年过去了。盖茨把他的口号从“A PC on every desk and in every home”进化成“Empower people through great software any time, any place, and on any device”，似乎也预示网络时代的到来。如今，单就web应用这块来说，技术层面的flash、ajax、wpf/e曾出不穷，概念层面的blog, wiki, tag, podcast, videocast等日新月异，呵呵，看得眼花缭乱。不过，在这么一个发展的历程里，也总是能找到几条发展方向，我简称之为三化。
- 用户体验个性化（体验）：对于普通用户来说，他只care体验，包括UI和Function。
- 技术体系标准化（标准）：对于平台商来说，他们应该会更care标准，许多专利都出自并握在他们手里。
- 应用领域普及化（随时随地任何设备上享受任何服务）：对于应用服务供应商，他们应该care互连互通，这可是他们吸引最大群体用户，创造最大利润的根源。
每个方向上都会因为各种利益而出现各种技术或理念，反过来各种技术和理念也基本都在这三个方向里进行验证决定其生死。
以前写了点关于活动目录的文章，收到很多的反馈和问题。由于时间限制，无法一一回应。近期在codeproject上找到了一篇关于活动目录API封装的文章，一时心动，就在其基础上进行了修改扩展（代码使用上除按原作者的要求外，其他可没任何要求）。经过修改扩展后的活动目录操作类，应该可以满足大部分需求了，相信大家使用起来也会比较简便的。下载地址：http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=93001c9d-194c-47ff-bc1a-e5ccd81d7e4a
Sample Code:
private void button1_Click(object sender, EventArgs e)
...{
// 获取 OU
ADOrganizationalUnit ou = ADManager.LoadOU("TestOU");
Console.WriteLine(ou.DistinguishedName);
// 获取该 OU 下所有用户(包括所有下级OU)
IList<ADUser> allUsers = ADManager.LoadAllUsers(ou.DistinguishedName, true);
Console.WriteLine(allUsers.Count.ToString());
// 获取该 OU 下所有用户(不包括所有下级OU, 仅该OU里)
IList<ADUser> subUsers = ADManager.LoadAllUsers(ou.DistinguishedName, false);
Console.WriteLine(subUsers.Count.ToString());
// 在 OU 下创建用户。并且激活该用户和设置用户帐号密码永不过期。
ADUser user = ADManager.CreateUser(ou.DistinguishedName, "通用名", "MyAccount", "MyPassword@1", AccountOptions.ADS_UF_NORMAL_ACCOUNT | AccountOptions.ADS_UF_DONT_EXPIRE_PASSWD);
// 在 OU 下创建组，该组默认为全局安全组。
ADGroup group = ADManager.CreateGroup(ou.DistinguishedName, "MyGroup");
// 把用户加入指定组里
ADManager.AddUserToGroup(user.AccountName, group.Name);
// 把用户从指定组里移除
ADManager.RemoveUserFromGroup(user.AccountName, group.Name);
// 禁用用户
ADManager.SetUserAccountOptions(user.AccountName, AccountOptions.ADS_UF_ACCOUNTDISABLE);
// 启用用户并设置用户密码永不过期
ADManager.SetUserAccountOptions(user.AccountName, AccountOptions.ADS_UF_NORMAL_ACCOUNT | AccountOptions.ADS_UF_DONT_EXPIRE_PASSWD);
// 获取用户所属的所有用户组
IList<ADGroup> userGroups = user.Groups;
foreach (ADGroup userGroup in userGroups)
...{
Console.WriteLine(userGroup.Name);
}
// 获取组里所有用户
IList<ADUser> groupUsers = group.Users;
foreach (ADUser groupUser in groupUsers)
...{
Console.WriteLine(groupUser.AccountName);
}
// 更新用户信息
user.Company = "User Company";
user.Department = "Sales";
user.Email = "myaccount@demo.local";
user.Mobile = "13333333333";
user.Url = "http://homepage";
user.ExtensionAttribute1 = "my custom info";
user.Title = "CAO";
// ......
user.Update();
// 删除用户和组和OU
ADManager.DeleteUser(user.AccountName);
ADManager.DeleteGroup(group.Name);
}
从关心发表的一篇joycode发帖统计随笔的关注中得到了一点想法。尽管博客堂一直在努力专注关注.NET开发领域的各类技术信息，但对各位看官来说，最重要应该不是在博客堂里能看到理论高深的文章或者各类信息发布文章，而是如何提高自我的信息汲取技巧，使得自己能在浩瀚的互联网信息中快速准确找到自己所要的内容。
我们就事论事。只要你是个.NET爱好者，那么你不会局限就关注博客堂一家，也许你会天天看MSDN，cnblogs或者codeproject等，你会在碰到问题就到搜索引擎上搜把，或者上论坛问看看。也就是说，在互联网这个世界里，信息是错综复杂的，即便是你非常喜爱的MSDN、博客堂、博客园等，你也不会每篇文章都去阅读，而是依自己的需要、兴趣去进行选择阅读的。所以，我觉得面对洪水般的各类信息，我们首先要做的并非抱怨，而应学会对信息进行选择、过滤、汲取乃至吸收。
废话多说了。我以.NET技术为例说说我是怎样获取信息的，仅供FYI。
- 首先确认你要获取哪方面的信息。
- 哪个技术专题。
- 编程异常问题。
- 环境配置故障问题。
- 开发难题。
- 其次确认你准备怎样去获取这些信息。
- 搜索引擎。google、msn search、yahoo等。
- 官方站点。各类技术的官方或半官方站点。
- 技术站点。MSDN、codeproject等。
- 技术社区或Blogs。博客堂、博客园、CSDN、msdn blogs等。
- 开源站或某个产品站点。sourceforge等。
- 最后善于结合上面两项列出的各类子项去组合获取自己所要的信息。
- 搜索引擎：信息关键字一定要准确，同时经常还辅以第二关键字甚至许多子关键字来缩小搜索范围。比如，想知道WCF(windows communication foundation)技术专题信息，你就直接在google上敲入windows communication foundation关键字进行搜索；碰到出现“执行xxx时错误异常，错误代码yyyyyy，错误信息：zzzzzzzz”，你就要知道关键字是什么了，在google上敲入xxxx yyyyy zzzzzzzz看看。如果没有，那扩大下范围就只敲入xxxxx yyyyy看看，还没有那再扩大或者选择其他关键字再试；对于技术难题等也要懂得找出关键字进行合理扩大或缩小的查找，一般你都会得到你所要的答案的。
- 官方站点：官方站点比较适合于你初学某项技术，或者你长期关注某个技术专题，或者你需要下载相关资料。比如你想学习windows communication foundation，那么http://wcf.netfx3.com/这个官方站点你一定要经常保持关注。一般做法就是先看该技术的整体介绍，如果你觉得自己需要掌握这门技术，那你就可以开始进行QuickStart和查阅相关Sample Code了。如果你只是想了解下该技术主要用于做什么或者架构性知识的话，你可以直接查看SDK或更深入介绍资料，一般这些资料都会从整体架构上讲解起的。
- 技术站点：技术站点主要用于自我学习和编程参考。你可以上技术站点查阅到目前最新的一些技术信息和发展趋势，也可以了解开发领域业界的相关信息，同时你需要一些具体的编程接口也可以在类似MSDN的站点找到所要的内容。这类站点又分为综合技术站点和专题技术站点，你只需要按照站点内部搜索或目录分类定位到自己所要或者感兴趣的内容部分即可。
- 技术社区或Blogs：这部分也主要分为综合性和专题性两块。对于综合性社区，你也只需利用目录分类、内部搜索等进行快速定位，再利用搜索技巧进行缩小范围即可。对于专题性社区，内容也是十分广泛复杂的，实际上也需要你去按照目录分类（如cnblogs的技术专题分类、地区分类、排名分类、热点分类等）去找到自己所需要的信息。
- 开源站或某个产品站：之所以单独列出，主要是当你需要完成一个项目或者产品，你找不到思路或需要了解下别人做法，你可以上这类站点去找下相关的产品信息，以寻求获取灵感。
一时匆忙所想，希望起到抛砖引玉作用，也希望大家能在浩瀚信息面前从容不迫找到自己所要的内容，正所谓“弱水三千，只取一瓢饮”。
在报文通信协议或者数据转换迁移这类应用中，不知您是如何组装报文，如何关联新老数据库字段的。因为之前我实施过这两类应用，在实施过程中逐渐萃取出了一个简单实用的类库（其实只是很简单的几个类，可以点此下载该类库，可以自己使用和商用，但请发email告知。），通过这个类库可以很便捷地进行通信报文的组装，新老数据库字段的映射，从而高效的完成目标功能。
该类库主要有四个类：MappingFieldAttribute、MappingField、MappingFieldException和MappingData。如下：
这里不再继续讨论类库设计什么其他的，这里面其实没多少值得称道的。这个类库本身存在的价值就在于让大家更简单更实用的完成报文组装、数据字段映射等工作，所以我尽量说下怎么快速使用这个类库。
对于报文或数据表，一般我们都有一个业务实体类与之对应。该实体类里的每一个成员字段或属性可以对应零个、一个或多个的业务字段，此时这种对应关系正是通过 MappingFieldAttribute特性标签来标识的。MappingFieldAttribute允许被多次使用在某个成员字段或属性上，同时被标识的属性可以由派生类和重写成员继承（也就是说可以搜索出父类和子类所有标有MappingFieldAttribute的字段属性出来，这点也很实用）。同时，所有使用这个类库的业务实体类都继承自MappingData类，这样才能自动拥有获取对映射字段的相关操作方法。
DemoPackage实体类中CustomerID属性及其映射规则：
/**//// <summary>
/// 客户编号。
/// </summary>
[MappingField("客户号", 20, false, 2)]
public string CustomerID
...{
get ...{ return _customerId; }
set ...{ _customerId = value; }
}
/**//// <summary>
/// 证件类型。A 为身份证，B 为护照，C 为军官证，0 为其他。
/// </summary>
[MappingField("证件类型", 1, false, new string[]...{"A", "B", "C", "0"}, 6)]
public string CreditType
...{
get ...{ return _creditType; }
set ...{ _creditType = value; }
}
可以看到MappingFieldAttribute有几个属性，分别为：
# 映射字段名称
# 是否必填
# 最小长度
# 最大长度
# 允许取值范围或集合
# 排序索引号
这些数据格式规则是从大部分映射关系中抽取出来的特征，这些特征都是具体某个映射字段所具备的基本特征。你可以通过这些特征严格控制映射字段的映射规则，保证不仅能够正常映射，同时能够准确映射。可以通过MappingData.EnsureValidation()或MappingField.Validate()对映射字段进行规则校验。
下面分别为快速输出目标Xml格式、报文格式和正常格式的代码：
/**//// <summary>
/// 输出 Xml 字符串。
/// </summary>
public virtual string ToXml()
...{
StringBuilder builder = new StringBuilder();
// 因为一般 Xml 的节点不需要排序，所以使用 GetMappingFields() 获取所有
// 标有 MappingFieldAttribute 特性标签的字段
Hashtable fieldTable = this.GetMappingFields();
builder.Append("<RequestParameter>");
foreach (DictionaryEntry entry in fieldTable)
...{
MappingField field = entry.Value as MappingField;
field.Validate();
string node = Utility.CreateXmlNode(field.FieldName, field.Value.ToString());
builder.Append(node);
}
builder.Append("</RequestParameter>");
string xml = Utility.InitializeXmlPackage(builder.ToString());
return xml;
}
/**//// <summary>
/// 输出通信报文。此处报文为固定长度的报文，不足长度需进行补足长度处理。
/// </summary>
public virtual string ToDatagram()
...{
StringBuilder builder = new StringBuilder();
ArrayList fieldArray = this.GetMappingFieldArray();
for (int i = 0; i < fieldArray.Count; i++)
...{
MappingField field = fieldArray[i] as MappingField;
field.Validate();
string node = string.Empty;
if (field.MemberType == typeof(int))
...{
// 如果是 int 类型，则在前面补 0，以达到规定的长度。
node = field.Value.ToString().PadLeft(field.Attribute.MaxLength, '0');
}
else
...{
// 如果不是 int 类型，比如 string 类型，则在后面补空格，以达到规定的长度。
node = field.Value.ToString().PadRight(field.Attribute.MaxLength, ' ');
}
builder.Append(node);
}
return builder.ToString();
}
可以看到，当实体字段越多时，利用本方案进行映射组装目标内容是非常便捷实用的。对于在数据转换迁移中，最典型的应用场景要算纵表结构导成横表结构。通过针对横表结构建立一个实体类，每个类成员字段属性都加一个或多个MappingFieldAttribute与纵表结构中的字段名称建立映射关联关系，最后就可以很方便利用这类库把数据从纵表中一一对应到新数据实体（对应横表结构）中，最后导入目标数据库。
当然，获取你还可以找到其他应用场景，相信你可以通过自定义扩充该类库而方便快速的实现你所要的功能。最后，记得给我发一份你的成果。J
前阵子花力气载下了Windows Vista Beta1和Visual Studio 2005 Beta2 July CTP两个共近6G的软件。因此，一载完自然就热血沸腾想安装上去瞧个究竟，以补偿漫漫长夜载东西的郁闷。这里我们先尝鲜Windows，看看Vista吧。
我是在我原Windows XP SP2上用虚拟光驱安装Vista的。Vista要求全新一个分区安装，不能在现有操作系统上升级安装。Vista的安装相对以前版本的Windows确实改进了不少，没有以前那么多的步骤和停顿。在复制好所有文件到硬盘后，系统进行了一次重新启动，然后进入Windows准备初始化。在出现Windows图标和Codename Longhorn文字后，突然硬盘没有了反映，屏幕保持进入Windows前的黑屏状态，而这又不是死机。经过我反复几次重启，现象依旧。我开始怀疑是不是虚拟光驱安装的问题，于是我重新进入WindowsXP，把虚拟光驱里的Vista所有文件拷贝到硬盘中某个目录里，准备从硬盘里安装。但是后来那个该死的Vista安装程序丢了个大大错误提示框给我：“stub loader for setup program has encountered a problem and needs to close”，这个说明从硬盘安装Vista似乎行不通，于是只好重新利用Virtual CDROM安装。但是为什么在看似一切都正常的情况下，会出现Loading Windows卡壳呢？
由于我的Vista虚拟光驱是在我的一个40G的USB移动硬盘上的，在复制好所有文件到电脑内置硬盘里后，也即Windows Vista开始初始化硬件和安装信息时，出现了卡壳。在一个偶然机会下，我面对着黑屏愤怒拔了移动硬盘，啊~，电脑内置硬盘灯一下亮了起来，Windows又开始继续Loading了，直至下面的全新的Vista界面出来。后来经我反复拔插USB移动硬盘，总是这种情况： 插入时Vista就卡壳，即使是已经在Vista里面了。而拔出时一切就又恢复正常。这不知道是不是Vista硬件支持不好，还是BUG？
进入Vista后，第一眼感觉就是黄绿色桌面背景和暗黑色任务栏搭配起来，看上去挺舒服的。打开左下Start菜单，发现所有程序已经不再是一个展开的二级菜单，而是直接嵌套在了Start菜单左边栏里了，显得更加专业，空间也更加紧凑。另外，注销和关机则相反多了一个小箭头，通过它可以拉出一个菜单，进行相应选项。比如Shutdown里有StandBy、Hibernate、Shutdown、Restart和最底下的Options菜单。这样我们就不必再类似WindowsXP点击Shutdown后出现一个对话框让你选择是关机还是重启等，而可以直接一步到位的选择相应操作，这点对于讨厌多余窗口的人来说，是个不错的改善。在这个Start菜单中你还会在Lock和Shutdown左边发现一个搜索栏和搜索按钮。这个改进，其实就相当于把任务栏里的搜索条或者IE浏览器中的搜索条也搬到了大家常用的Start里，也体现了Vista搜索无处不在的特征。
再转过来看下桌面，我设置在桌面上显示“我的电脑”等图标后（噢，等下，我的电脑现在不叫My Computer了，而直接称呼为Computer，相应的，My Document也叫Documents了。也许微软觉得没必要再强调My了，毕竟在这个处处互联的网络时代，强调个人PC时代的My意义也不太大了），哇～，桌面图标好大个，一种很粗旷的感觉。这点对于习惯于1024*768分辨率中的小巧图标的我来说，一下子适应不过来，老觉得好像是640*480分辨率一样，很不爽的感觉。不过很快我就说服自己适应这些硕大的图标了。
OK，现在赶紧打开Computer，出现了我们最经常使用的My Computer窗口。这个界面对于没用过Vista早期版本（即Longhorn前几个版本）的人来说，绝对是个Surprise！感觉中这类窗口似乎不是Windows窗口，而更像是在Mac，或者X-Window中的窗口。不过左下角Windows图标和Start字样才会让我们回到现实中，这确实是在Windows里。最顶上的后退和前进按钮和一个导航栏加以搜索栏让人瞬间明了目前方位。而此时的File菜单则被下降在标准按钮和导航栏下面，这点是在令人讨厌，尽管你不得不承认把标准按钮和导航栏放在窗口最上方能让用户立刻醒目明白目前自己所在，但是，你也不得不承认，这种挑战用户习惯的行为确实让人很讨厌，至少现在是。接着中间区域还是放着类似CDROM、HardDisk、Folder等常规图标，只是大家可以看到每个HardDisk分区都有一条进度条，让你通过图型方式更加明白目前硬盘的使用状况。而在窗口最下边，还多了一个显示Windows里文件夹、文件等类型对象的各种属性信息，比如创建时间、文件名称、作者等等。最让人拍奇的还是Rating和Keywords两个属性，似乎每个文件你都可以给它添加关键字让搜索引擎更方便查找，也可以给它评价个星级，和大家一起分享下5星级文件的感受。这个想法还是不错的，把原本一个一个冷漠的文件，一下子跟用户互动起来。对于Vista中的IE7.0，个人感觉一般。毕竟一个IE窗口多个Tab页的浏览方式，MyIE已经给过我们；而对于RSS浏览时套用默认样式显示也并非特别新鲜。毕竟在IE6发布后就遭撤的IE开发组，在面对RSS等新潮流后又慌忙组建，其应付的成分还是居多的。
接着看看控制面板Control Panel。控制面板改动也不大，就是增加了几个控制选项，和重新划分了控制类别。对于其中的网络功能，这里不得不再抱怨下。我用的是笔记本安装这个Vista的，通过安装以太网卡和无线网卡驱动也顺利识别了这两个网卡。于是接着自然就是为以太网卡分配一个IP地址和输入网关等信息，以让电脑能通过局域网访问Internet。不幸的问题就是，每次重设IP地址，按确定后都要重新启动操作系统才能正常使用这些新的IP地址，也才能顺利访问Internet。这种现象让人感觉一下子回到了解放前，回到了Windows98，令人费解。另外，对于能跑到WindowsXP的大部分应用程序，都可以在Vista上正常运行。而有部分应用程序就不能正常运行，比如我想用Vista玩《泡泡堂》时，就出现启动泡泡堂游戏程序时出错的现象。
总的来说，这些表层上使用感受，真正带给用户的便利的不是很多。因此，我想对于未来Vista发布后，要说服普通家庭用户升级到Vista比较困难，需要给用户一个升级的理由。而对于我们开发人员来说，Vista带给我的惊喜和享受就显得多得多。
Vista离我们还比较遥远，据说是2006年底才正式发布，这还是不包含再次跳票的风险估计。相对于Vista来说，MSN7.5，甚至MSN8.0就离我们稍微近些了。MSN7.5的测试版近期即将正式发布测试，而我们却已经可以通过一些途径获取到MSN7.5的中文或英文测试版了。这次新版的MSN7.5增加了一些小功能，诸如语音剪辑、动态会议背景以及重新设计过的界面及按钮。其中比较突出的是增加了语音剪辑和加强了语音的功能。恰好在MessBase.com上还进一步发现了未来MSN8.0和下一代Hotmail的截图，很是让人期待。让我们一起期待吧。
记得早些时候就在博客堂里看到toby在讨论关于桌面搜索方面的问题，那时候对桌面搜索的印象还很模糊，经过下载微软桌面搜索Beta版，试用了段时间才发现桌面搜索的“强悍”。后来发现Yahoo和google也有桌面搜索工具。不过，个人喜好还是Desktop Google
，因为在三者之间，一开始我就摒弃了Yahoo的桌面搜索，它相对于google和ms的桌面搜索工具来说，太过于繁琐复杂。换句话说，对于习惯进行快速检索信息的我，更倾向于简洁利落的外观。而在ms和google之间，选择google则要追溯到个人对Web Google情感问题了，毕竟爱屋及乌
。对于桌面搜索，难以避免都会想到个人隐私保护的问题。试想，如果使用了桌面搜索，可以让机器上全部内容被网络上的其他任何人查询访问到，那不是很危险？另外一个问题，使用desktop google，建立索引时占用了我几百M的硬盘空间，至今我还不知道它把那几百M以什么形式存放在哪里。幸好我硬盘空余空间还不算太小。
Visual Studio 2005开发小组最近贴了个帖子，大意是征求大家对VS2005中左边的工具箱和服务器浏览这两个Tab页设计外观上的意见。从实用角度上看，我觉得比较这个非常细微的外观似乎没有什么用处。但是，还是得钦佩他们的细心和对VS2005产品的认真负责。想到我们最终在使用VS2005时，每一个细微之处无不体现了设计开发人员的精益求精的“完美态度”，也会受到感染而充满激情。
ScottGu接受Channel 9的访谈录很是不错，访谈的内容为：
History of the ASP.NET project
XHTML and Accessibility Standards in Whidbey
New IIS7 architecture and design
Managed code and our philosophy for betting on it with ASP.NET
RSS and cool things you could do with it
Tracing/Eventing
Why Apache devs will like IIS7
App-Domains and how we use them
Lots more
今天38妇女节，祝所有女程序员节日快乐。博客堂里好像就只有Grace是女性同胞吧，祝她节日快乐。
微软总是喜欢“凑热闹”，在节日里，ms推出了一款被称之为游戏开发里的Visual Studio的综合开发平台——XNA。尽管目前还无法确切知道XNA更为具体的细节，但是既然微软想深入游戏开发领域，自然类似它在任何领域上一样，让人忽视不得。看看XNA页上Bill Gates的话就知道ms的激情了。
"Software will be the single most important force in digital entertainment over the next decade. XNA underscores Microsoft's commitment to the game industry and our desire to work with partners to take the industry to the next level."
- Bill Gates, founder and chief software architect of Microsoft
MSN7来了，这回可以看得出来这次微软下了番功夫了。用了Beta版本一段时间，看着MSN旁边正在建设中的社区、购物、交友等，就会想象着微软到底想在这里面放些怎样的东西？自己从头做？还是对其他相似产品进行收购或合作？不管怎样，未来这个集门户、Hotmail、Messenger、游戏等于一体的MSN7，确实会让腾讯等瞎忙一阵子了。
RSS也来了，而且和短信一块都跑进MSN里去了。看看这个MSNOK插件，确实让人感觉“博客通”的来头确实不小。
最后，msnok还搞了个rss大全，配合上面“博客通”。总体使用上感觉msnok的思路确实很好，日后肯定很有发展前途。
最近在看CommunityServer1.0的源代码，看到asp.net2.0中的MemberRole集合在其中，于是想去www.asp.net下载MemberRole的代码，结果发现找不到任何关于MemberRole的信息了，就这样消失了……只能看看Reflector里的代码结合Whidbey文档了解MemberRole了。
西游记是个团队项目。一个团队的核心是人，这些志同道合者聚集一起并对目标达成共识（西天取经），利用自身力量的同时依靠外部资源克服困难（81难），最终胜利完成任务。很多公司企业常常对内部员工或外部媒体说企业文化，他们却常忽略企业文化应该起源于公司上中下各级人员的核心精神共识，兴盛于企业整体团队运营项目过程中，传承于新老员工并最终体现于大至企业整体小至职员个人思维行动上。在管理范围里，企业都在追求企业文化，却忘了领导层和员工是企业文化的主体，造成“我们的企业文化是XXX……”永远停留在口头上的尴尬局面。
VS2005Beta1出来也有阵子了，最近才有空偶尔拿出来看看玩玩。大部分想接触ASP.NET2.0的人，大概都跟我一样，第一个问题是：ASP.NET2.0比1.x多了些什么？建议看下这篇《What's new in ASP.NET Whidbey》。如果你是1.x开发人员，看完那文章后还得做好心理准备：变化之大远远不是一篇文章能写出来的。就拿ASP.NET内部来说，你看看《ASP.NET 2.0 Internals》就知道其代码模型、编译、页面生存周期等等都发生了变化。外观来看，Master Page、验证控件、GridView等等新的或改进后的WebControls。在安全、缓存、数据操作、国际化等等都有了让人兴奋的改进。
就拿国际化来看，利用资源文件的方式创建一个多国语言版本的World-Ready ASP.NET Web Application，甚至可以不用编写任何代码就可以实现。你没有看错，我也没有说得太离谱。在ASP.NET1.x里，要完成这个功能是比较费劲的。ASP.NET 2.0里，利用资源文件本地化一个WebApp有两种方式：Explicit Localization（显式本地化）和Implicit Localization（隐式本地化）。Explicit Localization针对Application-Level Resources（应用程序级的资源文件。这些手工创建的资源文件存放在根目录下的Resources子目录里，Resources目录类似Code目录为ASP.NET2.0里WebApp的特殊目录。），而Implicit Localization则对应Page-Level Resources（页面级的资源文件。这些资源文件存放在LocalResources特定目录里。）
- Explicit Localization的资源绑定格式：
<%$ Resources:[filename prefix,]resource-key[,"designerdefault" %><%$ Resources:[filename prefix,]resource-key[,"designerdefault" %>
例如： <asp:Button ID="Button1" Runat="server" Text="<%$ Resources: ClassName, ResoureKey, Default value %>">
用代码读取资源：
string ApplicationLevelResource = (string)GetAppResourceObject("ClassName", "ResourceKey");
或者直接：
string ApplicationLevelResource = Resources.ClassName.ResourceKey.ToString();
- Impilicit Localization的资源绑定格式：
<asp:Label ID="Label1" runat="server" meta:resourcekey="LabelResource1" />
用代码读取：
string PageLevelResource = (string)GetPageResourceObject("LabelResource1.Text");
[提示]：打开一个.aspx页面，点Tools菜单上第一项Generate Local Resources，整个WebSite将自动增加LocalResources文件夹，并自动为每一个.aspx页面创建一个resx文件，对页面内部控件自动增加 meta:resourcekey 属性。
本地化具体操作步骤细节及具体编码，你可以参考：
从上面链接中，你也可以看出，有两个官方性质的站点是非常值得收藏的：
近些日子也听说VS2005 Beta2要到明年才能出来了，ASP.NET Group Program Manager先给了我们ASP.NET2.0在Beta2中将会有什么变化的信息。OK，明年的事明年再说吧。
推荐篇开发高性能ASP.NET应用程序的文章〈Developing High-Performance ASP.NET Applications〉作为这段的结束。希望上面的ASP.NET信息对你有所帮助。
对于这样的信息〈演算法安全加密功能露出破绽（MD5） 密码学界哗然〉，不知道你看了有什么感受？我的反映通常是看着惊讶，想着可怕，最后还是不管它。J 当然，如果事情真如文章所说，那么我们唯一能做的就是改进改造它或重新找其他的加密算法了。
