SharePoint: SharePoint ソリューションの構築に関する 10 のベストプラクティス

[アーティクル]
03/22/2017

SharePoint

SharePoint ソリューションの構築に関する 10 のベストプラクティス

E. Wilansky、T. Stojecki、P. Olszewski、および S. Kowalewski

コードは MSDN コードギャラリーからダウンロードできます。
オンラインでのコードの参照

この記事では、次の内容について説明します。

SharePoint の組み込みの機能を活用する
SharePoint ソリューションを展開する
テストしやすいコードを作成する
拡張と管理のために SharePoint をブランド化する

この記事では、次のテクノロジを使用しています。
WSS、Visual Studio Extensions for WSS 3.0

1. 境界を越えるケースを把握する
2. SharePoint に組み込まれている機能を活用する
3. SharePoint 開発者の重要なタスクと情報ソースを把握する
4. サーバーを使用せずにソリューションを開発する
5. コードをテストし、依存関係を管理する
6. 継続的な統合とビルドの自動化
7. SharePoint にカスタムの構成設定の管理を任せる
8. 構成設定の配置先を把握する
9. 拡張と管理のために SharePoint をブランド化する
10. 展開可能なソリューションを構築する
まとめ
その他のヒント
可能な限り相対リンクを使用する
カスタムマスタページを作成する
自動化ビルドで InfoPath プロジェクトを処理する

Windows SharePoint Services 3.0 (WSS) と Microsoft Office SharePoint Server 2007 (MOSS) を扱う開発者が直面する課題は、SharePoint プラットフォームそのものと同じくらい複雑で多岐にわたります。このプラットフォームを使用するのが初めての皆さんは、この記事で紹介するベストプラクティスに従うことで正しい方向に進むことができます。また、SharePoint に精通している開発者の皆さんは、これらのヒントを参考に、知識を深め、議論を活発化し、結果としてすばらしい SharePoint アプリケーションを構築することができます。これらのヒントのほかに、いくつかのオンラインリファレンスも紹介します。ここで説明するトピックについて理解を深めるには、これらのオンラインリファレンスを参照してください。

1. 境界を越えるケースを把握する

SharePoint 開発プロジェクトの初期には、他のシステムと最適な方法で対話するにはどうすればよいかという疑問が生じます。SharePoint は複合アプリケーションプラットフォームなので、この問いに答えを出さなければならないことはよくあります。その場合、Web アプリケーションのレベルから SharePoint アーキテクチャを眺めてください。これが最も簡単な方法です。SharePoint のインスタンスには、複数の Web アプリケーションが含まれます。SharePoint アプリケーションのアーキテクチャについての理解が不十分な場合は、「Office SharePoint Server 2007 のアーキテクチャ概要」をお読みください。

図 1 に、Web アプリケーション内部の SharePoint との対話、Web アプリケーション間の対話、および外部システムとの対話の一般的なアプローチを示します。これらの各対話については、このセクションの残りの部分で説明します。

図 1 SharePoint システムの対話モデル

特定の Web アプリケーションのコンテキストで実行される Web パーツ、ASP.NET フォームの分離コード、または Web コントロール (図 1 を参照) を記述する際には、SharePoint オブジェクトモデルを使用してください。SharePoint オブジェクトモデルには、SharePoint と対話するために使用できる充実したクラスが用意されています。Windows SharePoint Services 3.0 と Microsoft Office SharePoint Server SDK は、これらのクラスに十分対応しています。

コンテキストは、SharePoint Web (SPWeb) または SharePoint サイト (SPSite) の破棄を処理する際に考慮すべき重要な要素です。Dispose メソッドまたはステートメントを使用して、これらのオブジェクトを明示的に破棄する必要があるケースについては、「サイト、Web アプリケーション、およびその他の主要オブジェクトへの参照を取得する」と「ベストプラクティス: Windows SharePoint Services の破棄可能なオブジェクトを使用する」で重要な情報を確認してください。

SharePoint オブジェクトモデルの観点からすると、SharePoint Web アプリケーションは重要なセキュリティ境界です。通常は、SharePoint Web アプリケーション間の対話のために SharePoint オブジェクトモデルを使用することはお勧めしません。SharePoint のセキュリティに関するその他の重要なトピックについては、「SharePoint 2007 におけるセキュリティプログラミング」を参照してください。

SharePoint Web アプリケーション間、および SharePoint と外部アプリケーション (Office クライアントアプリケーションなど) の間で呼び出しを行う場合は、SharePoint Web サービスの統合層を使用してください。これは、Visual Studio でサーバーを使用しない開発作業を行う場合に有効なアプローチです。詳細については、「サーバーを使用せずにソリューションを開発する」を参照してください。

他のシステムと対話する場合、外部 Web サービスを呼び出すのが最も一般的ですが、必ずしも最適なアプローチとは言えません。より簡単に実装できる手段が他にいくつかあります。これらの手段には、処理が格段に速いというメリットがあることもあります。たとえば、Microsoft ディレクトリサービスのプログラミングフレームワークを介して LDAP ストアを呼び出す方法や、Project Server インターフェイス (PSI) Web サービス層ではなく、Project Server レポートデータベースに対する ADO.NET を介して Project Server を呼び出す方法があります。データソースが Web サービスまたはデータベースの場合は、ビジネスデータカタログ (BDC) を使用することを検討してください。詳細については、この記事の次のセクション「SharePoint に組み込まれている機能を活用する」を参照してください。

マイクロソフトは、SharePoint コンテンツおよび構成データベースを直接呼び出してはならないケースをドキュメントで明確に示しています。にもかかわらず、一部のアプリケーションではこのアプローチが採用されています。パフォーマンスが重要なのでこのアクセス手法がとられているのか、それとも単に SharePoint フレームワークの理解不足が原因なのかはわかりませんが、もっと安全なアプローチがあります。

重要なのは、マイクロソフトはこれらのデータベースの基になるスキーマを変更でき、Web アプリケーションごとに複数のコンテンツデータベースが存在してもかまわないという点です。直接的なクエリ操作には一見問題がないように思えますが、ソリューションの脆弱性を高めるおそれがあります。そこで、この記事で説明する他のアプローチを活用するか、SharePoint の実装の整合性を損なう、最適ではないソリューションを回避するための戦略を新たに策定してください。

2. SharePoint に組み込まれている機能を活用する

SharePoint に組み込まれている機能を開発チームがフル活用するのをやめる理由は、2 つあります。まず、SharePoint はこれだけ拡張性に富んだプラットフォームなので、開発者は、独自のコーディングをせずに SharePoint で利用できる機能を把握するために時間を割くよりも、カスタムソリューションを構築する方が手っ取り早いと考える可能性があります。次に、ビジネスオーナーは、開発者が標準の (OOB) 機能を柔軟に使用できなくなるほど、要件、ワイヤフレーム、そしてアプリケーションの動作を細かく指定しがちです。

