文武之道，一张一弛

第二天几乎没有什么进展，上来就碰见了问题。

我是一台服务器上面做的服务器场模式安装的WSS3.0，SQL使用本机的2005标准版。服务器上带DC和DNS。

在安装完毕初始化以后，按照联机的帮助，启动搜索服务。服务帐号和内容访问帐号都是域administrator，但是出现错误提示信息“此服务器不是该搜索应用程序的索引器”。我找了一下，没有发现WSS里面配置应用程序的索引器的地方。

我接下来创建了Web应用程序，在创建站点集的时候，出现“因为服务器当前的配置不支持，所以无法显示该页。若要执行此任务，请使用Stsadm.exe中的命令行操作”。我在命令帐号测试了命令“stsadm -o createsite -url http://s1.zc.intra -owneremail wss@zc.intra”，提示错误“指定的域不存在，或无法联系。<异常来自 HRESULT:0x8007054B>”

问题发给了一些朋友，都还没有遇见过这样的问题。郁闷阿，在网上在搜搜看吧！

昨天微软网站上面终于可以下载正式版的WSS3.0的SDK了，我的WSS之旅也开始了。学MOSS（SPS）是要先学的WSS的，这个是我的在SPS学完的体会。WSS是MOSS和SPS的基础，同时WSS的免费也使WSS的使用面积更大。

这次不是第一次安装WSS3.0。在WSS3.0刚发布的时候，就装了一次，朋友们翻看前面的Blog会看到。第一次安装的时候使用的是简单模式，也就是安装程序会自动地使用独立服务器的模式，同时还会安装一个Micro版的SQL Server2005。但是那种方式好像默认不能使用域帐号，自动使用本地帐号了，除非你在没有本地帐号的系统上面来安装（比如域控制器）。

这一次我是用的高级安装，之后会提示是Web前端服务器还是独立模式。我想上次按照独立模式安装了，这次就选的Web前端服务器模式安装的。Web前端模式开始会提示运行服务的账号是什么，为了避免麻烦，使用管理员账号。接着提示选择创建服务器场，还是使用存在的服务器场，这一点根据SPS2003的经验，应该是创建服务器场。然后填数据库服务器，我的VPC里面装了一个SQL 2005的标准版，就使用本机的SQL Server。在之后就使验证模式，我选的NTLM，这主要是我开分不清两种的区别，看提示以及SPS2003的经验，NTLM似乎会简单一些，那就选简单的。再往下会让人选择本地账号模式还是域帐号模式。我选择的域帐号模式，我把这个VPC做成域控制器了，他接下来会提示用于WSS的帐号会放在哪一个OU里面，我创建了一个SharePointOU。这里说句题外话，这点看似体贴的服务，实际也不是很好，如果域控制器上面的要使用的WSS的帐户在不同的OU怎么办？也许后面还有解决的办法，但是现在看起来有点莫名其妙。再后面安装还有什么步骤想不起来了，应该是就开始那9个安装步骤了。

安装好之后看了一下SQL里面的表，比SPS要好得多，除了配置数据库之外，管理中心网站只创建一个数据库。这样使得直接从数据库备份简单了许多。

打开WSS3.0管理中心，我没有继续深入做配置，而是先打开了帮助文档。根据WSS3.0beta2时候的经验，WSS3.0的服务器场还是和SPS2003的服务器场有相当的区别的。简单看了一下，需要做的配置如下：

• 启动搜索服务
• 创建Web应用程序和网站集
• 创建备用访问映射（如果只有一个Web前端就不必了）
• 配置传入电子邮件设置
• 配置传出电子邮件设置
• 配置工作流设置
• 配置诊断日志记录设置
• 配置防病毒保护设置

现在的WSS3.0真是和WSS2.0不可同日而语，简直就是一个SPS2003的.NET3.0加WF的版本了，有服务器场，有索引服务，还有搜索，了不起。今天的时间不早了，明天再慢慢消化WSS3.0的文档，消化完以后继续写...

