私はSharepointのアプリケーションを開発する方法を学んでいます。Sharepointのアプリケーションを開発するにはどのような方法がありますか？
にアクセスするには、SharePointアセンブリを参照していることは正しいとCOMです私は何かを欠いているか？
範囲、要件などによっては、SharePoint用に開発する方法がかなりあります。私の知るところは、2010年よりもSP2007の領域であり、私の答えはそれを反映しています。あなたは、SharePointのの外観をカスタマイズリストデータと相互に作用し、ちょうどjQueryとSPServicesプラグインを使用して、いくつかの興味深いUIエフェクトを行うことができますコンテンツエディタWebパーツを使用して
はJavaScript
。これらのソリューションでは、パッケージと展開は必要ありません。
カスタムコンテンツタイプ
これらはSharePointのUIを介して作成またはカスタムXML文書を定義し、WSPを経由して導入することができます。基本的には、これらは論理的に関連したフィールド定義の集合です。コンテンツタイプをリストに追加して、すべてのフィールドを自動的に利用できるようにすることができます。さらに、私はこのような使い方はしていませんが、同じリスト内のデータを混合して照合する便利な方法を提供します（ロールアップやリストデータのバックアップを考えてください）。
イベントレシーバー
イベントレシーバは、SharePoint内の特定のイベントに応答するために作成することができます。イベント受信者をリストに添付すると、項目や添付ファイルの追加、更新、削除などのイベントを同期（-ing）の方法でリッスンして応答することができるため、検証を実装して操作をキャンセルできます。非同期（-ed） - SharePointでアイテムの処理が完了した後で、後処理を行うイベント受信者は、イベントをトリガした要求を処理したフロントエンドSharePointサーバーによって処理されます。これは、ファーム内の任意のサーバーによって実行されるタイマージョブおよびワークフローとは、使用可能な状態ではありません。
さらに、イベントレシーバは、そのタイプに基づいてリストにアタッチすることができます（このIDタイプのすべてのリストに適用）。または、コンテンツタイプに関連付けてリストに関連付けられます（コンテンツタイプがリストに追加されます。イベント受信者も追加されます）。
フィーチャーレシーバは、彼らがアクティブ化またはいくつかの追加の作業を行うために非アクティブ化されているフィーチャー への対応という点で、イベントレシーバの特別な種類です。多くの人はこの特別な作業をFeature Staplingと呼んでいます。これは、XML文書だけでは実行できない追加のタスクをオンデマンドで実行できるためです。
タイマジョブ
Aタイマージョブは、スケジュール上で実行されるコードの一部です。 Event ReceiverのようなW3WPプロセスではなく、TimerService経由で実行されます。このため、SPRequestオブジェクトには特定の機能や値がありません。タイマージョブの開発は、イベントレシーバよりも難しく、実際にはエラーが発生しやすく、デバッグが難しいなどの問題があります。
ワークフロー
ワークフローは、SharePointデザイナーまたはVisual Studioを使用して作成することができます。これらの主な違いは、設計時に使用できる機能です。 SharePoint Designerワークフローは作成しやすくなりますが、SharePoint 2007ではバグが多い傾向があります。さらに、それらは環境全体で簡単にパッケージ化され、展開されるのではなく、作成したリストに直接関連付けられます（2007年、より複雑なカスタマイズのためにVisual Studioへのパッケージングまたは移行を可能にする拡張機能）。
Visual Studioを使用すると、より深みと機能が向上しますが、タイマージョブのように、「正しく」取得することが難しく、タイマーサービスプロセスでも処理されることがあります。
Webパーツ
カスタムWebパーツは、SharePointのコンテキスト内で、いくつかの拡張機能を備えた通常のASP.NET Webパーツと非常によく似ています。あなたはSPRequestオブジェクトにアクセスすることができます。したがって、すべてのコンテキスト情報（現在のユーザー、現在のリスト/ Web /サイトなど）が作業を行います。 Webパーツは、あなたのニーズには十分ではありませんか、ページ全体を制御したい場合は、カスタムASPXページ
など、ほとんどのASP.NETコントロールを利用して、を外部データベースにアクセスすることができ、 SharePoint対応のWebページを作成できます。これらは、適切なSharePointマスタページで装飾され、ハイブLAYOUTSディレクトリのサブディレクトリに展開された標準ASP.NETページです。これにより、Webパーツと同じように現在のリクエスト状態に同様のアクセス権が与えられますが、ページ全体のレンダリングをより詳細に制御できます。
カスタムWebアプリケーション
スタンドアロンアプリケーションの必要性を持っている場合、あなたはまだ、そのコンテキスト内で直接実行することなく、SharePointの認証および承認ツールを活用することができます。これを行うには、IIS Webアプリケーションを作成し、アプリケーションプールIDをSharePointと同じに設定します。または、SharePointアプリケーションプール内に仮想ディレクトリを作成することもできますが、これは一般的に推奨されていません。 SharePointオブジェクトモデルをまったく使用する場合は、.NET Framework 2.0ランタイムを使用するように制約されます。この設定は、カスタムASPXページやWebパーツを使用するだけで、ほとんどの場合ニーズを満たすことができるため、現場ではほとんど使用されていないようです。あなたの具体的な質問については
：
サンドボックスソリューションはなど、名前空間をあなたのWebパーツを制限ソリューションのほんの特殊なタイプですへのアクセス権を持っています。たとえば、あなたのコードは、その許可領域外のリストにアクセスすることはできません。あなたの代わりに電子メールを送信することはできません。カスタム権限セットを使用して権限を増やすことはできますが、これは高度なトピックです。私はちょうど "サンドボックス化されたソリューション"がそれ自体のタイプではないことを指摘したかったのですが、以前は存在しなかった制限が記述されています（SP 2007 GAC展開ソリューション）。
SharePointオブジェクトモデルを使用したMVCアプリケーションに関するご質問については、私が述べたように、まだ.NET 2.0ランタイムでの実行に制限されています。
編集：もう1つのオプションを忘れてしまった！
一覧サービス/その他ASMXサービス
SharePointのは、あなたが他のものの中リストと対話するために消費することができるWebサービスの数を持っています。この場合、アプリケーションは、ASMXサービスをどのように使用するかを知っている限り、任意のテクノロジ（またはランタイム）を使用して開発できます。利用可能な機能は、オブジェクトモデルを直接使用するほど豊富ではありません（なぜなら、私はそれを頻繁に考慮するのを忘れています）。しかし、コードをSharePoint環境からより分離することができます。 2010年には、さらに大きな機能を提供するためのClient Servicesの選択肢が増えています。
ビジュアルスタジオでソリューションを開発するには、Sandboxソリューションとファームソリューションをご利用ください。 SharePoint 2013をお持ちの場合は、App Partの開発というもう1つの選択肢があります。
サンドボックスソリューションはSharePoint 2013以降では使用できないため、サンドボックスソリューションを使用しないでください。 App Partの開発を進める方がよい。
他の多くのものは、タイマージョブ、イベントハンドラ、Silverlightまたは.netなどのクライアントアプリケーションなどです – Shoban