しかし、成果物が当初の要件から多少外れたものになったとしても、SharePoint プラットフォームに備わる機能を活用すれば、多くの場合、さまざまなメリットが得られます。こうしたメリットを得るためには、開発チームがテクノロジを完全に理解していることが大切です。そしてさらに重要なのは、特定の実装の価値とトレードオフについて、開発者チームがビジネスオーナーに明確に説明することです。

SharePoint の長所と短所を十分に理解することは、口で言うほどやさしくはありません。WSS と MOSS には SDK が用意されています。これらの SDK には、SharePoint でソリューションをプログラミングするときに利用できる技術ドキュメント、チュートリアル、コードサンプル、およびベストプラクティスが含まれています。情報をなかなか見つけられない場合は、.NET Reflector を使用して、SharePoint のコアアセンブリの一部を調べることもできます。図 2 には、Microsoft.SharePoint アセンブリ内の PeopleQueryControl クラスのメンバ (IssueQuery メソッドなど) が示されています。PeopleEditor コントロール (People Picker とも呼ばれる) は、SharePoint の ID ストアに対するクエリを PeopleQueryControl に委任します。また、このコントロールにより、IssueQuery メソッドをオーバーライドして既定の実装を変更できます。図からわかるように、.NET Reflector を使用すると、コンポーネントの対話の方法を詳しく調べることができます。

図 2 PeopleQueryControl の IssueQuery メソッドが表示されている .NET Reflector

プラットフォームの機能に関する知識を身に付けたら、テクノロジへの投資の意義を強調しつつ、特定の実装のメリットを関係者に明確に示す必要があります。SharePoint ほどの規模のプラットフォームでは、最初から実装の枝葉末節にこだわるのではなく、早期リリースとその繰り返しがビジネスに何をもたらすのかをクライアントにわかりやすく示すことが特に重要です。ソフトウェア開発ライフサイクル (SDLC) 全体にクライアントがかかわることのできる効果的なフィードバックメカニズムを導入することにより、クライアントが製品の機能を十分理解できるようにしてください。

多数のエンティティが含まれる選択リストをユーザーに表示する機能を実装するとき、どのような議論が起こるかを想像してください。この機能は、ASP.NET DropDownList コントロール、GridView コントロール、カスタムコントロール、サードパーティコントロールなど、さまざまな手段を用いて実装可能です。SharePoint 自体も、PeopleEditor またはその基本クラスである EntityEditorWithPicker コントロール (この目的で使用可能) を通じて項目数が多いリストの選択コントロールを提供しています。これらの Web コントロールには、独自のカスタムロジックを挿入するためのフックが多数あります。それらを利用したうえで、機能の充実した直感的なユーザーインターフェイスを活用し、一貫性のあるユーザーエクスペリエンスを SharePoint で作り上げてください。PeopleEditor Web コントロールのメソッドをオーバーライドする方法の例については、「Customizing EntityEditorWithPicker (EntityEditorWithPicker をカスタマイズする)」を参照してください。

SharePoint で基幹業務 (LOB) データを表示できるようにする作業も、よく依頼される作業の 1 つです。通常は、有効なデータソースを特定し、そのデータを SharePoint に取り込む最善の方法を突き止めることから始めます。Web サービスプロキシの作成や、データベースへの ADO.NET 接続の確立は、多くの開発者にとっておなじみの手法です。ただし、より優れた代替手段として BDC を使用できる場合があります。この SharePoint 機能を使用すると、データを外部データソースから読み取り、それを SharePoint で表示できます。BDC はさまざまな認証メカニズムをサポートしており、SharePoint 検索とリストインフラストラクチャに密に結び付けられています。また、BDC では、データエンティティ間の関連付けを作成できます。

SharePoint には、BDC を使用して LOB データを表示するための Web パーツのセットも用意されています。現時点では、BDC は create、update、および delete 操作を直接サポートしていません。しかし、これらの操作を実行するカスタムアプリケーションを作成し、BDC 操作のインターフェイスを通じてそれらを BDC に関連付けることはできます。詳細については、「リソース」の「ビジネスデータカタログ」を参照してください。

3. SharePoint 開発者の重要なタスクと情報ソースを把握する

ここでは、ソフトウェアの開発過程ですべての SharePoint 開発者が完了しなければならない一般的なタスクについて説明します。ツールのレビューではありませんし、いずれかのツールを推奨するねらいもありません。SharePoint の一般的な開発タスクを完了するために使用できる、さまざまなツールを紹介します。

採用をお勧めするアプローチの 1 つに、SharePoint ソリューションの構築があります。これについては、Ted Pattison がその「Office Space」コラム「SharePoint 2007 を使用したソリューション展開」の中で、「WSS の開発作業のパッケージ化および展開には、ソリューションパッケージを使用することがベストプラクティスです。その方法についての知識は不可欠なスキルです」とうまくまとめています。SharePoint ソリューションをパッケージ化する場合、manifest.xml ファイルと DDF ファイル (Diamond Directive File) を手動で作成する方法から、Windows SharePoint Services 3.0 ツール (Visual Studio 2005 Extensions/Visual Studio 2008 Extensions (VSeWSS)) を使用する Visual Studio プロジェクトを利用する方法まで、さまざまな方法を利用できます。

VSeWSS プロジェクトを使用する方が、DDF を手動で作成するよりもはるかに簡単です。ただし、商業または企業展開の場合に特に役立つツールが他にいくつかあります。WSPBuilder、STSDev、SPDeploy、DDFGenerator などです。さまざまなツールを評価して、自分のニーズに合った最適なツールを見つけてください。重要なのは、コードコンポーネントを手動で展開することではなく、展開用のソリューションパッケージを作成することです。

クライアント側の動作のデバッグは厄介な作業になる場合がありますが、Internet Explorer Developer Toolbar (Internet Explorer 8 の開発者ツール) などのツールを使うと、この作業が格段に簡単になります。Internet Explorer Developer Toolbar は、FireBug などの Firefox アドオンに似ています。Internet Explorer で動作するツールに、Web Development Helper もあります。どちらのツールも、クライアント側の JavaScript のデバッグ、スタイルの検査、および DOM の解析に役立ちます。IIS との対話を検査する必要がある場合は、IIS 6.0 Resource Kit に含まれている実用的な各種ツールを活用できます。たとえば、WFetch には、ページの出力情報 (カスタム HTTP ハンドラや認証ヘッダー情報の出力など) を調べて、使用されている認証プロトコルを確認できる便利な機能があります (図 3 を参照)。

図 3 NTLM 認証ヘッダーが表示されている WFetch

サーバー側コードの問題のトラブルシューティングは、SharePoint では特に困難な場合があります。Web ページが簡潔なので (あまり親切ではないので) エラーを突き止めにくいことや、エラーが Web サービスの呼び出し後にログに記録されることがその理由です。ここで最も重要なのは、SharePoint ログデータの保存場所とデバッガを使うタイミングを把握すること、そして SharePoint アプリケーションのトラブルシューティングに役立つツールに慣れることです。

