私はSharePointと、展開可能なさまざまな種類のソリューションを学習しています。可能であれば、サンドボックスソリューションを使用するために最善を尽くすように見えるようになっています。これは、Farm Solutionsが物事をあまりにも混乱させる可能性があるからです。サンドボックスソリューションはあまりにもひどく不自由なようです
しかし、私がWebPartsで行う主な事の2つは、Sandbox Solutionsではサポートされていません。これらは、Visual WebPartsとWebPart通信です。 （ファイルシステムにヒットする必要があるため、最初は許可されず、リフレクションを使用するため、2番目は許可されません）。
私のWebパーツは、常に少なくとも1つのことをしたいと思うようです。
実際のコードで実際に使用されていない点がないのですか、またはサンドボックスソリューションと呼ばれる「良いアイデア」はありますか？
はい、私は、サンドボックスソリューションが非常に制限されていることに同意します。
しかし、それはそれらの価値を与えるのはその制限です。この制限のため、サンドボックスソリューションはファームを倒すことはできません（これは少なくとも理論であり、誰かがその方法を見つけるかもしれません）。
これは、より多くのユーザーを開いて、ファームに物事を展開できることを意味します。 SharePoint Onlineに物事を展開することも要件です。
サンドボックスソリューションはより制限が厳しいため、開発がより面倒であることを意味します。制限を回避する方法をプログラムする必要があります。これにより、ソリューションがより高価になります。したがって、使用しない正当な理由がない限り、デフォルトはファームでなければなりません。
ご使用の環境でファームソリューションをインストールできる場合は、サンドボックスソリューションは制限され、必要な作業を中止します。
ただし、共有ホスティングや大企業の場合のように、通常のソリューション展開が許可されていない環境では、カスタムコードをまったく使用できないため制限がありません。
サンドボックスは恐ろしいですが、私は「それが彼らの価値をもたらすのはその制限です」というステートメントに全く反対しています。あなたはサンドボックスで多くのことをすることはできません。 1.無セッション 2.なしのWebパーツ通信 3.なしファイルアップロードコントロール 4.無リダイレクト...
、それだけで地獄のようなものが苦痛になります。私たちは外部のユーザーに直面しているエンタープライズアプリケーションを開発しています。私のアドバイスでは、Sandboxをこれらの目的のために考えていると、サンドボックスの問題に対処するためにプロジェクトの時間を150％増やすと言います。
多くの人がメリットについて話していますが、すべてのメリットは実際にはメリットがありません。たとえば、単一のサンドボックスアプリケーションコードでも例外が発生した場合は処理されません...幸運にも、ファーム全体がクラッシュし、問題は本当の悪夢です。
サンドボックス
の外に滞在することができれば、私はここのコメントのいくつかは、サンドボックスソリューションの全体のポイントを逃していると思い、彼らは意図的に多くの理由のための権限の縮小セットを与えられている： a）のAサイトコレクション管理者はSBソリューションを追加できるため、ファーム管理者である必要はないため、ファームのセキュリティが強化されます。 b）SBはファームを停止せず、通常のSharePointワーカープロセスでも実行するのではなく、リソースとしてアクセスしたかどうかを確認するホストとして機能する独自のプロセスの下でホストされているSB溶液には許容される。 c）クラウドが来て、その事実から逃げることはありません。誰かがあなたのSharePointソリューションをホスティングしているときに本当にファームにアクセスできると思いますか？
私はサンドボックスソリューションとしてのデベロッパー以外の視点からの影響を理解することが重要だと考えています。すべての種類のカスタムソリューションを作成せず、お客様がドメインレベルアカウントを実行することを期待してくださいしたがって、SharePointソリューションを作成する場合は、実際には他の方法がない場合は、デフォルトで最小限の権限でソリューションを実行することを検討し、ファームソリューションを検討してください。ここで
は、MSからの便利なガイドです：
ハンディリンク、ありがとう。 –
難戦争が開始してみましょう;）http://www.google.co.uk/search?q=sandbox+solutions+good+bad – Ryan