沙盒解决方案似乎过于严重瘫痪

Question

我正在学习SharePoint以及您可以部署的不同类型的解决方案。从我正在观看的训练看来，你应该尽可能地使用沙盒解决方案。这是因为Farm Solutions会把事情弄得太乱。

但是，Sandbox Solutions不支持我对WebParts做的两件主要事情。这些是Visual WebParts和WebPart通信。 （第一个是不允许的，因为它需要命中文件系统而第二个是不允许的，因为它使用反射）。

在我看来，我的WebParts总是想要做至少其中一件事。 （不通信的WebParts实际上不是模块化的吗？）

我是否忽略了这一点，或者Sandbox Solutions是一个“好主意”，并不是真正用于实际代码的？

Answer 1

是的，我同意您的看法，Sandbox解决方案非常严格。

但是，正是这种限制赋予了他们自己的价值。由于这些限制，沙盒解决方案无法打倒一个农场（至少理论上，有人可能会找到一种方法）。

这意味着您可以向更多用户开放以在服务器场上部署内容。还需要将内容部署到SharePoint Online。

Sandbox解决方案限制性更强，意味着开发更加繁琐，您必须按照限制进行编程。这使解决方案更加昂贵。因此，除非您有充分的理由不使用它，否则默认值应为farm。

Answer 2

我认为这里的一些评论缺少Sandbox解决方案的全部内容，因为许多原因，他们故意被授予一组减少的权限： a）网站集管理员可以添加SB解决方案，因此他们不需要是服务器场管理员，因此可以提高服务器场的安全性。 b）您可以相信SB不会关闭服务器场，它们甚至不会在正常的SharePoint工作进程下运行，而是在它们自己的进程下托管，该进程充当主机以检查访问的资源是否是允许SB解决方案。 c）云即将到来，当有人托管您的SharePoint解决方案时，您无法摆脱这一事实，您是否真的认为您可以访问该服务器场？

我认为从非开发人员的角度理解作为Sandbox解决方案运行的影响很重要，毕竟您不会创建任何类型的自定义解决方案并期望客户授予您域级帐户来运行它，因此，在创建SharePoint解决方案时，请考虑默认情况下使用最少的权限运行解决方案，如果实际上没有其他方法可以探索服务器场解决方案。

以下是MS的有用指南：

http://msdn.microsoft.com/en-us/library/ff798382.aspx

Answer 3

如果您的环境允许您安装服务器场解决方案，那么沙盒解决方案是限制性的，并阻止您按照自己的意愿行事。

但是，如果您的环境不允许进行常规解决方案部署，就像共享主机和一些大型企业那样，那么它们就不具有限制性，因为没有它们就根本无法使用自定义代码。

Answer 4

Sandbox非常糟糕，我完全不同意“正是这种限制给了他们价值”。你不能在沙盒中做很多事情。 没有会话 2.没有网络部分的沟通 3.没有文件上传控件 4.没有重定向......

它只是让事情变得痛苦。我正在开发面向外部用户的企业应用程序，我的建议是，如果您考虑使用Sandbox用于这些目的，我会说为项目添加150％的时间来处理沙箱问题。

大多数人谈论好处，但所有好处并不是真正的好处..例如，即使单个沙箱应用程序代码引发异常而未处理...祝你好运，它会使整个服务器场崩溃，并跟踪问题是真正的噩梦。

如果你能远离沙箱