アプリケーションの問題の原因を解明するには、Windows イベントログを調べることから始めてください。場合によっては、イベントログのレベルを上げることもできます。たとえば、Kerberos 認証を使用するアプリケーションを扱う場合は、システムイベントログに記録される Kerberos イベントのログレベルを上げると効果的です。Kerberos 認証についてわかりやすく解説しているオンラインリソースはたくさんあります。Windows Server 2003 での詳細な Kerberos イベントログについて、正確な情報が必要な場合は、「Windows Server 2003 における Kerberos プロトコルのレジストリエントリと KDC コンフィギュレーションキー」を参照してください。

SharePoint ログと IIS ログは、SharePoint アプリケーションのエラーのトラブルシューティングに不可欠です。この 2 つの重要なログソースについて、手短に説明します。

SharePoint ログは、<%CommonProgramFiles%>\Microsoft Shared\Web Server Extensions\12\LOGS に格納されます。Log Viewer 機能をインストールすると、これらのログを簡単に読むことができます。
IIS ログは、通常は <%SystemRoot%>\System32\LogFiles に格納されます。IIS のプロパティを調べて、ログのルートの場所を確認してください。各 IIS Web アプリケーションは固有の ID を持つので、IIS に一覧表示されている SharePoint Web アプリケーションの IIS アプリケーション ID と、LogFiles ディレクトリにあるフォルダの名前を照合できます。

カスタムアプリケーションのログ記録のために、Enterprise Library の統合を検討してください。Enterprise Library Logging と Exception Handling Application Block をコードに組み込むことで、カスタムアプリケーションのトラブルシューティングに不可欠なログ情報と例外の詳細をログターゲット (通常はデータベース) に含めることができます。

カスタムアプリケーションに潜む問題のデバッグに最も役立つツールは、Visual Studio デバッガです。Visual Studio を SharePoint サーバーにインストールしている場合、F5 キーを押してデバッグ機能を使用できます。理想を言えば、実稼働またはモデルオフィスシステムに Visual Studio をインストールすべきではありません。そこで、ソフトウェアをローカルワークステーションで開発し、ソリューションをリモートでデバッグすることもできます。SharePoint では、カスタムアプリケーションを IIS にホストしている w3wp プロセスに接続することにより、リモートデバッグが可能です。

アプリケーションを実行している w3wp のインスタンスを突き止めるには、Windows サーバーでコマンドプロンプトを開き、IISApp.vbs を実行して、SharePoint Web アプリケーションを実行しているプロセスのプロセス ID (PID) を確認します。そのうえで、Visual Studio で同じ PID を持つ w3wp のインスタンスを選択します。

Exception Display も非常に便利なツールです。このツールをファームで有効にすると、SharePoint エラーページの簡潔なメッセージをさまざまな例外表示に置き換えることができます。このツールのインストール方法と使用方法を確認するには、上記の「Exception Display」のリンクをクリックしてください。

展開されている Web パーツによってページの読み込みにエラーが生じている場合は、ページの URL の末尾に ?content=1 を追加して、Web パーツのメンテナンスページを開きます。メンテナンスページでは、問題のある Web パーツを閉じるか、ページから削除することができます。

さらに、Web アプリケーションの web.config ファイルでアプリケーションレベルのトレースを有効にできます。詳細については、「アプリケーションレベルのトレースの有効化」の説明を参照してください。

フレームワークの拡張を続けてください。SharePoint は、カスタムアプリケーションをさまざまな方法で統合する機能を十二分に備えています。SharePoint は ASP.NET 上に構築されているため、このプラットフォームの拡張ポイントを引き継いでいます。WSS 3.0/MOSS SP1 のリリースに伴い、ASP.NET AJAX フレームワークがサポートされました。そのため、ASP.NET AJAX Extensions と AJAX Control Toolkit を活用できます。SPWebConfigModification クラスを使用して AJAX 関連の web.config エントリをプログラムで追加または削除できる Ajaxify MOSS カスタム stsadm 拡張機能を利用すると、インストールと構成の手順を簡素化できます。

このフレームワークを活用すれば、AJAX コントロールスイートを使用できるほか、クライアント側のコールバックを実装してページの応答性を改善できます。これは、カスタム Web パーツから外部 Web サービスを呼び出す場合に特に重要です。詳細については、「AJAX Extensions を使用してクライアント側から Web サービスを呼び出す」を参照してください。

最近、マイクロソフトが Visual Studio でのサポートを発表したことからかなりの注目を集めている jQuery も、クライアント側フレームワークの 1 つです。jQuery のコアライブラリは単一の .js ファイルに格納されているため、SharePoint との統合は容易です。jQuery スクリプトを ASP.NET Web ページに埋め込む方法については、「jQuery Script Manager」を参照してください。

Silverlight との統合に関する情報については、「Silverlight 2 Web パーツで SharePoint に磨きをかける」を参照してください。この記事では、Silverlight アプリケーションと SharePoint の統合の例が紹介されています。

4. サーバーを使用せずにソリューションを開発する

SharePoint の開発にはさまざまな依存関係が付き物ですが、可能な限りこれらを避けてソリューションを構築することをお勧めします。Visual Studio 開発サーバー、ASP.NET Web パーツフレームワークのサポート、SharePoint Web サービス、およびサードパーティツールを使用すると、SharePoint を実行しているコンピュータではなく標準的なワークステーションで開発作業の大部分を行うことができます。

SharePoint は IIS および ASP.NET 上で実行されるため、Visual Studio に付属する Web 開発サーバーは、SharePoint のほとんどの開発作業を始めるのに最適なツールです。この比較的簡易な環境では、Web パーツ、HTTP ハンドラ、Web コントロールなどを開発できます。

最初に行う必要があるのは、コンポーネントをホストする環境をセットアップする作業の一部です。たとえば、ASP.NET Web パーツを効率的に開発するためには、Web パーツ、Visual Studio Web アプリケーションプロジェクト、および単体テストプロジェクト (必要な場合) をホストするためのクラスプロジェクトを作成する必要があります。このセットアップの例は Visual Studio SPTip ソリューション (この記事のサンプルコードに付属) に含まれていますので、サーバーを使用しない Web パーツの開発に役立ててください。

Web パーツプロジェクトの既定のコンストラクタには、Web パーツの ExportMode プロパティを設定する行が含まれています。

public WebPartOffServerExample()
{
    this.ExportMode = WebPartExportMode.All;
}

図 4 に示すように、この行により、Web パーツに対して構成したプロパティに基づいて .webpart 展開ファイルを生成できます。

図 4 Web パーツのエクスポートメニューオプション

次に、この展開ファイルを使用して Web パーツを SharePoint にインポートできます (図 5)。下位互換性のある SharePoint 2003 のインポートファイルの種類 (.dwp) は使用しないでください。.dwp の基になる XML スキーマは .webpart のスキーマほど優れておらず、開発者は SDLC の初期に Microsoft.SharePoint アセンブリを参照しなければなりません。

図 5 SharePoint にインポートされた Web パーツ

Microsoft.SharePoint.WebPartPages 名前空間ではなく System.Web.UI.WebControls.WebParts 名前空間の WebPart クラスから継承すると、.webpart 展開ファイルを確実に作成できることに注意してください (SharePoint の WebPart クラスからの継承が適切な場合の例については、「リソース」の「WebPart クラス」を参照してください)。