中文SPS2003发布的时候，正值2003年，.NET Framework 1.1和Windows Server 2003刚刚发布不久。但是随着.NET Framework 1.1的补丁不断出来，以及Windows Server 2003的补丁不断推出，即使SPS2003也不断推出补丁，但是还是有一些著名的小问题。比如中文的SPS2003的管理界面都变成了英文的界面。

这个问题估计可能不是SPS2003的问题，因为SQL Server 2000 Reporting Service也有类似的问题，解决的办法也是一样的。我最早发现这个问题是在2004年，当时.NET Framework 1.1 SP1刚刚发布。咨询微软的工程师，得到了support网站的一篇文章。文章里面讲由于.NET Framework 1.1 SP1的某些安全改进影响了.NET Framework 1.1的i18n解决方案，导致SPS2003的管理界面变成了中文。解决办法很简单，在创建的网站的web.config文件属性的“安全”里面，添加一个“Everyone”，并赋予“完全”的权限。这个方法在某种程度上会降低安全性，但是具体会带来什么危险，我也不清楚了。

最近，客户和我反映管理界面还是经常变成英文的，用上述的方法改一下，过一段时间就又会自己的变成英文的。我自己试了一下，发现上述的方法好像跟本不起作用了。我向客户了解了一下，最近对SPS2003做过什么处理，结果是客户最近部署过自己开发的WebPart，在web.config里面添加过SafeControl。我看了一下，发现web.config文件的编码被改成ANSI的编码了，修改为UTF-8编码以后，不用修改权限，管理界面就恢复中文了。再仔细研究了一下用户的使用习惯，她总是先下载web.config文件，用UltraEdit编辑以后，在上传回去。问题就出在UltraEdit，它在保存文件的时候，并不保持文件原来的编码格式，而是默认使用当前系统的默认编码(GB2312)来保存。不知道这个是UltraEdit的功能还是缺陷，或者其他人汉化导致的。

Reporting Service的问题也是类似的，我们做过一个安全插件，编辑过他的两个虚拟目录的config文件。把这些congfig文件的编码和权限调整过来以后，Reporting Service的管理界面也恢复正常了......

我在这里向大家推荐Editplus2编辑器，韩国人开发的，相当不错，支持在ftp里面直接打开，还可以另存到ftp上面。只不过好像国内没有代理商......

最近一直在做一个项目，以SOA为理念基于SPS2003的三个应用系统。后端以WebService提供服务，前端为嵌入SPS的UserControl，WebService与UserControl之间由序列化的对象进行通讯。由于开发环境是VS.NET 2003，所以就直接使用VSS6d来管理代码了，结果问题就跟着来了：VSS6d不支持UTF-8编码的程序文件以文本方式储存，否则就只能二进制方式存储。在开始阶段主要是开发WebService并没有什么问题，但是随着大量的UserControl开发出来并部署到SPS2003当中的时候，测试人员报告界面乱码。手工把ascx文件转换成UTF-8编码后，问题消失。

这样貌似问题解决了，但是以后每次重新编译部署的时候，都要把上百的ascx文件的编码手工修改一遍。修改编码成了一个极其繁琐的体力劳动......自己研究了一下，又请教了一下微软的工程师，有三个解决方法：

1. 在备份以后，重新把代码加入VSS的代码库，使用二进制方式存储代码。这会带来两个问题：一是二进制方式存储，在不同的代码版本之间不能做Different操作，二是二进制方式存储不再是层量存储，每签入一次，保存的都是一个完整的副本。
2. 使用VS2005 TFS来做代码管理。这需要在VS.NET2003内安装TFS的插件。这种方法微软网站上面介绍过，没有实践过。
3. 使用批量转换工具将ascx的编码转换过来。

我的项目现在只好使用第三种方式，但是找不到有批量的GB2312转UTF-8编码的工具，我只好自己写了一个。这个工具内部的转换引擎是GNU的libiconv，大家可以下载我编译好的版本直接使用，或者下载源代码自己研究。这个工具用.NET2.0写的，所以运行需要.Net Framework 2.0 Runtime。

