Kaneboy's Blog

最近正好有个朋友问这个方面的问题，如何规划一个SharePoint系统的磁盘容量？如果不能在前期做系统规划（Planning）的时候，确定好所需的磁盘容量，那么就很可能遇到系统上线3个月之后，发现服务器磁盘不够用的尴尬情况发生。

在微软TechNet网站上，有一些相关的文档和白皮书，比如《Capacity Planning and Sizing for Microsoft SharePoint Products and Technologies》。但是如果你懒得阅读白皮书，那么我可以给出一些简要的参数，根据这些参数，你可以快速的估算出一个SharePoint系统所需要的大致磁盘容量。

1、首先，你需要估算出整个系统中将要存放的内容的总容量。如果整个系统的总容量会随着系统的运行而不断增加（很多时候确实如此），那么你就想想你希望整个系统在上线后多长时间之内不想再进行磁盘容量上的升级，然后估算出这段时间之内，系统所存放的内容的总容量。

比如，每个月，所有用户会上传大概10GB文档到SharePoint服务器上。如果你希望SharePoint系统在未来两年之内，不用考虑容量升级的问题，那么这两年内，SharePoint系统中将存放总共240GB的文档。

由于SharePoint 2007文档管理会有“版本控制”和“回收站”的功能，所以在你估算的时候，不要忘记估算这两个功能将要占用的磁盘容量。

比如，在整个系统中，如果你估算大概会有5%的文件会存放到启用了版本控制功能的文档库中（提示：通常，并非所有文件都会需要版本控制的功能，很多文件都是一次性完成，或是无需保留历史版本的，对于这个文件所在的文档库，应该谨慎的使用版本控制功能），并且通过文档库的设置，限制了最多只保留10个主要版本，每个主要版本最多只保留5个次要版本（提示：对于启用了文档版本的文档库，同样需要设置好最多的主要版本的次要版本，避免版本数量无谓的增加太多），那么对于上面算出的240GB文档，你就需要还要加上240GB * 5% * 10 * 5 = 600GB的容量。

这样，我们计算出来的总容量空间将是：240GB + 600 GB = 840GB。

2、由于SharePoint会将所有的网站内容都存储到SQL Server数据库中，对于整个系统的数据库，你要准备所有内容总容量再乘上1.2-1.5倍的空间，给到SQL Server数据库。

比如，对于在第一个步骤里面计算出来的内容总容量840GB，我们就要给SQL Server数据库准备840GB * 1.5 = 1.3TB的磁盘空间。

3、由于SharePoint里面的索引服务（Index Services）会为所有的内容创建索引文件，所以你还需要注意为索引文件准备足够的磁盘空间。索引文件会占用的磁盘空间，可以按照(内容总容量 * (5-12%)) * 3倍这个公式进行计算。

对于5-12%这个比例，需要按照SharePonit中所存储的内容类型来进行适当的调整。例如，对于文档类型的内容（.doc、.docx、.xls、.xlsx、.pdf等），索引文件所占用空间的比例肯定会要比图片文件要高。如果你的SharePoint系统中主要是存放文档类别的内容，那么你就要将这个比例适当的加大，也就是更接近12%。

比如，对于840GB的内容，如果这些只有一部分是文档类型，那么我们要为索引文件准备840GB * 8% * 3 = 200GB的空间。

注意，如果在你的SharePoint服务器场中，索引服务是运行在一台单独的索引服务器（Index Server）上，那么就要在索引服务器上准备这么大的磁盘空间。

4、如果在SharePoint服务器场中，查询服务（Query Services）不是与索引服务运行在同一台服务器上，由于SharePoint会自动将索引文件从索引服务器上复制到运行查询服务的服务器上，所以在所有运行了查询服务的服务器上，同样需要准备足够的磁盘空间，留给索引文件。要准备的磁盘空间容量，计算方法与索引文件的容量相同。

5、最后，为了防止在估算的时候过于乐观，而且你也有足够的预算，那么不妨将上面的所有计算结果再乘上1.5 - 3倍（倍数可以按照您手里的预算来决定，呵呵）。比如，为SQL Server数据库准备2TB的磁盘空间，为索引文件准备300GB的磁盘空间。

最后，介绍两个SharePoint容量规划工具。第一个是微软的SharePoint Capacity Planning Tool，这个工具依赖于System Center Capacity Planner 2007。根据我的使用经验，个人认为这个工具过于花哨，实用价值不太高。:)

第二个工具是HP ProLiant Sizer for Microsoft Office SharePoint Server 2007，它是HP公司发布的一个工具。我对此工具没有什么使用经验。

第6讲：SharePoint开发 - 模式与重构（涂曙光）

5月30日，我会参加SharePoint技术峰会，并贡献一个讲座：《SharePoint开发：模式与重构》（或者可以叫做《如何将模式应用到你的SharePoint程序，并重构它》）。这个讲座面向的对象是SharePoint Developer和Architect。

这次活动的详细信息，请参考www.msiw.net。活动地点在霄云路现代汽车大厦18楼，参与者不需要负担任何门票费用，但午餐似乎需要自己解决。:)

更新：我在峰会上使用的PPT，以及现场显示的Demo源码下载。

Windows SharePoint Services 3.0 SP2 下载
SharePoint Server 2007 SP2 下载

最近在忙着给出版社交《Microsoft Office SharePoint Server 2007 管理员指南》的翻译稿，所以实在没有时间写blog了。希望等过了这阵子之后，再写一些新的东西。

WSS 3.0和MOSS 2007都发布最新版本v1.5 SDK了。

WSS 3.0 SDK v1.5下载
MOSS 2007 SDK v1.5下载