マイクロソフトは、SharePoint オブジェクトモデルの重要なサブセットを Web サービスを通じて公開しています。SharePoint Web サービスを使用してオブジェクトモデルにアクセスすると、SharePoint アセンブリに直接アクセスすることなくソリューションを開発できます。SharePoint では、各 Web フロントエンド (WFE) サーバーの _vti_bin 仮想ディレクトリに Web サービスをホストします。

Visual Studio で、Web サービス参照を追加するときと同様の方法で SharePoint Web サービスをソリューションに追加してください。SharePoint Web サービスの URL は、次の形式になります。

http://<SharePointServer>:port/[sites/][SubSite/]_vti_bin/WebService.asmx

<SharePointServer> の部分は、Web アプリケーションに関連付けられている URL です。たとえば、次のような形になります。

https://www.contoso.com:35000/_vti_bin/Lists.asmx

Web サービス参照を追加すると、サービスとサービスによって使用されるデータ型のプロキシクラスが作成されます。これらの Web サービスとの対話の詳細については、「Windows SharePoint Services Web サービスの紹介」と「Web サービス」を参照してください。

3 層アーキテクチャを実装すると、コードを分離し、SharePoint またはその他の外部ソースへの依存を解消するという目標に近づくことができます。このアプローチを採用した場合、ビジネスロジック、データアクセスロジック、および UI ロジックを明確に切り離し、コードを管理しやすい単位に分割してそれらの依存関係を減らすことができるため、サーバーを使用しない開発が容易になります。また、コードがテストしやすくなるというメリットもあります。このテーマの詳細については、「コードをテストし、依存関係を管理する」を参照してください。

このほかにも使用できるツールはいくつかあります。コードベース全体で SharePoint への依存をなくすのは、現実的ではありません。一般に、サーバーを使用しない SharePoint 向けの開発では、SDLC の初期に SharePoint のインスタンス (通常は仮想マシンにホストされる) を使用する必要があります。SharePoint の開発が盛んになると同時に、この大きな依存に対処するためのツールがいくつか作成されました。その 1 つが Bamboo Solutions 社の SharePoint on Vista Installation Helper です。このツールを使用すると、WSS 3.0 SP1 または MOSS 2007 SP1 を Windows Vista にインストールできるため、Windows Server を使用せずに SharePoint 依存ソリューションを開発できるようになります。

マイクロソフトは、このような方法で SharePoint を実行することをサポートしていません。しかし、このアプローチはこうした SharePoint への依存によるフットプリントを減らすのに役立つため、SharePoint 開発コミュニティでは歓迎されています。詳細については、「How to install Windows SharePoint Services 3.0 SP1 on Vista x64/x86 (Vista x64/x86 に Windows SharePoint Services 3.0 SP1 をインストールする方法)」を参照してください。

5. コードをテストし、依存関係を管理する

単体テストフレームワークと関連のテストツールが普及したため、必然的に、SharePoint の開発でも使用されるようになりました。単体テストと統合テストは、2 つの主要なテストカテゴリです。これらのテストにはそれぞれ異なる特性があり、使用するツールや手法も違います。

単体テストまたはサーバーを使用しないテストを記述する場合、スタブやモックなどを代用して外部依存関係をシミュレーションするのが最良の方法と考えられています。外部依存関係をまねるオブジェクトを渡すことにより、テストの時間が短縮されるほか、対象の動作に的を絞ったテストが可能になります。このアプローチの効果を高めるには、テストしやすいオブジェクト指向の設計の基本原則に従うか、ソリューションの密結合コンポーネントを分離するための特殊なフレームワークを使用する必要があります。

インフラストラクチャに依存しない動作とビジネスルールを特定し、それらを分けてテストするための戦略を策定してください。SharePoint、データベース、または Web サービスとの対話を分けるために、Repository パターンを導入してバックエンドシステムの詳細を抽象化できます。これらのリポジトリオブジェクトを上位コンポーネントに渡すには、制御の反転 (IoC) および依存関係の注入 (DI) の原則を利用します。IoC と DI の詳細については、「ソフトウェアの依存関係を緩和してアプリケーションの柔軟性を高める」を参照してください。

プレゼンテーションコンポーネントのテストの容易性を高めるためには、Model-View-Presenter (MVP) パターンを実装することをお勧めします。テストしやすいコードパターンの詳細については、「テストの容易性を高める設計」を参照してください。

SharePoint 開発者が単体テストの際に直面するその他の主要な課題は、SharePoint オブジェクトモデルに関係するものです。簡単に言えば、これらのコンポーネントを分けてテストするのは容易ではありません。その直接の原因は、シールクラス (内部依存関係があるか、パブリックコンストラクタのないクラス) は多数存在する一方で、インターフェイスと抽象化の数が限られていることにあります。

こうした短所を補うために使用される製品の 1 つが TypeMock Isolator です。これは、シールクラス、具象クラス、静的クラス、および内部構築クラスのモックを作成できる、市販のモック作成フレームワークです。これ以外のモック作成フレームワークを適用する場合は、先に説明したパターンと原則に準拠する必要があります。TypeMock Isolator か、その新しい SharePoint 専用バージョンである Isolator for SharePoint では、これらの制限を回避し、実行中の SharePoint インスタンスを使用することなくコードカバレッジを広げることができます。patterns and practices (P&P) チームも、SharePoint ガイダンスの参照アーキテクチャで TypeMock Isolator を使用しています。

ある時点で、SharePoint オブジェクトモデルに依存する統合テストを記述する必要があります。サーバー依存の単体テストとサーバー非依存の単体テストを分けて管理することをお勧めします。

Visual Studio でテストマネージャのテストリストエディタを使用すると、単体テストと統合テストを分けることができます。たとえば、サーバー依存のテストとサーバー非依存のテストという 2 つのテストリストを作成できます (図 6 を参照)。このアプローチにより、サーバー上で作業しているかどうかに応じて、実行するテストのセットを選ぶことができます。

図 6 分類されたテストリストが表示されているテストリストエディタ

Visual Studio がサーバーにインストールされている場合は、IDE でテストを実行およびデバッグすることも、MSTest.exe コマンドラインツールを使用してサーバー依存のテストを実行することもできます。残念なことに、Visual Studio がサーバーにインストールされていないと MSTest は動作しません。将来のバージョンの MSTest からはこのような大きな依存関係が解消されることを期待しています。

MSTest.exe では、コマンドライン引数を使用して、実行するテストを指定できます。MSTest.exe を実行するときに、/testcontainer と /testmetadata のどちらかのオプションを指定する必要があります。実行するテストを指定するには、/testmetadata オプションを使用してください。たとえば、すべてのサーバー非依存のテストを実行する場合は、次のように入力します。

MSTest /testmetadata:SPTips.vsmdi /testlist:ServerDependentTests

サーバー依存のテストのうち、特定のテストを実行する場合は、次のように入力します。