细心的朋友会问我，为什么我只强调了ascx为什么没有提asmx呢？我当初也奇怪这个问题，后来研究了web.config文件里面的system.web段的globalization的fileEncoding属性约束了ASP.NET从本地读取程序文件的编码。在默认的ASP.NET项目的web.config里面是没有这个属性的，ASP.NET默认会以Windows的默认代码页来读取程序。而我们的asmx文件内部没有中文，即使有中文，ASP.NET也可以识别出来。

但是SPS2003创建的站点里面的web.config文件里面的system.web段的globalization的fileEncoding属性为"utf-8"。我测试了一下，这个属性删除以后，SPS也会有莫名其妙的错误，看来还是不能删除的。

今天上午WSS3.0提供下载了，中文版也一同发布了。正好手头有一个.NET Framework 3.0的虚拟机，立刻就把这个东西装上了。感觉不错。安装过程很顺畅，没有BETA2时候安装不长的问题了。安装过程和MOSS2007 BETA2的安装过程很像，但是缺一些东西，估计这些就是区别。

现在发现的和MOSS2007的区别是MOSS2007独立模式安装的时候，会安装一个SQL Server 2005的Express版的引擎，这个引擎可以通过标准的SQL Server 2005的管理工作室进行管理。而WSS3.0独立模式安装的时候，数据库引擎是一个SQL Server 2005的嵌入版。在使用SQL Server 2005的管理工作室的实例列表当中可以看到他创建的实例，但是不能连接，提示“引擎不提供远程连接功能”。估计这就是SQL Server 2005的Express版和嵌入版的区别所在，还有就是嵌入版默认的安装位置是%windir%\SYSMSI目录。我是第一次知道有这样一个SQL Server 2005的版本存在，需要研究一下这个版本的特性。

WSS3.0的内存消耗堪称一流，我的机器上除了企业版的SQL Server 2005以外，就是这个WSS3.0和其附带的嵌入版的SQL Server 2005了，这个时候内存占用达到了850兆。不知道MS怎么想的，这个内存的消耗是在太大了，虽然现在内存便宜，工作组服务器也不贵，但是这样的内存消耗也太大了点...在虚拟机里面有点实在吃不消了。

在前两天随.NET Framework 3.0一起发布的VS.NET 2005的WSS3.0扩展是个很不错的东西，除了带有Webpart模板意外，还能创建站点定义。这个可以看看陈曦的blog里面的描述。

前面一段时间我的blog里面的文章少了，但是随着.NET Framework 3.0和MOSS2007的到来，各样的文章会如潮涌一样上来的...敬请关注

准备分两次介绍MOSS2007beta2单机开发环境的创建，第一部分主要是基本的创建过程，第二部分是主要是由beta2升级到Beta2TechRefresh的过程。

看我Blog的人，大约都已经看了kaneboy和ocean的介绍了，但是我还是要说说我创建MOSS2007beta2开发环境的创建，主要我觉得他们的写的过程，我觉得并没有把所有的事情都讲清楚。我的文档是根据英文的Deployment Guide for Office SharePoint Server（Office SharePoint Server部署指南，简称MOSS部署指南）实践后编写的，但不是单纯的翻译。我假设我的读者熟悉Win2003的管理和熟悉ASP.NET2.0的开发，这样我可以把MOSS部署指南当中叙述很详细的过程描述简化。

1. 下载需要的文件。除了需要MOSSbeta2的安装部件以外，如果单机开发环境还要做域控制器的话，那么还要下载一个补丁。这个补丁需要在MOSS安装完毕，配置向导运行成功以后执行。可以修正在域控制器上安装单机环境浏览报错的问题。
2. 我们可以准备一个VirtualPC或者一个真实的PC。这个PC要安装好Win2003的任何一个版本，为其安装配置好AD、DNS、应用服务器（启用ASP.NET）三个角色。然后打补丁SP1。接着我们需要安装.NET Framework 2.0 运行时部件和Windows Workflow Foundation 2.2(简称WWF)运行时部件。
3. 接下来我们开始安装MOSS。在添加完序列号以后，系统会提示我们用Basic还是Advanced方式安装。Basic是默认使用Stand方式安装，默认C盘为安装路径，同时在配置向导运行时，还将默认创建一个的MOSS网站和相应的Web Application。Advanced则全部需要自己手动设置。我们这里选择Basic。后面只需要逐步点Next就可以将MOSS安装完毕。安装完毕以后，可以根据需要安装对于域控制器做MOSS服务器的补丁。
   注意：我们没有安装SQLServer2005,这是因为MOSS的安装程序在Basic模式下会自动安装一个SQLEXPRESS，并默认一次数据库作存储。