在SharePoint从上个版本升级到当前版本时，从产品名称中去掉了"Portal" (SharePoint Portal Server 2003 –> Microsoft Office SharePoint Server 2007)，而下个版本将从产品名称中去掉"Office"，其产品名称将是"Microsoft SharePoint Server 2010"。

SharePoint Designer 2007变成了一个免费的产品。

中文版下载

在SharePoint 2007的列表中，可以通过列表设置直接启用项目级权限控制，使得只有每个列表项的作者能查看和编辑自己的项目。但是，文档库是没有这个功能的。最近有好几次被人为到这个问题，所以写了一个东东，安装到SharePoint 2007中，就可以为文档库启用这个功能了。



我将解决方案安装包和源代码都放到了spdoclibitemsecurity.codeplex.com上面，你可以直接到这个项目网站上下载安装包和源代码。

安装方法：
1. 在SharePoint 2007服务器上解压开安装包，然后执行里面的"install.bat"，进行安装和部署。
2. 在需要启用这个功能的网站，打开"网站设置"，然后进入"网站功能"，然后激活"文档库项目级权限"功能即可。

SharePoint网站默认是使用Active Directory集成认证，但如果是用于Internet场景，那么由于难以为访问用户建立AD帐号，解决方法通常是将SharePoint网站配置成使用Forms认证，在一个自定义的数据源（比如SQL数据库或其他的什么地方）中存储这些用户的凭证信息。

但有时候我们会遇到另外一种场景，那就是访问用户确实都在AD中有对应的帐号，但用户就是不习惯使用内置的那个Windows登录窗口，来输入自己的用户名和密码。这个时候，我们可以让SharePoint网站仍然使用AD认证，但是用户登录的时候，使用表单的方式，在页面上输入自己的AD帐号和密码，然后登录。下面的Video展示了完整的配置过程，以及如何做一个定制的登录界面。

第一部分：
<a href="http://video.msn.com/?mkt=uv-en-us&amp;tab=m555&amp;playlist=videoByUuids:uuids:dec9f8b5-e1b5-435f-a303-5e2910cf4919&amp;showPlaylist=true&amp;from=IV2_en-us_videoguide_player&amp;fg=gtlv2" target="_new" title="AD Auentication with Forms-Style Login in SharePoint">Video: AD Auentication with Forms-Style Login in SharePoint</a>

第二部分：
<a href="http://video.msn.com/?mkt=uv-en-us&amp;tab=m555&amp;playlist=videoByUuids:uuids:031b1794-cb9f-40fa-83b3-44189810d9a2&amp;showPlaylist=true&amp;from=IV2_en-us_videoguide_player&amp;fg=gtlv2" target="_new" title="AD Authentication with Forms-Style Login in SharePoint (Part 2)">Video: AD Authentication with Forms-Style Login in SharePoint (Part 2)</a>

Video中用到的配置信息：
(1)要添加到内容Web应用程序的web.config中的配置信息(粗体表示要添加的)
<configuration>
  <connectionStrings>
    <add name="ADConnectionString" connectionString="LDAP://moss070810.contoso.msft/CN=Users,DC=contoso,DC=msft" />
  </connectionStrings>
  <system.web>
    <membership defaultProvider="ADMembership">
      <providers>
        <clear />
        <add name="ADMembership" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString"  connectionUsername="contoso\Administrator" connectionPassword="pass@word1" attributeMapUsername="sAMAccountName" />
      </providers>
    </membership>
  </system.web>
</configuration>
(2)要添加到管理中心Web应用程序的web.config中的配置信息(粗体表示要添加的)
<configuration>
  <connectionStrings>
    <add name="ADConnectionString" connectionString="LDAP://moss070810.contoso.msft/CN=Users,DC=contoso,DC=msft" />
  </connectionStrings>
  <system.web>
    <membership>
      <providers>
        <add name="ADMembership" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString"  connectionUsername="contoso\Administrator" connectionPassword="pass@word1" attributeMapUsername="sAMAccountName" />
      </providers>
    </membership>
  </system.web>
</configuration>

附注：
(1) 如果你对SharePoint 2007中的自定义用户验证没有太多概念，可以参考我以前写过的一篇文章：《在SharePoint Server 2007中创建定制的用户管理模块》。
(2) 由于对录制Video没太多经验，导致Video声音偏小，下次一定注意。

今天偶然发现，WSPBuilder在中文版本的Visual Studio上面无法正常工作（以前一直使用英文版VS，所以没发现有这种问题），在使用"Build WSP"指令时，会提示"值不在预期的范围内"。到WSPBuilder的项目网站找了一下，发现已经有使用法文版Visual Studio的用户，提出过这个Bug了。我从项目网站上找到源代码，修改了一下，让它可以兼容非英文版本的Visual Studio了。如果你习惯了使用中文Visual Studio，可以到这里下载我上传到页面上的附件"WSPTools.VisualStudio.VSAddIn.zip"。下载后，使用压缩包里面的"WSPTools.VisualStudio.VSAddIn.dll"，替换GAC里面的同名文件就可以了。

---------- 不低俗的分隔线 --------------

今天在InfoQ上看到了一篇不错的文章，是几个"大人物"关于Unit Test和TDD的争论，感兴趣的可以看看。

在这个月上海举行的.NET技术大会上，我将奉献一节名为《基于SharePoint的Web应用开发模型》的课程。由于大会的定位是“面向企业级.NET开发深度应用”，我相信大家想听的一定不是单纯的介绍SharePoint Server，或是怎么做一个Web Part。思来想去，终于定下了《基于SharePoint的Web应用开发模型》这个题目。我希望能在有限的时间内，和大家探讨如何利用SharePoint这个Web开发平台，如何组织一个团队，开发一个大中型的Web应用。内容将包括如何组建团队、如何构建团队开发环境、如何分工、如何有效的利用SharePoint提供的Solution框架来组织我们的项目内容、如何测试（单元测试、集成测试）。当然，除了这些稍微有些"High-Level"的内容，我还希望能探讨，作为一个SharePoint Developer，我们可以对SharePoint的哪些部分下手，如何下手，如何让自己的定制内容（页面、代码、流程）能真正“融合”到SharePoint平台里面，而不是只把SharePoint当作一个大类库和存储库。坏消息是，似乎有太多内容要讲，而每个主题都似乎能讲上很长时间，而好消息是，课程将有70分钟的长度，如果没有记错的话，这已经比TechED的课程长度要长了。

