Visual studio VS2005&x2B的最佳项目格式；SharePoint部署？

首先，让我用一句话来表达我的沮丧：天哪，为SharePoint开发真是一团糟

好的，对不起，让我集中讨论一个特定的场景。我开发了（VS2005）一些功能，如果我将其作为DLL部署到SharePoint（MOSS2007）服务器上，这些功能就可以正常工作。现在，我正在尝试确定将其打包为可部署功能的最佳方式

根据搜索结果，你会认为从来没有人能以可重复的方式成功地做到这一点！每一篇文章都与下一篇文章相矛盾，或者记录了一种用其他人的技术修补某些问题的技术，而这一技术又可能在另一篇文章中更新。许多似乎基于2003、WSS等的旧方法。有些建议使用MSBuild任务部署到代码中，手动将文件复制到名为“12”的目录中，或使用SharePoint Designer等工具，或直接对服务器进行修改。这些听起来像是开发人员用来安装在测试服务器上的黑客。有没有人曾经创建过一个项目，在成功构建之后，它可以被带到另一台机器上，并通过STSADM使用安装程序或单个命令行指令进行部署

我承认我对SharePoint管理只有初步的了解，但这一定比看起来容易。我想我理解的基本概念，但有没有一种方法来自动化呢？对于要在2007服务器上部署的打包功能，必须有一个推荐做法。。但就我个人而言，我不知道是哪一个。（我最好的猜测是它是这样的：，但自2007年2月以来一直没有更新过。）

---

有人能帮忙吗？非常感谢

街谈巷议通常围绕SharePoint开发的三个选项展开

，根据您的规格预先创建VS解决方案

，我的偏好是因为它与集成

所有这些都有优点和缺点，我建议你尝试这三种方法，以找到你的偏好

---

.b

使用了VSeWSS 1.2之后，我建议创建一个STSDEV解决方案，该解决方案可以封装代码并将Web部件复制到正确的位置

更新 然而，VSEWSS1.3现在是微软的“官方”版本，在未来的VisualStudio版本中将得到支持，所以这可能是现在应该采取的路线

不幸的是，您仍然需要知道每个东西都必须放在何处才能进入SharePoint以使其正常工作。在幕后，解决方案和功能仍然使用粗糙的XML格式来控制解决方案的所有部分的方向

---

过了一段时间，你会感觉到剧烈的疼痛，然后慢慢消失。

谢谢，我会试试WSPBuilder和STSDEV！将根据我的发现重新选择“正确”答案：）WSPBuilder是构建功能的前进方向。话虽如此，只要您想要实现更复杂的特性，您很快就会陷入XML的深渊。谢谢，我将尝试一下STSDEV！我会回来根据我的发现挑选“正确”的答案：）很高兴听到事情变得容易了。我真的需要一些阿司匹林来止痛