4. 在测试以后，我们可以开始Office2007beta2和VS2005安装开发环境了。安装Office2007beta2就不详细介绍了。然后我们可以选择任何一个VS2005的版本，除了VS2005Express的版本以外。安装的时候我们可以只选择VS2005的最小版本，比如只安装最小的VistualC#.Net环境。接下来可以安装WWF的VS2005设计组件。这时一个基本的MOSS2007beta2的单机开发环境就已经做好了。

使用Basic模式虽然可控性比较差，但是我们可以通过这个快速的建立MOSS2007beta2的开发环境。此外这个环境大约需要1.5GB的内存，如果不需要开发环境大约1GB内存就足够了。如果要在VisualPC当中做的话，则宿主需要至少2GB以上的内存。

我们知道，WinFX被重新名为.NET Framework 3.0。可见WinFX对于.NET Framework的重要性，虽然我认为3.0和2.0之间的间隔似乎太短了，但是WinFX作为.NET Framework 3.0来讲，当之无愧！

为此，WinFX有了自己的网站：http://www.netfx3.com 。同时，WWF的网站也变为了：http://wwf.netfx3.com 。在这个网站里面，除了我们熟悉的WWF、WCF、WPF以外，还多出来了一个Windows CardSpace(WCS)，这是一个什么呢？

鉴于WinFX重新命名为.NET Framework 3.0，以及原来WinFX以及其部件WWF、WCF、WPF有着众多的针对VS2005的扩展，根据.NET Framework 1.0 到 .NET Framework 1.1的升级伴随着VS.NET2002到VS.NET2003的升级，我估计在.NET Framework 3.0的正推出，VS2005会有一个新的本版或者一个大扩展包或者一个ServicePack的产生。随着各种各样的VS2005的扩展插件的产生，VS2005越来越像是一个半成品。

让我们静静期待下一个完美的VS的到来吧！

这个两者似乎并没有关系，但是事实上确实有联系还有很大的关联。下面描述的事情是发生在我身上的：

我的Blog和我在CSDN的Blog都是基于ASP.NET技术的Blog，我的是DasBlog，CSDN是.Text。他们的共同点就是都是使用UTF-8编码，这样Cookies也都以某种编码来存储。具体是什么编码，有待查阅一下RFC文档来考证一下。我们在回复某篇Post的时候，会有一个选项问你“是否保存回复信息”也就是你的nick和mail、site之类的信息，如果你选择了保存，则会在cookies里面做相应的记录。

带来麻烦的就是这个cookies。在我们的浏览器每次连接http服务器的时候，如果浏览器没有屏蔽cookies的话，你的在这个网站的cookies会自动地发送到服务器端，这样你保存在cookies里面的nick、email和site信息就会被自动填充的回复的那几字段当中。而http的连接是要通过防火墙的，加入你的防火墙不能识别你的cookies的编码的话，他将对你的http数据包内的数据误判。而且我们每个网页的会又多个request来完成，这样每个页面显示完全的话就需要多个连接或者并发多个连接。而防火墙在多次误判http数据包内的数据以后，就会判定这是一次攻击，而不是网络传输的错误。这样你的IP立刻就会被封掉。我的服务商给我的防火墙封ip的理由是 Http_cookies overflow攻击，引证我的判断。

我会把我的这个发现提供给服务商，请他们来调整防火墙。他们的防火墙使用的是BlackICE。很早就用过这个防火墙软件，当时就觉得这个防火墙很牛，可以做到很安全，但是作为服务商来使用的话，似乎防火墙规则太苛刻了。

报表服务允许在报表当中内嵌代码，也允许报表引用定制的程序集。内嵌代码要求是VB.NET编写的代码，而引用的定制程序集没有限制，在codeproject上面甚至看到有人调用包装了COM的定制程序集。