See you in Shanghai !

(2009-2-21 更新：从这里下载此课程的PPT)

SharePoint Team Blog中公布了VSeWSS 1.3 CTP的消息，请从这里下载。1.3最大的改进之一，是提供了x64版本，以支持在x64机器上进行开发。另外，我最喜欢的改进包括：

新增更多的Project Item，比如，通过"Root File"直接往12hive里面放文件。
  
VSeWSS的智能化程度也高了一些，如果在Project Explorer里面更改了文件夹名，或是直接删除了文件夹，会自动对SharePoint Solution进行更新，不会像以前那样，直接在WSP View告诉你一个错误信息。

这个新增Feature的对话框很可人...


终于有了独立的"Package"选项，而没有必要仅仅为了生成一个WSP包，却不得不使用"Deploy"选项，先生成WSP，再被强迫进行部署...另外，"Quick Deploy"里面的功能很实用。
 

总结：通过正确的"模仿"WSPBuilder很早就有了的好用且实用的功能，相比1.2版本，这个新版本的可用性明显提高了不少。

Composite Web Application Block是Web Client Software Factory中一个用来开发Web应用的框架，它能帮助程序员更方便的使用MVP模式。关于CWAB的更多信息，请参考这里。

当我们开发SharePoint界面的时候，比如，创建一个Web Part，如果你希望使用MVP模式，是可以引入CWAB的。在这个文档中解释了如何在SharePoint中使用CWAB，但文档里面的一些步骤，其实不一定是最好的。比如，文档中告诉你，将各个程序集放到Web Application的/bin目录中，但我的建议是仍然将它们部署到GAC里面，这样，你就不需要更改Web Application的web.config中的<trust>节点，将代码的默认信任等级提高了。

嗯，总之，我们可以使用CWAB来方便的基于MVP模式来开发Web Part，比如下图所示的项目结构：
 

上图中的“KBSample.SiteUser.Module”是CWAB中的一个Module项目，包含了与界面UI分离的业务模块。在“Views”目录中包含了定义View的接口和Presenter类：


在“Services”目录中包含了与业务操作相关的Service类：


而“KBSample.SiteUser”项目则是专门的SharePoint项目(你可以选择使用VSeWSS，或是其它你习惯的工具)，其中包含了用来定义Web Part界面的View的实现。

在下面所示的Service接口中，定义了用来真正和SharePoint Object Model交互以获取数据的Service：


在Module被初始化时，将上面的Service注册到Container中：


对View接口的定义：


在Presenter里面，通过[ServiceDependency]来注入所依赖的Service对象(CWAB通过ObjectBuilder来干这件事)，同时定义了当View被载入时的操作：
 

View是通过一个用户控件来实现的，它实现了View接口，通过[CreateNew]来将一个新的Presenter对象注入进来：

别忘记在View被载入时，也要执行一下Presenter中的载入方法：


如果你熟悉Web Client Software Factory的话，那么在SharePoint开发中引入CWAB应该不是一件困难的事情。不过，由WCSF提供的那些Template和Recipe都不能使用了，项目的结构，需要我们来手工维护(这样反而给了我们很大的自由度:)。

在Wikipedia上，对“Web Application Framework”的定义是：

一个Web Application Framework是一个设计为支持动态Web网站、Web应用程序和Web Services开发的软件框架。Web Application Framework的目标是减少在Web开发中，与常见的开发工作有关的问题。例如，许多框架都提供了诸如数据库访问类库、模板框架和会话管理，同时，框架通常都能促进代码复用。（注：http://en.wikipedia.org/wiki/Web_application_framework）

Wikipedia的定义虽然清晰明了，但未免过于宽泛。根据这个定义，实际上，我们可以再将Web Application Framework分成两种：
■ Web Application Infrastructure Framework
■ Web Application Building Framework

Infrastrcture Framework提供了用来构建Web应用最底层的各种基础框架，诸如HTTP请求的截取和分配、网站与页面处理框架、会话管理、缓存等等。ASP.NET、PHP、JSP就属于Infrastrcture Framework。

Building Framework则是基于Infrastrcture Framework而构建起来的层次更高的Web应用框架，它的目的包括：
■ 将Web应用开发人员的视角从最底层的网站与页面框架，拉到更上面的基于具体应用的业务功能上
■ 用来支撑大型复杂的Web应用，例如超过上千个网站、上万个页面的Web系统，而且提供对服务器场、负载平衡的支持

在.NET领域，DotNetNuke就是一个典型的Building Framework。有了Building Framework，Web开发人员就可以不用从最底层开始构建Web应用系统，而是可以基于Building Framework，开始构建所需要的应用功能组件。一个Building Framework通常会包含下列内容：
■ 成熟的网站与页面结构框架，使得开发人员不用再基于页面、目录来管理整个Web应用
■ 完善且可扩展的用户、角色与权限管理
■ 灵活的UI模型
■ 内置的数据和文件存储能力
■ 具备完善的功能模块封装型
■ 对必要的功能接口提供API
■ 其他…



