Sandbox -Lösungen scheinen zu stark verkrüppelt zu sein

Question

Ich lerne SharePoint und die unterschiedlichen Lösungen, die Sie bereitstellen können. Aus dem Training, das ich anschaue, scheint es, als ob Sie Ihr Bestes geben sollten, um eine Sandbox -Lösung zu verwenden, wenn dies immer möglich ist. Dies liegt daran, dass Farmlösungen die Dinge zu sehr durcheinander bringen können.

Zwei der wichtigsten Dinge, die ich mit Webparts machen würde, werden jedoch in Sandbox -Lösungen nicht unterstützt. Dies sind visuelle Webparts und Webpart -Kommunikation. (Der erste ist nicht erlaubt, da es das Dateisystem treffen muss und der zweite nicht zugelassen ist, da es Reflexion verwendet).

Es scheint mir, dass meine Webparts immer mindestens eines dieser Dinge tun wollen. (Webparts, die nicht kommunizieren, sind nicht wirklich so modular, oder?)

Vermisse ich den Punkt oder sind Sandbox -Lösungen eine "schöne Idee", die nicht wirklich im tatsächlichen Code verwendet wird?

Answer 1

Ja, ich stimme Ihnen zu, dass Sandbox -Lösungen sehr restriktiv sind.

Aber es ist diese Einschränkung, die ihnen ihren Wert gibt. Aufgrund der Einschränkungen kann eine sandkäfige Lösung einen Bauernhof nicht abbauen (mindestens die Theorie ist jemand einen Weg, dies zu tun).

Dies bedeutet, dass Sie sich vielen weiteren Benutzern öffnen können, um Dinge auf der Farm einzusetzen. Es ist auch eine Voraussetzung, um Dinge für SharePoint online bereitzustellen.

Dass Sandbox -Lösungen restriktiver sind, bedeutet, dass die Entwicklung umständlicher ist, Sie müssen sich die Beschränkungen umgehen. Dies macht Lösungen teurer. Daher sollte der Standard die Farm sein, es sei denn, Sie haben einen guten Grund, ihn nicht zu verwenden.

Answer 2

Ich denke Bessere Sicherheit der Farm. b) Sie können darauf vertrauen, dass ein SB die Farm nicht senken wird, sie nicht einmal im Rahmen des normalen SharePoint -Arbeiterprozesses läuft. Stattdessen werden sie unter ihrem eigenen Prozess gehostet, der als Host fungiert eine SB -Lösung erlaubt. c) Die Cloud kommt, es gibt keine Ausrichtung von dieser Tatsache, wenn jemand anderes Ihre SharePoint -Lösung hostet, denken Sie wirklich, dass Sie Zugang zur Farm erhalten?

Ich denke, das Verständnis der Auswirkungen des Laufen SharePoint -Lösungen, denken Sie an Ihre Lösung mit der minimalen Menge an Berechtigungen standardmäßig, wenn es wirklich keinen anderen Weg gibt, dann erkunden Sie Farm -Lösungen.

Hier ist eine nützliche Anleitung von MS:

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

Answer 3

Wenn Sie mit Ihrer Umgebung Farmlösungen installieren können, sind Sandbox -Lösungen restriktiv und verhindern, dass Sie das tun, was Sie wollen.

Wenn Ihre Umgebung jedoch keine regelmäßige Lösungsbereitstellung zulässt, wie dies bei gemeinsamem Hosting und einigen großen Unternehmen der Fall ist, sind sie nicht restriktiv, da Sie ohne sie überhaupt keinen benutzerdefinierten Code verwenden könnten.

Answer 4

Sandbox ist schrecklich, ich stimme der Aussage "Es ist diese Einschränkung, die ihnen ihren Wert gibt" völlig nicht einverstanden. Sie können in Sandbox nicht viel tun. 1. Keine Sitzung 2. KEINE WEB-PART-Kommunikation 3. Keine Datei-Upload-Steuerelemente 4. Keine Umleitung ...

Und es macht die Dinge nur höllisch schmerzhaft. Wir befinden uns mitten in der Entwicklung einer Unternehmensanwendung, mit der externe Benutzer konfrontiert sind, mein Rat, wenn Sie Sandbox für diese Zwecke in Betracht ziehen, würde ich sagen, dass Sie 150% mehr Zeit für Ihr Projekt hinzufügen, um mit Sandbox -Problemen zu befassen.

Die meisten Menschen sprechen über Vorteile, aber alle Vorteile sind nicht wirklich Vorteile. Wenn sogar ein einziger Sandbox -Anwendungscode eine Ausnahme ausschaltet, die nicht behandelt wird ... viel Glück, wird er den gesamten Farm zum Absturz bringen und das Problem verfolgt, ist echt Albtraum.

Wenn Sie sich aus Sandbox heraushalten können