以前在SharePoint中配置列表，库，网站列，内容类型，列表定义等时，我通常使用通过WSP部署的SharePoint功能 - 或使用PowerShell脚本。这意味着我有一个可以部署到DEV / TEST / PROD的软件包。
我在Office 365中使用SharePoint，并且不确定在SharePoint中配置列表/库/功能的最佳方法。
选项：
无代码沙盒解决方案 试图避免使用这些作为Microsoft提供的关于它们是否被弃用的信息是不稳定的 - 但沙盒解决方案将允许我部署具有列表定义的功能等。我知道使用c＃的沙盒解决方案肯定已被弃用，但没有代码解决方案的信息是差。
应用 我知道应用程序可以在应用程序和主机Web级别进行配置，但是使用CSOM创建列表，库等似乎需要付出很多努力并且后退一步。
的PowerShell SP Online PowerShell远不如内部SP强大。我可以通过此设置网站集，但不能提供列表或库...
我非常想知道其他开发人员如何部署到Office 365，特别是围绕使用特定列表定义，库，内容类型等配置网站...
由于
答案 0 :(得分：3)
Microsoft确实澄清了No Code Sandbox解决方案的立场 - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
此外，如果您正在考虑使用Powershell进行部署，那么您可能希望沿着PowerShell中使用CSOM的路线走向 - SharePoint 2013的SharePoint客户端浏览器适用于设置会话也非常适合查看内容365租户 - http://spcb.codeplex.com/
答案 1 :(得分：0)
我已经使用基于代码的提供近两年而没有任何问题。 服务器端模型工作得很好，CSOM有一些限制但是很酷，JSOM可以提供与CSOM和SSOM相同的功能集，排序95％：）
PowerShell不是最好的选择，因为它很难集成到CI中，进行一些单元测试和回归。
如你所说，这是＆＃34;退一步＆＃34;，但如果你没有任何框架或基础。我的库是内部库，但是在codeplex和SPMeta2上有SPGenesis。 由于社区并不真正关心，需要或者使用这样的库供应（是的，让我们面对它），所以有很多这样的库，但是有很多＆＃34; MVP＆＃34;样本sorta＆＃34; hello world＆＃34;水平。
最后，我建议将您的时间和精力投入到基于代码的提供中。 这是一个未来，就是它;）
<强> UPD
挣扎于SharePoint的API不一致，错误，＆＃34;按设计＆＃34;行为，无法负担的时间来编写，支持和升级WSP包和XML，一群热情的SharePoint专业人员决定提出强大，可测试和可重复的方式来部署诸如字段，内容类型，库，页面等工件
享受并告诉我们它是如何发展的。