对于Web应用的开发来说，从静态网站到动态网站，从Infrastructure Framework到Building Framework，几乎是必然的。随着Web应用越来越复杂，开发人员面临的挑战也越来越大：如何维护和管理上千个网站、上万个页面？如何使Web应用能部署到网络负载平衡的环境中？如何使后台的Services与前台Web请求分离？如何提供完善的系统备份与迁移方案？如果我们必须基于Infrastructure Framework来解决这些问题，那么我们可能得将大部分的项目开发周期，花费在解决这些“底层架构”框架之上（虽然有些开发人员确实更喜欢开发“框架”，而不是一个可用的业务系统）。



当基于Building Framework之上进行开发时，开发人员可以更关注业务需求和业务功能的实现。通常，每一种Building Framework都会有一套专门的对功能模块进行封装和打包的模型，开发人员可以基于这一套模型，将自己开发的功能模块以标准化的方式进行封包。一方面，这样可以使得功能模块的部署变得更简单（避免了基于文件的手工拷贝方式），另一方面，开发人员也更容易的将自己开发的功能模块共享给社区（社区中使用同一套Building Framework的开发人员，可以方便的将拿到的功能模块以标准化的方式部署到自己的环境中）。

待续…

这个操作手册是之前帮一个客户写的，使用了SQL Server 2005 Mirroring来实现SPS 2003的门户的快速恢复，主要目的是在SPS 2003门户的突然不可访问（如数据服务器损坏、服务器群集所在网络不可用等）时，能够用最短时间在另外的地点恢复出门户网站。基本上MOSS 2007的原理类似，参考手册中的方法进行即可。

不过需要注意的是，在决定用SQL Server 2005 Mirroring来实现快速备份和恢复之前，你需要根据你的服务器场环境的具体情况，确定是否SQL Server 2005 Mirroring这种方式确实适用于你的服务器场环境。考虑的因素包括：
■ 对快速恢复所花费时间的要求
■ 网络情况
■ 评估Mirroring可能造成的性能上的损失

点击此处下载。

Chai同学已经在他的blog上贴了文章，讲述VS2010中，针对SharePoint开发的一些增强。虽说VS2010还有一点点远，但是先了解一下也是不错的。嗯，在VS2008上，应该至少还会发布一个VSeWSS 1.4出来。

新的项目模板类型：
 

内置在VS2010中的Server Explorer：
 

Feature属性设置界面（可以选择将Project中的指定Item添加到当前Feature中）：


新的Web Part开发模式，当我们新建一个Web Part时，会同时创建一个“绑定”的用户控件，在Web Part内会内置有包含此用户控件的代码，然后，我们可以直接基于这个用户控件进行可视化设计。

Package Explorer

对项目新增了“Package”操作，不再只能“Deploy”了。

QuickPart已经很久很久很久没更新了，这1个月将它做了一些小小的更新，其中最重要的一项更新是：QuickPart现在不但会搜索Web应用程序的“/wpresources”目录下放置的“.ascx”用户控件，还会搜索“/controltemplates”目录(及子目录)下放置的自定义“.ascx”。做这个看似没太多意义的更新，主要目的其实是可以让使用QuickPart的开发人员，直接使用Visual Studio 2005/2008（加上相应的VSeWSS），来管理、打包用户控件。也就是说，现在，大家可以不用辛辛苦苦的手工将做好的“.ascx”、“.dll”一个一个的拷贝到服务器的相应目录，而是可以使用SharePoint Solution Package的方式，快速的打包和部署可供QuickPart使用的用户控件了。

如何利用Visual Studio，来管理QuickPart部件，可以参考下面的video。如果觉得太小看不清楚，可以直接下载wmv格式的video。


(双击可放大到全屏，wmv格式下载)

链接：QuickPart 1.02下载

(注：标题中说的“SharePoint解决方案”，不是指SharePoint Solution Package(.wsp)中的那个“Solution”，也不是Visual Studio中用来包含各个子项目的“解决方案”，而是泛指各种基于SharePoint的应用。)

什么样的问题，是我现在被问得最多，也是最害怕被问的呢？嗯，就是“我对SharePoint开发没什么概念（/头绪/思路），你能给我讲讲吗？”其实，问这样的问题的人，不一定“真的”一点都不了解SharePoint的开发，他可能已经知道了Web Part要如何做出来、事件处理程序怎么写、SharePoint页面要如何进行定制化等等，但是，就是仍然觉得自己的大脑中没有一个清晰的、整体的SharePoint开发思路。一言以蔽之，提问者真正不了解的，准确来说，应该是SharePoint解决方案的完整的开发模型，到底是怎样的？或者换一个更cool的说法，就是所谓的开发方法论的问题。

在我的理解中，SharePoint解决方案的开发模型，确实绝对并非简单的Web Part如何开发、事件处理程序如何写之类的。当然，我不是说这些基础的、对SharePoint各个开发接口的了解不重要，实际上，如果连这些都还没有了解，那么也根本谈不上要了解更“上层”的SharePoint解决方案开发模型了。SharePoint解决方案开发模型应该包括但不限于下面这些主题：
■ SharePoint开发团队应该如何组织和分工？
■ 如何建立SharePoint开发、测试、集成（硬件和软件）环境？
■ 根据用户需求，如何进行SharePoint应用的整体设计（包括数据、界面、User Case…）？
■ SharePoint应用应该如何组织、分拆、组合？
■ 开发人员要如何有效的维护和管理SharePoint项目代码和内容？
■ 如何设计生产环境的拓扑和网络模型？
■ 如何按照信息架构，对SharePoint网站内容进行合理的分类和组织？
■ 如何创建一个高效的部署、迁移模型？

