如果要在SharePoint上放置表单，是否更容易使用InfoPath或者在C＃中构建自定义Web部件？我还应该考虑其他选择吗？

每个选项的要求和障碍是什么？

解决方案

我们能更详细地了解表单和共享点版本吗？

这取决于Sharepoint版本：如果我们有2003，则要使用InfoPath，也必须在客户端上安装它。在SharePoint 2007上，我认为这不是必需的。

如果它是一种大型格式，几乎没有业务规则，那么可以使用InfoPath->所见即所得，并且易于部署。

如果表单涉及更多业务规则，则_layouts中的Web部件或者页面可以"更简单"并且更易于维护。

使用InfoPath构建表单绝对是在SharePoint中发布表单的最简单方法。请注意，它有很多限制，我们可能会发现自己试图提出一些有问题的逻辑或者需要其他功能。

当然，Crequires Cknowledge编程和SharePoint的API知识。此外，完成后，必须由SharePoint发布并信任生成的DLL，这需要sysadmin进行干预。这可能并不总是可用，并且在我们下次尝试升级SharePoint时可能会出现问题。

最后，我建议尝试仅使用SharePoint的内置功能来完成大多数工作(包括表单)。如果稍微深入研究，我们会发现实际上可以通过仅定制List的视图，安排字段顺序，添加自己的列(和站点列)等来构建复杂的应用程序。这种方法是纯SharePoint。不需要额外的知识(和人员)。

Infopath急于快速构建表单并将其扔到Sharepoint上。
我希望它比构建自定义Capp快1000倍。

实际上，我们不需要太多有关SharePoint API的知识即可创建自定义Web表单。这是一个非常简单的过程。我没有任何方便的链接，但是应该有多个" hello world"示例供我们使用。 SharePoint Web部件中比较棘手的部分是如何最好地调试和部署它们。

我认识一些顾问，他们在笔记本电脑上本地运行着一整套虚拟服务器，因此可以使用所有工具。对我来说，这不是一个选择。我的小组利用System.Web.UI.WebControls.WebParts.WebPart，因此我们可以在部署到我们的开发环境之前进行本地测试。请注意，如果走那条路，我们将无法在本地进行全面测试，因为我们将缺少一些SharePoint元素，例如样式表和系统提供的Web部件。至于部署，我们仍在研究细节。我们可以手动执行此操作，但这对于锁定生产环境不是很好。一种审查方法是"功能"；尽管我不确定我们如何处理它的错误修复，但将其作为单个安装程序应用新的增强功能看起来很有希望。

它可能会取决于思维方式

例如
1.如果我们试图将控制权交给最终用户以便自己定制表单，则可以使用Infopath。

Infopath非常易于理解，开发。为了使用信息路径，我们必须学习Infopath，Infopath Form Services和Sharepoint api才能将Dotnet(C＃)和Sharepoint整数化。