MSTest /testmetadata:SPTips.vsmdi /test:GetTasks_ShouldReturnTasks

サーバーを使用するテストとモック作成フレームワークを使用したテストの例については、この記事のコードダウンロードに含まれている Visual Studio SPTip ソリューション内のサンプルコードを参照してください。

6. 継続的な統合とビルドの自動化

コードをソース管理で保持すること、継続的に統合を行うこと、そしてビルドプロセスを自動化することは、高品質なコード資産を効率的にリリースするうえで必要不可欠な取り組みです。この環境のセットアップは、SharePoint により、控えめに言っても簡単な作業ではなくなります。そこで、まず「チーム開発の概要」を読むことを強くお勧めします。

この概要の後の方で、「方法: Team Foundation Server Build を使用して自動化ビルドおよび展開ソリューションを作成する」という SharePoint ガイダンスのトピックが紹介されています。このトピックでは、ビルドターゲットを作成してソリューションをビルドおよび展開する方法が解説されています。この方法にはメリットもありますが、企業でよくあるように、TFS ビルドと SharePoint サーバーが同じ環境に存在していない場合は使用できません。また、ターゲットを使用してソリューションパッケージをビルドする場合、パッケージを自動化ビルド環境でしか使用できなくなるため、開発者による早期開発とパッケージのテストが促進されません。

これの代わりになるのが、Visual Studio でビルド後のイベントを使用する方法です。ビルド後のイベントは、MSBuild ターゲットと同じパッケージ化手順を実行するように設定できます。また、ビルド後のイベントを使用すると、開発者は各自のサンドボックス環境への展開用にパッケージをビルドできます。このアプローチは、WSPBuilder や STSDEV などのサードパーティツールでも有効です。

企業に展開する場合は、バージョン管理ソリューションパッケージを検討しなければならないこともあります。ソリューションのバージョンを現在のビルドバージョンに関連付けるのも 1 つの手です。AfterBuild MSBuild イベントで、またはビルド後のイベントから実行されるカスタムアプリケーションコードを使用すると、これが容易になる可能性があります。また、自動化ビルドのソリューション ID と、ビルドごとに新しい ID を生成するかどうかについても考慮が必要です。この決定は、今後ソリューションをアップグレードする力に影響します。一般的には、アセンブリのバージョンが変更されたときに新しい ID を生成してください。アセンブリのバージョンが変わらない場合は、同じソリューション ID を使用します。こうすると、ビルドのバージョン ID は変わりません。

ここでは、SharePoint Server 2007 デベロッパーポータルから入手できる情報は繰り返しません。代わりに、自動化ビルドプロセスをさらに簡素化する方法を重点的に説明し、このヒントを充実させることにします。SharePoint ガイダンスのトピック「方法: Team Foundation Server Build を使用して自動化ビルドおよび展開ソリューションを作成する」では、P&P チームは読者が VSeWSS/拡張機能を使用していることを想定しています。

VSeWSS は SharePoint 開発者のツールキットに仲間入りを果たしたすばらしいツールであり、その場でソリューションを構成できる WSPView パネルなど、さまざまな機能を備えています。しかし私たちは、中規模から大規模の実装や、アジャイル開発方法論を取り入れているチームには適していないと考えています。

P&P SharePoint ガイダンスチームのドキュメントには、VSeWSS はワンクリックの展開機能と F5 キーでのデバッグ機能を備えているとあります。確かにワンクリックの展開機能は VSeWSS に組み込まれていますが、F5 キーでのデバッグ機能を使用するには、SharePoint のインスタンスに対して Visual Studio をローカルに実行していなければなりません。これは、VSeWSS のインストール要件です。VSeWSS をワークステーションにインストールするためにレジストリハックを使用することもできますが、VSeWSS をワークステーションにインストールすると、そのメリットのほとんどが失われます。

上記のドキュメントには、WSPBuilder や STSDEV などの各種ツールを使用する場合、開発者は SharePoint ソリューションのパッケージ化に必要な Feature.xml ファイルと Manifest.xml ファイルを Web ソリューションパッケージに格納する必要があるとも書かれています。しかし、これらのツールは進化を続けています。たとえば、現時点の WSPBuilder には、Feature.xml と Manifest.xml を Visual Studio 2005 および 2008 で簡単に管理できるようにする拡張機能が組み込まれています。

VSeWSS は、SharePoint プロジェクトの構成方法に自信がない場合に最も役立つツールです。たとえば、Web パーツや SharePoint ワークフロープロジェクトの構造を決定するために、VSeWSS プロジェクトを使用することができます。構成方法がわかったら、その情報を取り出し、ごく一般的な種類のプロジェクトに移すことができます。中規模から大規模のプロジェクトに VSeWSS を使用する場合、主に次のような問題があります。

VSeWSS は、SharePoint サーバー上で実行されている Visual Studio のインスタンスにインストールされるように設計されている。したがって、WSS に大きく依存する。
VSeWSS では特別なプロジェクトの種類が作成されるが、VSeWSS をインストールしていない開発者はこの種類のプロジェクトを開くことができない。
VSeWSS により、ソリューションの再ビルドが複雑になる。

ガイダンスのドキュメントでは、Visual Studio ソリューションごとに SharePoint ソリューションファイルを配置マニフェストファイル (manifest.xml) と共に手動で作成するアプローチも提案されています。ただし、WSPBuilder などのツールを使用すると、ビルドのこの手順を自動化できます。

ビルドの自動化を実現するうえで重要なのは、次の点です。

すべての開発者がプロジェクトを簡単に開けるように、Visual Studio の標準のプロジェクトの種類 (つまり、Web パーツのクラスプロジェクト) を使用する。
図 7 に示すように、コードプロジェクトを構成するときにソリューションパッケージをプロジェクトに統合する。展開プロジェクトを別に作成する必要はありません。
WSPBuilder またはその他の自動化ソリューションビルドツールを実行して SharePoint ソリューションファイルをビルドするように、ビルド後のイベントを設定する。このアプローチは、ソリューションのローカル展開と自動化ビルドプロセスの両方で有効です。
マクロ条件を使用して、ビルドの実行場所に応じて呼び出されるビルド後のイベントの各部分を制御する。
InfoPath プロジェクトの場合は自動化ビルドがさらに複雑になることに注意する。その詳細については、この記事のオンラインバージョンで「自動化ビルドで InfoPath プロジェクトを処理する」を参照してください。

図 7 Web パーツプロジェクトに統合されたソリューションパッケージの構造 (コードダウンロードを参照)

統合環境に移行するまでは、グローバルアセンブリキャッシュ (GAC) には展開しないでください。アセンブリを BIN フォルダに格納すると、カスタム SharePoint アプリケーションのデバッグが非常に容易になります。SharePoint イベントハンドラや、SharePoint フィーチャーなど、特定の種類のプロジェクトには、このモデルは不適切です。互換性のあるアセンブリを BIN フォルダに配置しておくと、共有開発環境の開発者は、展開のたびに IIS を何度も再起動せずに済みます。

BIN から SharePoint アセンブリを実行する場合は、次の指針に従ってください。