这也是为什么，很多人觉得，看完了《Office SharePoint Server 2007 开发入门指南》，仍然感觉对SharePoint开发存在着很多的疑问和未解。一本入门的书，很难将SharePoint解决方案开发模型的内容给装进去。而且，在编写这本书的2006年，SharePoint 2007甚至还没有正式发布，更不太可能有成熟的SharePoint解决方案开发模型可以借鉴。如果有人要撰写更新的SharePoint开发书籍，就有可能将更多的开发模型方面的内容放进去了:)。在MSN群里面和大家聊天的时候，也曾经头脑发热，提议再写一本相对高级的书，但是…不过，还是希望自己能陆续写一些相关的文章，放到blog上，和大家分享。

伴随着PDC 2008，一大堆新东东一下子被推到了我们面前。Windows 7、Azure、Visual Studio 2010…

当然，Office也丝毫不逊色。Azure中的Microsoft SharePoint Services（不是Windows SharePoint Services），还有Office Web Applications，都是很吸引人的东东。Microsoft SharePoint Services，是一个可以让开发人员访问Azure中的SharePont功能的东东，通过使用Visual Studio这样的开发工具，开发人员可以快速构建使用到SharePoint能力的应用程序。至于Office Web Applications嘛，嗯，大家终于可以在浏览器里面直接编辑Word、Excel、PowerPoint、OneNote文档了。

Update for Windows SharePoint Services 3.0 x86 Edition (KB956612)，安装之前，请参考Jie Li同志写的此文。

最近有很长一段时间没有写blog了，最近的空余时间全部花在了翻译《Microsoft Office SharePoint Server 2007 Administrator’s Companion》（中文版名称将会是《Microsoft Office SharePoint Server 2007 管理员指南》）上。在12月份前，应该能够和几位弟兄一起完成翻译工作。

悄悄的，Windows SharePoint Services 3.0 SDK v1.4发布了。还有Microsoft SharePoint Administration Toolkit v2.0。

今天IE 8 Beta2发布，第一时间安装到了自己的电脑上。感觉尚好，只是在打开新的Tab，或者关闭某个Tab时，IE8不断的Crash（不过现在IE8终于不再像IE7那样，一个Tab的Crash会搞死整个IE了。）将IE中所有的Add-on都Disable掉，终于好了。

-------- 从爱枣报学来的分割线 -----------

在第一篇文章中，我讲了如何使用Feature Stapling来自定义网站初始化过程，但是Feature Stapling还是有一些限制的。相比之下，虽然创建一个定制的Site Definition要更加复杂一些，但确实可定制性要更强更灵活。如果再配合上Site Provisioning Engine，那简直可以说是强大无比了。

首先澄清一个概念。在一个SharePoint网站的网站设置页面中，使用“将网站另存为模板”链接，管理员可以将整个网站保存为一个扩展名为.stp格式的模板。使用这个stp网站模板，管理员可以重复创建同样结构（和内容）的新网站。那么这种stp格式的网站模板，和我们下文所说的Site Definition有什么区别呢？简单来说，Site Definition是一种通过磁盘上的一系列文件（包括xml、页面模板文件等等）来对一个网站的结构和内容进行描述的一种方式。Site Definition可以对一个网站模板的方方面面进行非常细致的定义，基本上无所不能。而stp网站模板只是一种简单的将一个已存在网站进行转存之后，可以重复使用的网站模板格式。stp网站模板没法直接修改，没太多可控性。下文中说的“网站模板”一次，默认是指Site Definition。

接着来详细说一下Site Definition。在SharePoint服务器的“Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\2052\XML”位置，有一堆以WEBTEMP开头，扩展名是.xml的文件。这些WEBTEMP*.xml文件，就是SharePoint中用来标明Site Definition的文件。

我们在SharePoint中创建一个新网站时，有一个“工作组网站”的网站模板可以让我们选择。打开“WEBTEMP.xml”文件，就能看到这个“工作组网站”的Site Definition。



在WEBTEMP*.xml文件中，“<Template>”节点表示一种Site Definition，它的“Name”属性指明了这个Site Definition保存在“Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates”中的哪个子目录中。一个Template可以包含多个子Configration。一个Configuration对应到一个用户所理解的网站模板。如果我们需要多个网站模板，它们大致相同，只有一些微小的地方有区别，那么我们就可以只定义一个Site Definition，然后用这个Site Definition的多个Configuration来体现这多个网站模板的不同之处。

在上图所示中，我们可以看到，其实“工作组网站”、“空白网站”、“文档工作区”这三个网站模板，都是同属于“STS”这个Site Definition的三个Configuration。“STS” Site Definition位于“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\sts”目录中。

当然，WEBTEMP*.xml只是让SharePoint知道有哪些Site Definition，以及每个Site Definition中有哪些网站模板（也就是Configuration）可用。但是具体每个模板中包含的内容，包括列表、文档库、页面、页面上的web part等等等等，都是定义在Site Definition中的ONET.XML文件中。比如，下图就是“STS” Site Definition的ONET.XML文件。

ONET.XML几乎定义了一个网站模板的方方面面。比如，为什么使用“工作组网站”模板创建的新网站的default.aspx页面，在页面右侧会显示一个SharePoint的Logo图片？这是因为在ONET.XML里面有下面的内容。

于是我们就看到了

现在你应该已经明白了Site Definition是怎么回事，以及它是如何起作用的。了解这些之后，我们就可以根据自己的需求，来创建自己所需要的Site Definitiion了。你一定要记住一点：永远不要修改SharePoint自带的Site Definition。这是因为微软可能在某些后续的Service Pack或Hotfix中，用更新的文件覆盖旧的Site Definition文件。

创建新的Site Definition的基本步骤是：

1、找一个磁盘上已有的，用来起步的Site Definition，将这个Site Definition目录复制一份；
2、创建新的WEBTEMP*.xml文件，比如WEBTEMP.MySiteTemp.xml，在里面写明新的Site Definition的名称（也就是Site Definition所在的目录名），Configuration等等；
3、修改这个新Site Definition的定义文件直到满足你的需求为止；
4、IISRESET