本文的注意力不在内嵌代码上，因为内嵌代码相对引用定制程序集简单，功能也要弱一些。我们的注意力着重在报表如何引用定制程序集，以及这样的报表如何部署。

在报表中如何引用定制程序集

在报表的数据或者布局视图点击“报表”菜单->“报表属性”项会出现如下的窗口：

在点击“...”按键选择要应用的程序集。如果使用对象的静态成员，可以应用以后直接使用。如果对象需要实例化以后才能使用，则需要在窗口下半部分的添加类名和准备使用的实例名。静态成员可以直接以“myNameSpace.myClass.myFunction()”的方式来执行，如果不是静态成员，则要以“Code.myObject.myFunction()”方式来执行。其中myClass是类名，myObject是实例化以后的实例名。

部署引用的定制程序集

部署应用的定制程序集有三个步骤：

1. 将引用的dll添加到报表设计器和报表服务器的bin目录，具体来讲就是报表设计器的C:\Program Files\Microsoft SQL Server\80\Tools\Report Designer和报表服务器的C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\bin。
2. 编辑C:\Program Files\Microsoft SQL Server\80\Tools\Report Designer目录下的rspreviewpolicy.config文件和C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer目录下的rssrvpolicy.config文件。在“<CodeGroup>”节点下添加相应的“<CodeGroup>”节点：
   <CodeGroup class="UnionCodeGroup"
        version="1"
        PermissionSetName="FullTrust"
        Name="MyCodeGroup"
        Description="Code group for my data processing extension">
        <IMembershipCondition class="UrlMembershipCondition"
             version="1"
             Url="C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\bin\RSAddition.dll"
        />
3. 编辑C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer下的web.config文件。修改<system.web>节点内的<trust>节点为<trust level="Full" originUrl="" />。

此方法适用于SQL Server 2000 Reporting Service SP2和SQL Server 2005 Reporting Service。但是不适用于没有安装过ServicePack的SQL Server 2000 Reporting Service。

在报表当中使用引用的定制程序集

在数据视图中使用

数据视图当中的对象主要是DataSet。要如何在DataSet当中使用应用的定制程序集呢？首先我们可以在DataSet当中使用参数，这个参数不是报表参数而是DataSet参数，之后我们在DataSet属性的参数页当中设置参数调用应用的定制程序集。

在设计视图中使用

在设计视图中使用相对比较简单，我们只需要在相应的表达始终按照“在报表中如何引用定制程序集”一节中说明的使用方法就可以了。

使用了一下，发现mojo还可以支持LDAP的验证！暗想，那这岂不是可以支持AD了，看来需要好好研究一下mojo的代码了...中文版的mojoPortal 2.0进行中...

最近因为线路稍微稳定一些了，所以想把vegetusoft.com的网站做起来，于是在网上找了几个免费的.NET下的CMS软件，最后选中了mojoPortal。开始就对mojoPortal兴趣，是因为他的界面我比较喜欢，但是后来发现他的功能也很不错。但是用了以后发现问题还是很多，比如对双字节支持的就不好。不过这些作者都留了接口，所以修改语言config文件和SQL脚本就可以了。

由于作者的这个版本是.NET 2.0的，所以我还准备试试能不能使用SQL Express当作数据库...等我的好消息！

我在使用CredentialCache的Add方法的时候，不知道其他的几个authType怎么来写。在Google的帮助下，从微软的Support网站找到一些提示：

"Basic"：基本身份认证（明文传送用户名和密码）

"Digest"：Windows域服务器的摘要式身份认证

"Negotiate"：Windows集成身份认证（至少在这种认证方式下可用）

希望对调用有身份认证要求的WebService的朋友有帮助！

从起航的Blog上面摘来的，顺便测试一下Trackback。

中国电话号码验证
匹配形式如:0511-4405222 或者021-87888822 或者 021-44055520-555 或者 (0511)4405222
正则表达式 "((d{3,4})|d{3,4}-)?d{7,8}(-d{3})*"