アセンブリを [assembly:System.Security.AllowPartiallyTrustedCallers] 属性で修飾する。
カスタムのコードアクセスセキュリティ (CAS) ポリシーを構成するか、次のように、web.config を完全な信頼に設定する。

<system.web>
  <trust level="Full" />
</system.web>

(信頼レベルを完全な信頼に設定してもかまわないのは、コード資産が最終的に GAC に展開されることになるローカル開発または社内開発の場合だけです)。

GAC への最終的な展開に備えてアセンブリに署名する。

7. SharePoint にカスタムの構成設定の管理を任せる

他のアプリケーションと同様に、SharePoint ソリューションを正しく動作させるためには構成設定が必要です。構成設定がわずかしかないカスタムアプリケーションであれば、おそらく手動でも簡単に管理できるでしょう。しかし、SharePoint でエンタープライズアプリケーションまたは商用アプリケーションを開発する場合は、構成設定の数はかなり多くなる可能性があります。

そのため、さまざまな設定の種類とそれらの管理方法を把握することが、アプリケーションを開発、展開、管理するうえで重要になります。SharePoint で管理する設定の数を増やし、手動管理する設定の数を減らすのが最適なアプローチです。

設定の種類を把握すると、その設定の配置先がわかります。通常、SharePoint の構成設定は、コア設定、カスタム設定、SharePoint 設定という 3 つのカテゴリに分けられます。

コア設定は、SharePoint Web アプリケーション全体で使用されます。一般的なコア設定の例としては、Enterprise Library アプリケーションブロックや外部 Web サービスの構成が挙げられます。

カスタム設定は、カスタムビルドコンポーネント用の設定です。これらの設定は、カスタムコンポーネントの構成設定を提供するために使用されます。コンポーネント以外のものとは共有されません。たとえば、カスタム設定は、LDAP 参照用のディレクトリサーバーの設定を提供するために使用できます。

ソリューションを SharePoint 内で機能させるために必要なのが SharePoint 設定です。このカテゴリの設定には、SafeControl エントリ、SessionState のカスタマイズ、HttpModule の登録などがあります。

設定を分類したら、それらを適切な場所に配置して管理できるようになります。目標は、手動で管理する設定の数を減らすことです。SharePoint で設定を処理するようにしておけば、アプリケーションの展開時に発生する可能性のあるエラーを減らせます。

コア設定は、ソース管理で管理することをお勧めします。ソース管理を利用すると、設定の履歴を管理し、信頼の置ける単一の設定のソースを維持できます。さらにこのアプローチでは、開発、テスト、実稼働の各環境用に、異なるバージョンの構成ファイルを管理できます。

SharePoint オブジェクトモデルと展開ツールを使用すると、カスタム設定のインストールと管理を自動化できます。SPWebConfigModification クラス、ソリューション展開、および SharePoint 12 ハイブの CONFIG ディレクトリを使用して、構成の管理戦略を策定してください。ソリューションを通じた展開の詳細については、この記事の「展開可能なソリューションを構築する」を参照してください。

SharePoint の SPWebConfigModification クラスを使用すると、SharePoint Web アプリケーションの web.config に設定をプログラムで登録できます。また、構成エントリを一覧表示、追加、削除するコンソールアプリケーションまたは stsadm 拡張機能を記述できます。このアプローチでは、大量の SharePoint 構成設定を一貫した方法ですばやく変更できます。このクラスの SPWebConfigModificationType 列挙体には、変更の種類を指定する 3 つの値 (EnsureChildNode、EnsureAttribute、および EnsureSection) が含まれています。この列挙体を使用して追加したエントリは簡単に削除できないので、EnsureSection を使用する際には十分な注意が必要です。詳細については、「SharePoint API を使用して Web アプリケーションの展開を自動化する」を参照してください。

SharePoint の CONFIG ディレクトリに XML ファイルを格納することで、設定を宣言的に登録できます。SharePoint が Web アプリケーションを作成するときに、WSS がこの XML ファイル内の設定を web.config に適用します。このフォルダの設定は、すべての Web アプリケーションに適用されます。このアプローチの詳細については、「Managing Web.Config Customizations (Web.Config のカスタマイズを管理する)」を参照してください。

8. 構成設定の配置先を把握する

前のヒントでは、さまざまな種類の SharePoint 構成設定と、その管理の方法について説明しました。アプリケーションは次の環境 (テスト環境から実稼働環境など) への移行に伴って昇格されるので、構成設定の変更、特に外部システムに関係する変更は、とらえどころのないもののように思えるかもしれません。しかし、構成設定の配置先を把握しておけば、環境設定を確実に管理できます。

複合アプリケーションの開発では、構成設定への依存度が高まってきています。構成設定の機能と使いやすさがその乱用の原因かもしれません。これらの設定の変更頻度を抑える方法の 1 つが、名前付け規則などから値を推測することで、"設定より規約" のパラダイムを適用することです。「継続的な統合とビルドの自動化」には、この "設定より規約" パラダイムの例が示されています。SharePoint ソリューションパッケージを Visual Studio プロジェクトに統合する方法のくだりを振り返ってください。このパラダイムに関係する例は、Web コンテンツのヒント「可能な限り相対リンクを使用する」にも示されています。

インスタンス固有の設定は、Web パーツの各インスタンス専用の設定です。プログラムマネージャ用のページにはプロジェクトの一覧を表示し、開発者用のページにはプロジェクトとタスクの詳細を表示する Web パーツを思い浮かべてください。インスタンス固有の設定は、カスタムツールパーツか、Web パーツのさまざまなツールパーツプロパティに格納することをお勧めします。

複数のコンポーネントによって使用される構成設定は、グローバル設定と見なされます。このカテゴリの設定の例としては、外部 Web サービスの URL、ビジネスオブジェクトの設定、データ設定などが挙げられます。これらの設定は、「SharePoint にカスタムの構成設定の管理を任せる」で説明したとおりの方法で web.config に格納し、管理することをお勧めします。

9. 拡張と管理のために SharePoint をブランド化する

SharePoint サイトをブランド化することで、ユーザーにアプリケーションの用途を最も明確に、視覚的に伝えることができます。ブランド化には、マスタページ、コンテンツページ、ページレイアウト、サイト定義、CSS など、さまざまなアーティファクトの操作が必要です。カスタムマスタページの作成のヒントについては、オンラインヒントの「カスタムマスタページを作成する」を参照してください。

リソース

Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3 (Microsoft Office SharePoint Server 2007 および Windows SharePoint Services v3)

ビジネスデータカタログ

SharePoint 2007: BDC—The Business Data Catalog (SharePoint 2007: BDC - ビジネスデータカタログ)

WebPart クラス (Microsoft.SharePoint.WebPartPages)

アプリケーションの拡張と管理の戦略にこれらのブランド化アーティファクトの管理方法が盛り込まれていることを確認してください。SharePoint のブランド化の詳細については、「リソース」の「Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3 (Microsoft Office SharePoint Server 2007 および Windows SharePoint Services v3)」を参照してください。