接着介绍Site Provisioning Engine。什么是Site Provisioning？当你在SharePoint里面，使用某个网站模板，创建了一个新SharePoint网站，这个过程就叫做Site Provisioning。（干嘛不直接叫做Site Creating？嗯，有时候用用时髦词挺Cool的，不是吗？）SharePoint内置了一个Site Provisioning Engine，来完成Site Provisioning过程。这个过程包括给站点应用模板、将所需文件“拷贝”到站点中、根据网站模板类型进行一些其他的必需操作等等。但是，这个Site Provisioning过程也是可以自定制的。

一个Site Provisioning过程，需要由一个继承自Microsoft.SharePoint.SPWebProvisioningProvider的类来完成，具体点说就是由这个类的Provision()方法来完成。所以我们如何自定制这个过程呢？写一个新类，继承自Microsoft.SharePoint.SPWebProvisioningProvider，然后重载Provision()。

我们来用一个实际的示范进行讲解。用户的需求是：“工作组网站”这个网站模板的首页的右侧那个SharePoint Logo图片实在碍眼（没错，就是上面那个截图中的图片），能不能创建网站后，不要那个图片了？当然，我们可以创建一个新的Site Definition，然后修改新Site Definition的ONET.XML文件，去掉这个web part，但是，因为演示的缘故，我故意不用这个简单的方法，而用更“高级”的定制Site Provisioning来完成。

由于“工作组网站”这个模板的其他部分并不需要调整，所以我决定新建一个WEBTEMP.CustomTeamSite.xml文件，并在文件中创建一个新的Configuration。

上图中的名称为“定制工作组网站”的“Cinfiguration”节点有两个属性，“ProvisionAssembly”和“ProvisionClass”，这两个属性指定了这个Configuration使用了一个定制的Site Provisioning过程，而不再使用SharePoint默认的Site Provisioning模式。

接着是上面指定的那个定制Site Provisioning类。

在重载的Provision()中，首先，代码仍然让新网站应用“工作组网站”这个网站模板。“STS#0”的意思是，使用“STS”这个Site Definition的ID为“0”的Configuration，也就是“工作组网站”这个模板。但是，在应用了默认的“工作组网站”模板之后，再调用了InitTeamSite()方法，在这个方法中通过SharePoint API，将网站首页上的那个图片web part去掉了。

将我们的项目部署到服务器上，IISRESET之后，就能在新建网站页面中看到这个新的名为“定制工作组网站”的网站模板。

使用这个网站模板创建一个新网站后，就会发现，这个网站和用“工作组网站”模板创建的网站一模一样，除了首页上再没有那个图片web part。

通过创建定制Site Definition，以及创建定制的Site Provisioning类来接管Site Provisioning过程，我们就能够完全自定义一个SharePoint新网站的创建过程了。:)

最后一个问题，我们应该选择哪种方式呢？Feature Stapling？还是Site Definition + Site Provisioning Engine？我更推荐Feature Stapling。将各种自定义功能封装成（一个或多个）Feature，让网站管理员可以自己选择启用或停止这些Feature，如果需要，使用Feature Stapling使网站自动应用并激活这些Feature，是一种更好、更优雅、更具封装性、更容易迁移的方式。

上面所示的定制Site Provisioning项目源码下载。

刚才把书柜里面的SharePoint书都堆在一起，用手机拍的...

为什么要自定义一个SharePoint新网站的创建过程呢？作用很多。其中之一就是，我们创建了一个新的SharePoint应用组件，然后希望SharePoint管理员在创建一个SharePoint新网站的时候，就可以在那个新网站中使用我们开发的新应用组件。

SharePoint Server 2007本身也利用了这种方式。比如，如果用户希望使用Records Management相关的功能，他可以使用“记录中心”这个网站模板来创建一个新网站。在新网站中，界面和内容会根据Records Management的需求做好了一些定制，用户可以直接基于新网站中的预制内容，开始自己的工作。

 

要自定义一个SharePoint新网站创建过程有两种方式：

1、Feature Stapling
2、Custom Site Definition + Site Provisioning Engine

SharePoint产品自身大量使用了第二种做法。我们也可以模仿它那样，创建一个定制的Site Definition，然后让用户在上图所示的创建新网站的时候，选择我们创建的Site Definition即可。创建一个定制的Site Definition是一件繁琐的活儿，特别是如果还需要利用SharePoint Provisioning Engine来做一些更“高级”的调整。幸好SharePoint Solution Generator一定程度上减少了创建Site Definition的复杂度。

但我个人更建议你使用第一种方法。:) 所以今天我先介绍Feature Stapling，第二种方法在后续的文章中再介绍。

Feature Stapling，也叫Feature/Site Template Association，它的作用是将某个Feature与某个网站模板关联起来，而不需要这个网站模板定义本身包含这个Feature。比如，在系统中有“工作组网站”这样一个Site Definition，我们希望这个模板能包含我们自己开发的一个“Feature XYZ”，但是又不想直接到磁盘上去改动“工作组网站”这个Site Definition。除了使用上面说的第二个办法（也就是在“工作组网站”的基础上添加一个新的比如“工作组网站 with Feature XYZ”的Site Definition），用Feature Stapling就能将我们的这个“Feature XYZ”与“工作组网站”Site Definition关联起来，就好象“工作组网站”Site Definition已经包含了“Feature XYZ”一样。

要实现Feature Stapling，需要创建至少2个Feature。第1个Feature叫做Feature Stapler，也就是用来将真正完成功能的Feature与网站模板进行关联的一个Feature，第2个也就是用来完成功能的Feature本身了（也就是上文所说的“Feature XYZ”）。

