など、特長、私はSharePointユーザーコントロール（ないWebパーツ）を構築したとソリューションを経由して、それを展開していますWebコンポーネント

Question

のためのファームレベルのデータを格納する

それは、市販の部品だと私はできるようにしたいです登録されたライセンス情報を保存します。私はすべてのライセンス供与を受けていますが、情報を格納するための「グローバル」（つまりファームレベル）の場所を探しています（マルチサーバーファームで動作するように）。

これは商用コンポーネントを対象としているため、セキュリティポリシーやアプリケーションプールアカウントなどを制御することはできません。ファームを再構成する必要のない管理者なしで作業する必要があります。

私が考えられてきました：

• のWeb.config - これまでのところ最良の選択肢が、Windows UACが干渉することを読んだことがあると変更が常に適用されない場合があります。

• 階層オブジェクトストア - いくつかのセキュリティの落とし穴 - すなわち、アプリケーションプールが構成データベースにアクセスする必要がある（多くの環境が許可されません）

• ルートサイトのプロパティバッグ - 可能。登録時にすべてのルートサイトのプロパティを更新できますが、新しいウェブアプリケーションを作成するとどうなりますか？ユーザーは各Webアプリケーションのコンポーネントを登録する必要がありますか？

• レジストリ、ファイルシステム - サーバ

• カスタムDB間で保持しない - これが失敗するための多くの場所のように思えます。

私は他の商用ベンダーが何とかしていることは知っています。

アイデア？

Answer 1

Web.config - これまでの最良のオプションですが、Windows UACが干渉して変更が適用されるとは限りません。

設定の内容をweb.configに入れることについては、多くの意見があります。個人的には、ではなく、がおすすめです。SharePointは自動的に変更をプッシュしているため、何が起こっているのかを実際は制御できません。

同様の要件がありましたが、SiteCollectionレベルでした。私がしたことは、私のSiteCollectionのルートに2つの列（Key、Value）を持つ簡単なカスタムリストを作成することでした。私のコードでは、リストの名前をハードコードし、必要な値にアクセスするために昇格された権限を使用しました（私はリストの権限を管理者のみに設定しているためです）。

基本的に同じことができますが、SiteCollectionレベルのルートではなく、サーバーの全体管理で実行できます。これにより、SharePoint内のどこからでも構成リストにアクセスできます。

もう1つの考え方は、単純な構成データベースを設定し、カスタムWebサービス（SharePoint内に展開されている）を使用して値を取得することです。しかし、このような「シンプルな」タスクにかなりのオーバーヘッドが加わり、適切な例外処理/ロギングがなければ、多くの問題が発生します。