ブランド化に使用するツールを選択する前に、SharePoint の実装のサイズ、ブランド化作業の範囲、アプリケーションをサポートする開発者の知識の程度を考慮してください。ここでは、2 つのツール (SharePoint Designer と Visual Studio) を取り上げます。

SharePoint Designer は、マスタページと CSS の編集に役立つ Web デザインツールであり、FrontPage の技術に基づいてます。ただし、SharePoint Designer の使いやすさにはそれなりのコストも伴います。

統合ソース管理サポートがない。
SharePoint Designer で行った変更により、変更されたコンテンツが非ゴースト化する。

非ゴースト化された状態では、コンテンツのコピーはファイルシステムではなくコンテンツデータベースに格納されます。結果的に、非ゴースト化によって次のような影響があります。

コンテンツを SharePoint または SharePoint Designer 内部でしか更新できないため、展開の管理が難しくなる
ファイルシステムに展開されているサイトに更新されたコンテンツが反映されない
大規模なアクティブな SharePoint の実装でパフォーマンス上の問題が生じるおそれがある

これらの理由から、SharePoint Designer は、小規模から中規模の実装とプロトタイプに最適なツールだと思われます。

Visual Studio は、アプリケーションコンポーネントおよびブランド化アーティファクト用の一貫性のある開発環境ですが、SharePoint Designer が備えているグラフィカル編集機能はありません。そのため、開発者には HTML と CSS の高度な編集技術が求められます。ブランド化アーティファクトを管理するには、適切なプロジェクト構造を設定する必要があります。Visual Studio の統合ソース管理サポートを使用すると、環境固有の構成の管理や、複数の環境に展開されるブランド化アーティファクトのパッケージ化を比較的容易に行うことができます。また、ブランド化アーティファクトは非ゴースト化されません。そのため、大規模なエンタープライズまたは商用の実装の場合は、SharePoint のブランド化ツールとして Visual Studio を使用することをお勧めします。

ブランド化の適用手段としては、サイトテンプレート、カスタムサイト定義、およびフィーチャーの関連付け機能を使用してカスタマイズに関連付けられた OOB サイト定義の 3 つがあります。小規模な実装またはプロトタイプの場合、最も手軽なのは、おそらくカスタムサイトテンプレートを作成する方法です。ただし、テンプレートを基に作成されたサイトは、新しいテンプレートがアップロードされても更新されません。カスタムテンプレートにはテンプレート ID を指定できないので、テンプレートを参照するあらゆるプロビジョニングコードの変更が必要になります。また、サイトテンプレートを基に作成されるのは非ゴースト化コンテンツだけなので、パフォーマンスに影響を及ぼすおそれがあります。

サイト定義は、サイトテンプレートよりも柔軟性と移植性に優れたアプローチです。サイト定義ファイル (onet.xml) と関連のコンテンツをソース管理で管理でき、ゴースト化コンテンツを展開できます。そのため、新しいコンテンツでサイトを更新できます (ただし、サイトがまだカスタマイズされていない場合)。編集する必要のある XML が複雑なため、サイト定義の作成は一筋縄ではいかないかもしれません。ただし、12\Template\SiteTemplates に格納されている OOB サイト定義をベースとして使用するか、VSeWSS を使用してサイト定義をエクスポートすれば、この作業は簡単になります。サイト定義の詳細については、「Site Definitions Demystified - Creating a custom site definition having Custom webparts (サイト定義の解明 - カスタム Web パーツが含まれるカスタムサイト定義を作成する)」を参照してください。

中規模から大規模の実装を扱う場合は、OOB サイト定義をカスタムフィーチャーに関連付けるのが最善の方法です。フィーチャーはサイト定義を拡張するために使用でき、サイトを準備するためのモジュールアプローチを提供します。フィーチャーのわかりやすい概要については、「Office Space」コラム「SharePoint の機能」を参照してください。一部のサードパーティツールだけでなく、VSeWSS 拡張機能にも、ブランド化 Web サイトで使用する一般的なフィーチャーを作成するためのテンプレートが用意されています。

フィーチャーの関連付け機能により、フィーチャーをサイト定義に関連付け、それを新しい Web サイトが作成されたときにアクティブ化できます。この方法は、ブランド化を SharePoint の OOB サイト定義に適用する場合に非常に便利です。

10. 展開可能なソリューションを構築する

コンポーネントは、いくつかの方法で SharePoint Web アプリケーションに組み込むことができます。ここでは、Web ソリューションパッケージ (ソリューション/WSP)、フィーチャー、SharePoint オブジェクトモデルなど、SharePoint に用意されているパッケージ化フレームワークと展開フレームワークの使用方法を取り上げます。

コンポーネントを展開する場所に応じて、コンポーネントのパッケージ化の方法は大きく変わってきます。ソリューションにはサーバーに展開されるファイルが含まれ、フィーチャーにはコンテンツデータベースに展開されるコンテンツが含まれます。

Sharepoint ソリューションに含まれるのは、SharePoint Web アプリケーションに展開されるアセンブリとリソースです。ソリューションはコンパクトで、展開と取り消しが容易です。SharePoint は、ファーム内の複数のサーバー間で SharePoint ソリューションのファイル更新のミラーリングを処理します。Sharepoint ソリューションは、web.config を変更するために使用することもできます。ソリューションと web.config の変更の詳細については、「SharePoint 開発者の重要なタスクと情報ソースを把握する」と「SharePoint にカスタムの構成設定の管理を任せる」を参照してください。図 8 に、ソリューションとそのコンテンツでサポートされている一般的なフォルダの場所をまとめました。"12 ハイブ" は、SharePoint アプリケーションのルート (既定では <%CommonProgramFiles%>\Microsoft Shared\Web server extensions\12) を表します。

図 8 WSP からアクセスできる一般的なファイルの場所

12 ハイブ内のフォルダ	格納されるもの
\ISAPI\HELP\[LCID]	SharePoint のヘルプファイル。このフォルダ (またはローカライズされたサブフォルダ) に独自の .chm ファイルを展開します。
\CONFIG	Web.config のカスタマイズ。
\ISAPI	SharePoint Web サービス (カスタム Web サービスもここに展開)。/_vti_bin にマップします。
\Resources	カスタムフィーチャーとサイト定義からアクセスされるグローバル .resx ファイル。
\TEMPLATE\CONTROLTEMPLATES	.Ascx ユーザーコントロール。/_controltemplates にマップします。
\TEMPLATE\FEATURES	もちろん、フィーチャーです。
\TEMPLATE\LAYOUTS	一般的なサイトページ。/_layouts にマップします。
\TEMPLATE\IMAGES	一般的なサイトイメージファイル。/_layouts/images にマップします。
\TEMPLATE\SiteTemplates	すべての SharePoint サイト定義。カスタムサイト定義 (onet.xml) を展開するには、<subfolder>\xml を作成します。
\TEMPLATE\THEMES	テーマで使用されるすべての UI 要素。既存のテーマフォルダを複製して、独自のフォルダを作成します。
\TEMPLATE\[LCID]\XML	有効なサイト定義を定義する Webtemp.xml ファイル。カスタムサイト定義の xml ファイルをここに追加します。
\TEMPLATE\ADMIN	サーバーの全体管理に使用されるページ。/_admin にマップします。
\ADMISAPI	管理 Web サービス。/_vti_adm にマップします。