由于Feature有事件处理程序机制，所以，通过给第2个完成实际功能的Feature添加事件处理程序，我们实际上是能利用Feature Stapling完成某些很复杂的事情的。例如，给网站中添加几个List、为网站添加一些预定义的用户。

曾经有人问过我这样一个问题，如何修改所有用户的“我的网站”的样式？比如，在“我的网站”首页中增加自己开发的Web Part，或者干脆将“我的网站”完整的换成自己想要的样子？Feature Stapling就是一个很好的解决之道，我们只需要将一个（或多个）Feature关联到“我的网站”所使用的网站模板，这样，当每个用户第一次访问“我的网站”并为其创建“我的网站”时，关联的Feature就可以通过它的事件处理程序来完成工作，达到我们想要的效果。

接下来是我最喜欢的实例示范环节。:)

Demo场景是，当用户使用SharePoint内置的“工作组网站”这个模板创建一个新网站时，希望在这个新网站内能自动出现一个联系人列表，并且里面已经包含了一些原始数据。

首先，创建Feature Stapler：

feature.xml:
<Feature Id="06dbfca3-a041-4c50-aea3-7dd8561b48f9" Title="STS#0 Feature Stapling" Scope="Farm" Version="1.0.0.0" Hidden="FALSE" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="STS0FeatureStapling\elements.xml"/>
  </ElementManifests>
</Feature>

elements.xml:
<Elements Id="55B76996-827F-4879-B0D1-BADDCCDC8AAC" xmlns="http://schemas.microsoft.com/sharepoint/">
  <FeatureSiteTemplateAssociation Id="1d68910c-b227-4cba-bfa7-87896d812dcf" TemplateName="STS#0" />
</Elements>

然后是实际用来完成工作的Feature：

feature.xml:
<Feature Id="1d68910c-b227-4cba-bfa7-87896d812dcf"
         Title="Team Site Init"
         Scope="Web"
         Version="1.0.0.0"
         ActivateOnDefault="FALSE"
         Hidden="FALSE"
         DefaultResourceFile="core"
         ReceiverAssembly="FeatureStaplingSample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5"
         ReceiverClass="FeatureStaplingSample.FeatureCode.TeamSiteInitFeatureReceiver"
         xmlns="http://schemas.microsoft.com/sharepoint/" />

上面的Feature使用了一个事件处理程序来进行实际的工作，事件处理程序的代码就不贴了。

示范完整源码下载（需要VS2008+VSeWSS 1.2）。

奥运会终于开幕了！

如果你看过奥运会开幕式，一定惊奇于开幕式中精彩的灯光和背景显示控制。这些各种控制使用了120台HES Axon服务器，服务器中运行的，是Windows XP Embedded（XPe）。


（鸟巢中的服务器机房）

同时，在奥委会的Info2008系统中（超过3500家奥运合作伙伴和媒体会使用此系统），选用了Office SharePoint Server 2007作为其内容的搜索引擎，以帮助Info 2008的使用者更快捷的搜索信息。



（相关的Case Study请参考微软网站）

WSS 3.0与MOSS 2007发布了在SP1之后的又一个重要更新：Infrastructure Update。

WSS 3.0 Infrastructure Update Download
MOSS 2007 Infrastructure Update Download

使用方法参考这里：SharePoint文件磁盘存储组件使用指南。
WSP安装包下载：WSSv3.DiskFileStorage.wsp (源码 (Update 2008-6-24:为了方便大家使用源码，将源码改成了使用VS2008 + VSeWSS 1.2) )

警告：仅仅是测试版，请仅用于测试（或者你直接把源码改到认为已经足够稳定也行）。有问题请到我的备份blog（http://kaneboy.spaces.live.com）此克隆贴下留言。

SharePoint文件磁盘存储组件可以将用户上传到SharePoint中的文件，存储到指定的磁盘目录中。基本原理可以参考我之前的blog。

1、安装Solution Package

使用stsadm.exe将Solution Package安装到SharePoint服务器上：
stsadm -o addsolution -filename DiskFileStorage.wsp

2、部署解决方案



 

3、在服务器场中激活“文件磁盘存储”功能





激活后，在服务器命令提示符中运行下列指令：
IISReset
net stop sptimerv3
net start sptimerv3

4、配置Web应用程序以启用此功能

在“管理中心 - 操作 - 数据配置”点击“用户文件磁盘存储”：
 

在下面的界面中配置每个Web应用程序是否启用磁盘存储功能，以及存储位置等：


搞定。

计划本周末提供组件Solution Pakcage下载。

（本文转自http://www.enet.com.cn/article/2008/0416/A20080416228677.shtml）

【eNet硅谷动力消息】CIO们为什么对于微软的SharePoint产品特别关注呢？因为它使用得频繁程度正在日益增加（无论你是否知道，但这却是事实），它需要进行特殊管理以发挥最大效用。

Corridor Consulting公司是一家专门从事企业内容管理（ECM）的厂商---尤其是帮助企业部署SharePoint，并使它发挥最大效用。该公司总裁Russ Edelman（他也是即将出版的新书《轻轻松松赢得商战成功的八项战略》合作作者之一）本月初寄给我的一份有关微软SharePoint会议的报告，主要从一个SharePoint大客户的角度阐明了一些观点，以及如何使SharePoint发挥最效果的技巧。

SharePoint 2007 大会可以看作是微软内容/文档/图像/记录管理系统SharePoint发展势头的一个晴雨表，这次盛会于3月3日至7日在美国西雅图召开，门票很早就被抢购一空，等待名单中有超过500人。事实上，一些“绝望”的 SharePoint用户甚至在没有会议通行证的情况下强行冲入了会场，希望能申请到一张门票参加这次盛会。如果你认为SharePoint仅仅是一个部门级解决方案的话，那么你可能对SharePoint的理解不是很正确。许多应邀出席SharePoint 2007 大会的公司都是全球性大公司，他们对于SharePoint的使用也在迅速增加。如果你不重视这个现象，你就有可能使你的企业遭受到了损失。