中国邮政编码验证
匹配形式如:215421
正则表达式 "d{6}"

电子邮件验证
匹配形式如:justali@justdn.com
正则表达式 "w+([-+.]w+)*@w+([-.]w+)*.w+([-.]w+)*"

身份证验证
匹配形式如:15位或者18位身份证
正则表达式 "d{18}|d{15}"

常用数字验证
正则表达式 
"d{n}" n为规定长度
"d{n,m}" n到m的长度范围

非法字符验证
匹配非法字符如:< > & / ' | 
正则表达式 [^<>&/|'\]+

日期验证
匹配形式如:20030718,030718
范围:1900--2099
正则表达式((((19){1}|(20){1})d{2})|d{2})[01]{1}d{1}[0-3]{1}d{1}

ASP.NET成员为你提供了一套内置的验证和存储用户信任的方法。因此，ASP.NET成员可以帮助你在你的Web应用当中管理用户验证。你可以在Forms验证的时候使用ASP.NET成员，也可以在通过登录控件来创建一整套用户管理系统。

ASP.NET成员轻松支持如下特性：

• 创建用户和密码
• 在微软SQLServer、AD或者其他数据源当中存储成员信息（用户名，密码和其他数据）
• 鉴别访问站点的用户。你可以按照自己的意愿鉴别用户，也可以通过ASP.NET登录控件不编写代码或者很少编写来创建一整套用户鉴别系统。
• 管理密码，包括创建、更改和重设密码。依赖于你设置的membership选项，membership系统提供自动实现基于用户提供的问答来重设密码的实现。
• 为鉴别过的用户提供一个唯一的标识，以便你能把这些标识应用在你的应用系统的个性化和规则系统（授权）系统当中。
• 定制特殊的成员provider，允许你用自己的代码替代并管理和维护存储在定制数据存储中的成员数据。

成员，规则和用户配置

虽然成员是ASP.NET用户鉴定的一个半独立特性，但是它可以与ASP.NET规则管理整合，以此为你的站点提供授权服务。成员也可以与用户配置相整合，以此提供针对用户的特殊应用细节。详细内容请参考“使用规则管理授权”和“ASP.NET配置属性”。

Membership如何工作

如果要使用成员，必须首先在站点中配置。大体上需要如下的步骤：

1. 在你的站点配置添加成员配置参数。默认情况下，成员是被打开的。你也可以指定自己使用的成员provider。（对于实践的时候来讲，就是指定你想用以保存用户信息的数据库。）默认的provider是微软SQL Server数据库。你也可以选择AD来存储成员信息，或者你自己指定一个特定的provider。如果要得到更多关于在你的ASP.NET应用的Web.config文件中配置成员的信息，请参考“配置ASP.NET应用使用Membership”。
2. 配置你的应用使用Forms鉴别（区别于Windows或者Passport鉴别）。你代表性的可以指定应用中的某些页和文件夹是受保护的，只有经过鉴别的用户才可以访问。
3. 定义成员的用户帐号。你可以通过两种方法完成这个步骤。你可以使用Web站点管理工具提供的向导页面来创建新用户。你可以通过ASP.NET页来自己收集用户名、密码（邮件地址可选），然后使用成员功能提供的“CreateUser”方法在成员系统当中创建新用户。

你可以在你的应用当中使用成员鉴别用户。大多数情况下，你需要提供一个登录窗口，他可以是一个隔离的页或者隔离的文件夹。你可以使用ASP.NET的TextBox控件手动创建登录窗口，也可以使用ASP.NET的登录控件。因为你配置应用使用Forms鉴别，所以当用户在访问受保护的页面的时候，ASP.NET将自动显示登录页。

注释：ASP.NET的登录控件（Login、LoginView、LoginStatus、LoginName和PasswordRecovery）包含了所有的事实上需要的所有成员系统的受信任用户的提示和验证用户信用的逻辑。

如果你使用登录控件，这些登录控件将自动使用成员系统来验证用户。如果你自己手动创建一个登录窗口，你可以提示用户提交一个用户名和密码，然后调用ValidateUser方法来执行用户确认。在用户被确认以后，用户的相关信息可以一直在Forms鉴别当中使用（例如：如果用户的浏览器接受cookies，将使用加密的cookie）。登录控件将自动执行这个任务，如果你手动创建登录窗口，你必须调用FormsAuthentication对象的方法来创建cookies，并写入用户的电脑。如果用户忘记了他的密码，登录窗口也可以调用成员的功能来帮助用户可以回忆起密码或者创建一个新的密码。

译者前言
ASP.NETv2与前一个版本之间的一个比较显著的区别就是添加了membership管理。这个是一个显著的特性。希望可以通过MSDN里面的这一篇"Managing Users by Using Membership"来打到抛砖引玉的作用。本文的版权属于MSDN。转载译文请标明出处来自于http://blog.zhangchi.com.cn 。

原著前言
ASP.NET成员可以使你的Web应用有效的管理用户信息。它提供了一些功能，诸如：确认用户，创建和修改成员用户，和管理用户的密码、电子邮件地址之类的用户信息。ASP.NET成员主要用在ASP.NET的Forms验证，但是也可以使用在Web应用的任何地方。

ASP.NET成员使你可以管理你的应用用户验证，并将信息存储到你的数据源当中。因为ASP.NET成员用户提供了成员数据的数据源，所以你不比扩展任何代码就可以读写用户信息。

ASP.NET成员主要有内置的成员Provider组成，它与数据源通信，并由静态的membership对象暴露出成员Provider的功能。你可以在你的ASP.NET代码中调用membership对象来执行用户的确认和管理。

• 内容目录
• Membership的介绍
• 对照Membership与Windows和Passport验证
• Membership对象
• Membership Provider
• 配置ASP.NET应用使用Membership
• Membership的安全性
• 实现一个Membership

上次向飞鹰推荐了Yet Another Forum论坛，但是飞鹰没有用。他不用没关系，我用。我在现在实施SPS的项目中，客户不满意SPS的讨论版。我本来想使用ASP.NET Forum 2，但是现在发现她变成商业的了，于是我们决定使用Yet Another Forum，它是GPL的。开源+免费有什么不好？

YetAnotherForum的域整合非常简单，首先要在安装一个非域验证的实例，在选择管理员账号的时候比较有技巧：帐号最好和将来域里面准备作为论坛管理员的账号一致。这样做是为了在与域整合以后不用再调整论坛的管理员了。其他的安装可以按照软件包里面的说明进行。

在非域验证配置完成以后，我们开始进行域整合的配置。我们需要修改Web.Config，将验证方式改为

<authentication mode="Windows">
</authentication>

然后修改IIS关于这个应用的验证方式为Windows域服务器的摘要式身份验证，同时将你论坛程序所在的目录赋予读/执行/列表权限给相应的域用户。

这样在你再次访问的时候，你就会发现已经能像SPS一样整合使用与账号了。而你当初指定的那个账号会自动变成管理员了。这样你就可以开始你的其他论坛配置了。

我现在的项目是一个电信企业的企业门户，使用SPS2003来搭建。为此项目专门申请调配了一个内存1GB+256MB的PC做服务器。

做这个开发环境有两个方案，一个方案是所有的软件安装都安装在这个物理服务器上面，另一种方案是在这个PC上面做若干个虚拟机，模拟真实的环境。

首先说说第一个方案。第一个方案需要将这个PC安装win2003系统，并建成主域控制器。安装应用服务器(IIS+ASP.NET)，之后还要代开SMTP和NNTP，然后再安装Exchange2003、SQL2000+sp3。最后就可以安装SPS2003了。值得注意的是，安装应用服务器的时候不能安装Frontpage扩展，这个扩展和SPS2003有冲突。

这个方案的优点是速度快、一台服务器便于移动，然而缺点却比较多，。这个PC应为自己作为主域控制器，所以不适合（不等于不能）再加入现有的域。同时这个PC不容易管理，Win2003的终端服务器必须有终端授权证书服务器才可以不限时间的运行，但是即使是免激活的开放许可Win2003里面的终端证书服务器也是需要激活的，电话激活或者互联网激活都比较麻烦（需要开放授权的ID）。否则就要使用其它的远程管理软件，会产生其它的费用。如果将来有新的服务器或者PC调配过来，软件迁移到其它的服务器很麻烦。

再说第二个方案。这个方案的是将所有的软件都安装在虚拟机里面。宿主服务器的操作系统可以选择Win2003或者Linux。如果宿主服务器是Win2003，那么虚拟机软件必须是Visual Server 2005。如果想要宿主服务器使用Linux，可以直接使用VMware ESX Server，它内置一个定制的Linux系统，可以安装在无系统的主机上面。VMware ESX Server和Visual Server 2005比较，主要是强在VMware可以设置虚拟机具体使用几个CPU，和具体使用哪个CPU。

我现在使用的就是第二个方案。建了两个虚拟PC，第一个虚拟PC作为域控制器，安装了Exchange2003和SQL2000+sp3，分配了256MB内存。第二个虚拟PC只安装了SPS2003，分配了512内存。

这样做的优点是都可以通过Web远程管理，同时自带远程管理工具和虚拟终端。VMware ESX Server的虚拟终端可以是任何VNC软件，而Visual Server 2005的虚拟终端叫 VMRC（Virtual Nachine Remote Control Client），不需要单独的授权。虚拟机搬迁起来也很方便，将虚拟机的配置文件和相应的虚拟硬盘文件搬迁到新的服务器然后导入虚拟机就可以了。缺点就是速度比物理服务器实现的慢，相应对宿主服务器的硬件要求要高！

这两种方案各有千秋，可以用在不同的时候。比如我在去帮助市场人员做售前给客户演示门户系统的时候就是使用的第一种方案，将所有的软件装在了一个1G内存的笔记本电脑上面。而我们在内部开发的时候使用的就是第二种方案，毕竟服务器的速度要比笔记本电脑快的多。

找到的一个窍门，不让vpc弹出内存不够的对话框，强制开始了我的.NET2的试用过程。

安装完express的环境，立刻就有了一个感觉，express系列是对WebMartix的风格延续。vcs主要针对Windows的应用，vwd专门针对Web应用，此外vwd还支持多种语言开发（c#,vb,j#）。

在看过JohnnyHu的VC# Express vs Enterprise以后，发现差别还是不小的，决定找一套Enterprise来，只是公司的微软联系人在休产假，不然我现在已经开始download了。

vwd里面有一个新东东吸引了我的兴趣，在这里的ASP.NET页面中可以添加WebPartZone,而且可以向这些Zone中拖入WebPart。笔者我现在的工作就是带领一个team开发SPS上面的WebPart。如果这些工作可以服用的话，那么就不要说代码复用了，我们的二进制程序也可以复用了，一个字，“太爽了”！

由于在MSDN中还没有找到有关这一部分的资料，所以今天的试用体会就先告一段落。

vs2005express一套东东我是下来了，但是看着哥几个开始写dotNet Framework2和vs2005express尝鲜的文章，我只能看着干咽吐沫。

话从机器配置说起，我们的开发用机是在上一项目开发的时候提的升级申请，后来一个人发了一条256的内存，我们一下子成开发部和工程部同事们羡慕的焦点。可是我们自己心里有数，人家微软工程师的笔记本都是1G的内存，没事就开个虚拟机给我们演示个什么的。

现在dotNet Framework2到手了，条件反射是装个虚拟机，我的机器也够意思，立刻告诉我只有128的可用内存。在我关了n个服务之后，还是达不到256地步。于是乎打起笔记本的主意。就在我装完dotNet Framework2之后，突然想起机器上还没有开发完的ASP.Net应用的命运，这是心已经提到嗓子眼了。等开始装SQL2005express之后，我的心彻底出来了——他开始把我的SQLServer停掉，然后替换我的SQL2000。如果SQL2000被干掉，我的应用铁定跑不起来了，马上就要交工了，总不能告诉人家你们得等微软的framework2的正式版出来再用，只好死心。

我现在就想以后有了钱，卖它个4G的内存，开两个虚拟机，一个跑linux，另外一个就为了占内存。