ソリューションを処理する場合に注意する必要のある重要な規則を次に示します。

SharePoint ソリューションは構成データベースで管理されるため、ファームには SharePoint ソリューションの一意のインスタンスを 1 つしか配置できません。同じファームを使用して、同じ Web アプリケーションの異なるリリース (たとえば、現在の管理環境と将来の開発環境の両方) をホストする場合は、この点に注意してください。
SharePoint は、ソリューションを名前ではなく ID で追跡します。そのため、ソリューションをアップグレードする予定がある場合は、ソリューション ID をソース管理で管理する必要があります。
12 ハイブは、Web アプリケーション用の共有領域です。複数の Web アプリケーションを同じファームにホストすることを計画している場合は、他のソリューションによりこの領域に展開されている既存の SharePoint ファイルが、新しい SharePoint ソリューションによって上書きされることがないよう注意してください。
ソリューションのファイルを図 8 に記載されているフォルダ以外の場所 (wpresources、global _wpresources、12 ハイブにないその他のフォルダなど、Web アプリケーション下のフォルダを含む) に展開することはできません。
ソリューションのコンテンツを SharePoint Web アプリケーション内に展開することはできません。これは SharePoint フィーチャーの役割です。

フィーチャーとそのレシーバアセンブリを使用すると、Web パーツをギャラリーで使用可能にできるほか、ドキュメントライブラリへのファイルのアップロードと発行や、カスタムアクション (サイトテーマや既定のマスタページの設定など) の実行が可能です。ブランド化を目的とするフィーチャーの使用については、この記事で既に説明した、適切なブランド化手法の使用に関する情報を参照してください。

フィーチャーを作成する場合、いくつかの注意事項があります。

フィーチャーは追加されたコンテンツを追跡しません。そのため、フィーチャーレシーバを使用してフィーチャーが非アクティブ化されたときに、フィーチャーでそれ自体をクリーンアップする必要があります。フィーチャーのライフサイクル全体に目を向け、フィーチャーによって展開されるコンテンツが、削除前に Web アプリケーションの他のパーツで必要になるかどうかを考慮してください。たとえば、フィーチャーの非アクティブ化時にマスタページを削除すると、そのマスタページから継承しているすべてのページが使用できなくなります。
すべての Web アプリケーションでフィーチャーを非アクティブ化してから、そのフィーチャーを展開するために使用したソリューションを削除するようにしてください。そうしないと、ソリューションの展開に失敗します。また、フィーチャーのフォルダが削除されている場合、STSADM を使用してフィーチャーを強制的にアンインストールしなければなりません。

まとめ

この記事は手引きとして使用できます。参考用に紹介されているリファレンスに目を通し、この記事のコードサンプルをダウンロードして、作業の開始に役立てください。おそらく、SharePoint プラットフォーム上でアプリケーションの開発に取り組む過程で、これらのベストプラクティスを見直し、コードサンプルで実際の使用例を探すこともあるでしょう。この記事で紹介したヒントや皆さんが重要だと考えているその他のヒントについて、説明が必要な場合は、ご質問やご意見をお送りください。フィードバックもお待ちしています。できる限り速やかにお返事します。電子メールは、ewilansky@yahoo.com までお送りください。

その他のヒント

SharePoint ソリューションの開発に役立つその他のヒントをいくつか紹介します。

可能な限り相対リンクを使用する

絶対リンクの代わりに相対リンクを使用することを検討してください。ドキュメントライブラリ、データ接続、レポートライブラリなどの場所に相対リンクを使うと、SharePoint インスタンス間での展開が容易になります。レポートライブラリを例に考えてください。すべての SharePoint 環境でレポートライブラリに同じ Web 上の場所を使用した場合、アプリケーションを次の環境に移すときにレポートへのポインタを変更する必要がなくなります。通常、"設定より規約" の概念はコードの構成に適用されますが、展開の他の構成の側面にもある程度適用できます。

これに関連して、私たちは、マイクロソフトが SharePoint プラットフォーム内で相対リンクをサポートすることを期待しています。今のところ、SharePoint プラットフォームの一部の構成設定では絶対リンクを使用しなければなりません。たとえば、InfoPath .udcx データ接続ファイルでは、フォームライブラリに絶対 URL を指定する必要があります。また、ReportViewer Web パーツでは、レポート定義への絶対パスが必要です。

カスタムマスタページを作成する

独自の外観で SharePoint サイトをブランド化する一般的な方法の 1 つに、カスタムマスタページを作成する方法があります。カスタムマスタページでは、サイトのレイアウトを最もきめ細かく制御できます。既存の SharePoint マスタページを利用し、ニーズに合わせて修正することができます。このアプローチが最適なのは、既存のマスタページが目的のレイアウトとそれほど違わない場合です。目的の外観がどの OOB マスタページとも大きく異なる場合は、ゼロから作成する必要があります。ただし、SharePoint のマスタページには最低限必要な機能があるため、最低限の機能を備えたマスタページを基に独自の外観を作り上げることをお勧めします。最低限の機能を備えたマスタページの作成の詳細については、「[方法] 最低限のマスタページを作成する」を参照してください。Heather Solomon 氏のブログからも、最低限の機能を備えたマスタページをいくつかダウンロードできます。このブログへのリンクも「リソース」にあります。

自動化ビルドで InfoPath プロジェクトを処理する

ビルドを自動化する作業をさらに困難にするのが、Microsoft InfoPath Designer で作成されたプロジェクトです。この場合の最善のアプローチは、パッケージ化の処理を InfoPath と SharePoint に任せることです。InfoPath プロジェクトから移植性の高いソリューションパッケージを取得する方法の詳細については、「SharePoint API を使用して Web アプリケーションの展開を自動化する」を参照してください。

Ethan Wilansky は FTI Consulting 社の Technology Practice のディレクターであり、カスタム SharePoint ソリューションの作成に携わっています。また、Microsoft ディレクトリサービスの MVP として、DS プログラミングフレームワークに集中的に取り組んでいます。Ethan は、Office Developer Advisory Council のメンバでもあります。

Paul Olszewski は、.NET 機能チームの情報スペシャリストです。マイクロソフトテクノロジを活用した、再利用可能なコンポーネントアプリケーションの作成と展開を専門としています。

Tomek Stojecki は Annapolis Computing 社に勤務しており、設計パターンとアジャイル方法論を使用した .NET アプリケーションのアーキテクチャと開発を専門としています。彼は、数々の SharePoint ベースプロジェクトでコンサルティング業務をこなしてきました。

Stefan Kowalewski は、SharePoint 開発チームのシニアコンサルタントです。技術支援を行うと共に、アジャイル開発での確かな経験をカスタム SharePoint 開発作業に取り入れています。

次の方法で共有

その他のリソース