General Mills公司微软卓越研发中心经理Elliot Gerard同比尔盖茨一起为SharePoint 2007 大会作了定调发言。会后，General告诉我：“ General Mills同一些核心厂商，比如微软，都有过合作，这也带来了巨大的合作机会。”General Mills 公司信息系统部负总裁Terry Brown还补充说：“这种做法让我们有机会用更低的总体拥有成本（TCO）更快的创造业务价值。微软是我们的一个主要供应商，在2001年SharePoint刚刚发布以后，我们就部署了这个系统。”

企业一般将SharePoint用于集中存放各种文件，并且它很胜任这项工作：大部分文件都可以方便地进行查询和快速存取。但SharePoint也已证明是一个非常成功的协作平台；其工作能力，虽然不能说是最好的，但可以帮助员工更告高效地处理信息和过程。

General Mills的Gerard说：“尽管SharePoint在早期有一些局限性，但是，在微软的不懈努力下，这些都已经得到了很大的改善。在General Mills，SharePoint目前被认为是一个关键技术，并且已经广泛渗透到企业的各个方面。”Brown在最后的发言中说：“我们设想，最终所有的非结构化信息将存储在SharePoint上，这样我们就可以利用记录保留策略并且对内容添加索引，因而我们的用户能够进行全文内容检索。”

General Mills还向大家展示了他们是如何使用SharePoint的；不过，他们对SharePoint的使用水平远远超过了其它公司。随着越来越多的公司加快部署SharePoint，并不断在该服务器上运行新的应用，这次大会还给大家提出了一些建议。

第一，由于很多业务人员带头支持SharePoint却没有用企业标准对它进行评估，这造成了SharePoint使用的盲目增长。必须用一种治理策略赖管理这个过程，不然的话，使用SharePoint可能会适得其反。

第二，ECM系统是一个巨大的“技术成功，但却不是伟大的“商业成功”。许多关键的业务因素常常被忽视，比如通讯规划、变更管理和配置管理。把这些重要因素融入你的策略中，因为如果不这样做，你可能从一开始就走错方向了。

最近新发布的SharePoint资源相当多。

微软发布了一个新的SharePoint开发网站：http://MSSharePointDeveloper.com，这个网站是专门设计给想要学习SharePoint开发的ASP.NET程序员。同时，SharePoint Development Training for ASP.NET Developer也正在进行中，这儿有一些PPT和Demo文件，这儿是动手实验文档。Paul Andrew也写了一篇《Introduction to SharePoint Products and Technologies for the Professional .NET Developer》。另外，新发布了一篇挺长的文档：《Developing Custom Applications with SharePoint Server 2007》。最后，Choral同志的51sharepoint.com也开张了。

早就知道了有这么一个服务，但一直没有机会尝试，今天趁有空，将一个Office Business Applications的Casestudy录像上传到了Silverlight Streaming服务，效果还不错。:)



Tips：双击可转为全屏播放模式。

怎么做已经在这篇文章里面说得很清楚了。






注意事项：
1、在Windows Vista下安装和使用WSS、MOSS都是不被Microsoft支持的，也就是说，如果出了问题，得不到任何Microsoft官方的技术支持...
2、如果你不是非要使用Windows Vista，还是装Windows Server 2008 + SharePoint吧...
3、不要认为你的程序在Windows Vista + SharePoint下运行正常了，那么在Windows Server 2003/2008 + SharePoint的生产环境中就一定会运行正常，一定要测试！

虽然我一直认为WSP Builder比VSeWSS好用很多，但似乎使用VSeWSS的人还是比WSP Builder多很多，所以...

最新的VSeWSS文档下载，包括了多篇不错的指导文档，以及各种典型VSeWSS项目的Walkthrough。

另1：能够支持VS 2008的VSeWSS版本计划在6月份发布。
另2：STSDev 1.3发布了，这是STSDev 2.0之前的最后一个版本，基本上是一个bug fix version。STSDev开发团队对2.0有一个很大的计划，除了功能上的改进，还打算也弄成一个VS Add-in的模式。我曾发邮件给他们抱怨说，现在VS Add-in已经够多了（WSPBuilder、VSeWSS、AC's VS SharePoint Project Utility Tool Window），Developer通常不喜欢为了同一个目的在自己的VS里面装太多插件。他们的回信很简单：“我们的目标就是把上述功能重复的Add-in都干掉”...

<Module Name="" Path="" Url="">
  <File Name="" Path="" Url="" />
</Module>

Module:
Name : 磁盘上放置文件的文件夹的名称
Path : 在"Name"属性中指定的文件夹在磁盘上相对于\\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Features\Feature的路径。如果文件夹是直接放置于Feature目录，那么Path应该是空。
Url : 要拷贝到站点的哪个目录，目录的路径是相对于站点根目录的。如果站点中没有此目录存在，则会自动创建此目录。

File:
Url : 文件在站点中的名称
Path : 文件在磁盘上相对于\\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Features\Feature的路径。
Name : 通常不需要制定Name属性的值，留空即可。如果不为空，则会覆盖Url属性的值，使文件在站点中用Name指定的名称。

举例：
Feature源文件结构如下，在“AModuleSample”这个Feature目录中还有一个“AModuleSample”子目录，其中有“readme.txt”这个需要provision的文件：


那么Module和File就要写成下面这样：


上面的Module和File元素的定义表明，我们希望将readme.txt文件以newname.txt的名字放到站点的NewFolderInSite目录中。所以，激活此Feature之后，站点上就会多这样一个目录和文件：