转帖：[Best Practice]如何在SharePoint团队开发中利用WSPBuilder
本文关注SharePoint开发的Assembly Development（何为Assembly Development，请参见http://msdn.microsoft.com/en-us/library/bb428899.aspx）
WSPBuilder
到目前为止，我觉得WSPBuilder是SharePoint社区中最好的辅助开发工具之一（VSeWSS 1.3 CTP版本有一些功能就是“模仿”了WSPBuilder，呵呵）。
WSPBuilder的特点是根据文件夹结构来生成WSP文件，这是我个人觉得WSPBuilder最好的特性，也是最有用的功能。现在，CodePlex上WSPBuilder提供了Visual Studio Addin的安装项目，该Extensions也可以在Visual Studio 2008上使用，该Extensions使得WSPBuilder更好的融合到Visual Studio的开发操作中，安装完“WSPBuilder Extensions 1.03 - Visual Studio Addin (0.9.8.0830)”后，你打开Visual Studio可以有如下WSPBuilder项目：
在创建好的WSPBuilder项目后，右键点击项目可以看到以下WSPBuilder菜单：
以上菜单中，值得注意的是以下两个：
> Build WSP: 创建WSP文件，仅仅是创建而已，不会帮你部署！有很多时候我们其实只需要WSP文件（使用VSeWSS的人应该很希望VSeWSS也能这样）
> Attach to IIS Worker Processes: 不用在点好几步，然后查找w3wp.exe进程，然后附加了，只要点一下即可开始调试！
SharePoint的团队开发
在SharePoint团队开发，我感觉比较焦点的话题有几点：
0）团队开发怎么个模式比较好；
这个请先看看http://msdn.microsoft.com/en-us/library/bb428899.aspx；
然后，我补充一点我个人的看法：
> 你会需要一个集中代码管理服务器，SharePoint开发集成环境，SharePoint测试服务环境，然后你会想要自动编译部署（WSPBuilder为你的这个愿望提供了很好的基础）
> 我偏向于程序员每个人都有自己的SharePoint开发环境（与生产环境相同的版本），环境中的Visual Studio有Web Application开发模板，安装WSPBuilder 的Visual Studio Extensions。
> 如果有条件开发人员的SharePoint环境使用虚拟机为好（如果SharePoint环境坏了，恢复快，好处肯定不止这个）。
> 另外，开发人员应该有一个非Windows Server的环境（用来自己做测试用，模拟一个真正的开发机和客户机环境，所有的开发测试都在SharePoint环境里面做是不明智的，很多时候你会发现当用客户机访问的时候，问题才能暴露）。也就是说，或者开发人员本机是非Windows Server环境，虚机是SharePoint开发环境；或者是本机是SharePoint环境，有一个非Windows Server的虚机环境。
1）开发的各种SharePoint部件（事件处理、Web Part、模板等）怎么方便的组合起来集成部署（知道用WSP，但是总是没有找到比较好的实施的方法）；
做Solution Package的最主要的问题在于
a、如何正确的使用Solution Schema里的Element来部署不同的开发产出；
b、编写正确的manifest.xml文件，打包成WSP文件
WSPBuilder的好处就在于，你需要做的就是把开发出来的东西放对文件夹！其他一切交给WSPBuilder
使用WSPBuilder自己的模板创建出来的项目，WSPBuilder会自动生成正相应的文件夹结构
所以，我的做法是使用WSPBuilder项目加上Visual Studio的Post-Event来满足要求：
1、专门创建一个WSPBuilder Project，作为维护创建WSP文件的文件夹结构的项目（也就是说专门用来生成WSP文件的项目）；
2、为不同的功能模块（某个Web Part、事件处理程序等）创建不同的项目，这样方便进行代码管理，工作分配，多人协作，创建的项目加入到第一步创建的解决方案中；
3、然后接着就是在WSPBuilder Project项目中，创建文件夹，直到每个功能模块对应的项目都能在该项目中找到相应的文件夹；对于每个功能模块对应的项目则在Post-Built中加入命令行脚本，使在编译通过以后，把编译的结果拷贝到第一步创建的项目的文件夹目录下。
---------------------------------例子开始了----------------------------
举个例子，你创建一个WSPBuilder的项目作为维护生成WSP文件的项目：
创建一个Web Part项目（用的是VSeWSS的Web Part模板），加入到解决方案中
在WSPBuilder项目中，添加一个叫DemoWebPartFeature的Blank Feature：
解决方案变成：
我会把自动生成的elements.xml文件删除，然后修改feature.xml文件：
把ElementManifests节改成以下样子：
<ElementManifests>
<ElementManifest Location="WebPart1.xml"/>
<ElementFile Location="WebPart1.webpart"/>
</ElementManifests>
然后在WSPBuilder项目中创建出80\bin目录，这时候解决方案样子如下：
然后，对DemoWebPart项目做一些设置，首先把WebPart1.webpart和WebPart1.xml文件的属性改成“Copy Always”，这样在该项目的Debug目录中会出现这两个文件:
接下来，就是在Post-built中添加Copy命令行，把生成的文件拷贝到WSPBuilder项目对应的文件夹下：
copy "$(TargetDir)DemoWebPart.dll" "$(SolutionDir)WSPBuilder\80\bin\";
copy "$(TargetDir)WebPart1\WebPart1.xml" "$(SolutionDir)WSPBuilder\12\Template\Features\DemoWebPartFeature";
copy "$(TargetDir)WebPart1\WebPart1.webpart" "$(SolutionDir)WSPBuilder\12\Template\Features\DemoWebPartFeature";
这样，整个项目的初始创建和设置就完成了，把项目迁入到代码管理服务器中，以后就不需要再改动这些设置了。
当你编译DemoWebPart项目的时候，WSPBuilder项目的文件夹下就会是如下样子：
在WSPBuilder项目的文件夹里面就已经有了所有DemoWebPart相关的文件了，然后我们可以在WSPBuilder项目中创建WSP文件（Deploy和Upgrade菜单在第一次点击Build WSP后才会变成可用）
所有在WSPBuilder解决方案中的项目右键点击都会出现以上菜单，可以方便的点击“Attach to IIS Worker Processes”来调试。
---------------------------------例子结束了----------------------------
这样的话
> 开发人员的工作过程就是：从代码管理服务器上获取解决方案的最新版本，然后迁出自己开发的项目，直接选择Deploy Solution，WSP会生成并自动部署到他的环境中，然后在代码中设置断点，点击“Attach to IIS Worker Processes”即可进行调试。
> 集成人员的工作过程：从代码管理服务器上获取最新的项目版本，然后Build WSP，把WSP部署到开发集成服务器上。这个过程，大家可以想象，使用自动build部署的方案完全是可以完成的。
2）可视化Web Part开发的最佳实践；（下一篇文章，我会介绍一个WSPBuilder和QuickPart合作进行Web Part开发的好方法）