本内容は、SharePoint Server 2007 をベースに記載しています。(2008 年に記載したコラムです。コラム終了のため、こちらに移動しました . . .)最新の SharePoint 2010 を使用した製品開発手法については、「SharePoint Server 開発 サンプル コード集 : 10 行コードで作る .NET アプリケーション」を参照してください。

シリーズ最後として、今回は、製品レベル開発における配布の手法まで説明を進めていきます。

SharePoint 開発の本質

• はじめに
• UI / Web パーツで見る「フィーチャー フレームワーク」
• ワークフロー フィーチャー
• フィーチャーのカスタマイズ
• インストーラとしてのソリューション パッケージ (wsp)

まず、配布に際して重要な要素として「サイト定義」というのものがありますのでおぼえておきましょう。前回、サンプルの「リスト定義」を見ましたが、この「サイト定義」についても概念は同様です。こんどは、サイト作成の際に選択されるテンプレート情報になります (下図)。

ここではサイト定義については詳述しませんが、リスト定義とは比べものにならないほど複雑になることがご想像頂けるでしょう。リストの場合、せいぜい「どのようなフィールド (列) を用意するか」、「どのようなビューを用意するか」、「そのビューのフィルター条件をどうするか」といったいくつかの情報を定義すれば良かったのですが、サイト定義では、サイト作成時の左のナビゲーションバーの項目、最初に表示される default.aspx の表示内容、使用するテーマやマスター、そのサイトで使用可能なドキュメントテンプレートなど、サイトの動きをつかさどるありとあらゆる定義を記述する必要があります。

しかし、逆の言い方をすれば、このサイト定義が作成できれば、「製品用のサイト」として完成された姿を記述する ことが可能です。サイト定義を使うと、利用者のために最初に表示しておくマスターページや Web パーツ、あらかじめ設定しておくワークフローなどを記述できるためです。皆さんご存じの「GroupBoard」という製品や、CodePlex 上で提供されている各種ワークスペースなども多くはこの方法で提供されています。利用者は、サイトの作成時に、このサイト定義をテンプレートとして選択するだけで、製品用にカスタマイズされた UI、カスタムリスト、カスタムワークフローなどが組み込まれたサイトが自動的に組み立てられます。製品開発の全体イメージが掴めました !

しかし、現実の「製品レベル」の開発では、まだクリアすべきハードルがあります。これまでの知識を思い出して、「配布方法」を想像してみてください。

• まず、「サイト定義」に加え、その中で使用する「Web パーツ」、「ワークフロー」など、いくつかのフィーチャーを同時にインストールする必要が生じることでしょう。それぞれは異なる「フィーチャー」ですから、stsadm.exe コマンドを使用して別々にインストールする必要があるでしょう。
• さらに、ここまで見てきたような web.config の書き換え、GAC (グローバルアセンブリキャッシュ) へのアセンブリの配置、イメージファイルなど付随するファイルの配置などの作業を思い出してください。前章で述べた stsadm.exe コマンドによる「フィーチャー」のインストール以外にも、実際には事前のさまざまな作業が必要になるでしょう。これらを製品の利用者には実施させたくないでしょう。

こうした点を解決する 1 つの方法として、開発者がインストール用のバッチコマンドなどを作成 (開発) するという方法があります。このコマンドの中に必要な処理をすべてスクリプトで記述しておくと良いでしょう。
しかし、SharePoint Server 2007 を使うと、こうした配布を考慮した「ソリューション フレームワーク」と呼ばれるさらに賢い仕組みを使うことが可能です。以下に例示をしながら見て行きましょう。

SharePoint のソリューション フレームワークを使うと、以下の簡単な手順で単一のインストールコンポーネントを作成できます。

1. ソリューションマニフェストと呼ばれる XML ファイルにインストール内容を記述します
2. インストールするコンポーネント (フィーチャーを含む) をこのマニフェストと共に cab (キャビネット) ファイルにします (この作成されたキャビネット ファイルは「Web ソリューションパッケージ」と呼ばれるもので、拡張子は .wsp です。)

上記 1 のソリューションマニフェストは、以下の構造の XML ファイルです。

<?xml version="1.0" encoding="utf-8"?><Solution  SolutionId="[ソリューションの GUID]"  xmlns="http://schemas.microsoft.com/sharepoint/">  <SiteDefinitionManifests />  <FeatureManifests />  <TemplateFiles />  <Assemblies /></Solution>

• SiteDefinitionManifests
  前述したサイト定義をインストールする場合は、ここにそのサイト定義のマニフェストファイルを指定します。
• FeatureManifests
  これまで説明してきた「マスターページ」、「Web パーツ」、「ワークフロー」、「リスト定義」などのフィーチャー (feature.xml) をここに指定します。
• TemplateFiles
  SharePoint のテンプレートフォルダにあらかじめインストールしておくイメージファイル、.aspx ファイル、テンプレートドキュメント (.xltx, .dotx, など) などはここに指定します。例えば、以下の通り指定すると、%programfiles%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1041\STYLES に MyStyle.css を配置できます。

<?xml version="1.0" encoding="utf-8"?><Solution  SolutionId="65487A66-78F7-4d88-B463-001CBAD0FE9E"  xmlns="http://schemas.microsoft.com/sharepoint/">  <TemplateFiles><TemplateFile Location="LAYOUTS/1041/STYLES/MyStyle.css" />  </TemplateFiles></Solution>

• Assemblies
  GAC (グローバルアセンブリキャッシュ) などに配置する dll と、付随する web.config の変更を指定できます。

例えば、この連載の「UI / Web パーツで見るフィーチャー フレームワーク」で作成した Web パーツ とその配置方法をもう一度思い出してください。作成した dll を手作業で bin フォルダに配置し、web.config の書き換えをおこないましたが、同じことをこのソリューション パッケージで自動化するには上記の 1 のソリューションマニフェストに以下の通り記述します。

ソリューションマニフェスト (manifest.xml)

<?xml version="1.0" encoding="utf-8"?><Solution  SolutionId="65487A66-78F7-4d88-B463-001CBAD0FE9E"  xmlns="http://schemas.microsoft.com/sharepoint/">  <Assemblies>    <Assembly    Location="SimplestWebPartDemo.dll"    DeploymentTarget="WebApplication">    <SafeControls>      <SafeControl        Assembly="SimplestWebPartDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"        Namespace="SimplestWebPartDemo"        TypeName="DotNetWebpartDemo" Safe="True" />      </SafeControls>    </Assembly>  </Assemblies></Solution>

また、SharePoint 上で実施する Web パーツのフィーチャーの設定も、このマニフェストに記述しましょう。そのために、まずは、この連載の「フィーチャーのカスタマイズ」で説明したように、「feature.xml」、「要素のマニフェスト」、「関連する設定ファイル」の 3 種類のファイルを以下の名前で作成します。(上記の manifest.xml も含め、いずれも必ず「UTF-8」の文字コードで保存をおこなってください。)

feature.xml 

<?xml version="1.0" encoding="utf-8"?><Feature  Id="db878366-08b4-43f4-818d-1c3f4d62d98b"  title=''  Scope="Site"  Version="1.0.0.0"  Hidden="FALSE"  DefaultResourceFile="core"  xmlns="http://schemas.microsoft.com/sharepoint/">  <ElementManifests>    <ElementManifest Location="DotNetWebpartDemoDotNetWebpartDemo.xml" />    <ElementFile Location="DotNetWebpartDemoDotNetWebpartDemo.webpart" />  </ElementManifests></Feature>

要素マニフェスト (DotNetWebpartDemo.xml)

<?xml version="1.0" encoding="utf-8"?><Elements  Id="62564c92-b1bc-44c5-9520-6811b8678a45"  xmlns="http://schemas.microsoft.com/sharepoint/">  <Module    Name="WebParts"    List="113"    Url="_catalogs/wp">    <File      Path="DotNetWebpartDemoDotNetWebpartDemo.webpart"      Url="DotNetWebpartDemo.webpart"      Type="GhostableInLibrary" />  </Module></Elements>

DotNetWebpartDemo.webpart

<?xml version="1.0" encoding="utf-8"?><webParts  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">    <metaData>      <type name="SimplestWebPartDemo.DotNetWebpartDemo, SimplestWebPartDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />      <importErrorMessage>Import failed !</importErrorMessage>    </metaData>    <data>      <properties>        <property name="Title" type="string">テスト用Webパーツ</property>        <property name="Description" type="string">        これは、配置用のテストです        </property>      </properties>    </data>  </webPart></webParts>

この「フィーチャー」をソリューションパッケージの中に含めていきます。先ほど作成したソリューションマニフェスト (manifest.xml) に以下の通り追記します。

ソリューションマニフェスト (manifest.xml)

<?xml version="1.0" encoding="utf-8"?><Solution  SolutionId="65487A66-78F7-4d88-B463-001CBAD0FE9E"  xmlns="http://schemas.microsoft.com/sharepoint/">  <FeatureManifests>    <FeatureManifest Location="DotNetWebpartDemofeature.xml" />  </FeatureManifests>  <Assemblies>  same as above . . . . .  </Assemblies></Solution>

最後に、これらを上記の 2 に従ってキャビネット ファイル (.cab) にして完了です。キャビネット ファイルの作成方法を記述した以下の .ddf ファイルを準備します。

test.ddf

.OPTION EXPLICIT.Set CabinetNameTemplate=TestSolution.wsp.Set UniqueFiles=off.Set Cabinet=on.Set MaxDiskSize=CDROM.Set CompressionType=MSZIP"manifest.xml" "manifest.xml""SimplestWebPartDemo.dll" "SimplestWebPartDemo.dll""feature.xml" "DotNetWebpartDemofeature.xml""DotNetWebpartDemo.xml" "DotNetWebpartDemoDotNetWebpartDemoDotNetWebpartDemo.xml""DotNetWebpartDemo.webpart" "DotNetWebpartDemoDotNetWebpartDemoDotNetWebpartDemo.webpart"

上記で、例えば「feature.xml」は、「DotNetWebpartDemo」というフォルダの中に配置されます。

以上でファイルの準備は完了です。最終的に、以下のファイルが作成されているはずです。

コマンドプロンプトを起動し、以下の通りキャビネットを作成します。上記の test.ddf に記述している通り、作成されるファイル名は .cab ではなく「TestSolution.wsp」になります。

makecab.exe /F C:¥Demo¥testtest.ddf

作成されたソリューションパッケージ (TestSolution.wsp) を使って、以下の通り、SharePoint Server 上でインストールをおこないます。

stsadm.exe -o addsolution -filename C:¥Demotestdisk1TestSolution.wspstsadm.exe -o deploysolution -name TestSolution.wsp -local –url http://localhostiisreset

これで配置は完了です。
SharePoint 上でインストールされているフィーチャーを確認すると、以下の通り表示されるはずです。

サイト定義と共に配布する際は、サイトの作成時に、これら必要なフィーチャーをアクティブ化することで、配置されたフィーチャーを使用したサイトが構成できるでしょう。(サイト作成時にこうした処理を実装するには、サイト定義のプロビジョニングハンドラーと呼ばれるコードを記述します。)

また、SharePoint の IIS フォルダの bin 下を見ると、.dll も配置されていることでしょう。web.config の書き換えもおこなわれているはずです。

前回 も記載しましたが、実は、VSeWSS (Windows SharePoint Services 3.0 ツール: Visual Studio 2008 Extensions) を使用すると、これらをすべて自動的に実施してくれます。このシリーズでは、ツールの使い方でなく、一貫してその背景となる技術のベースを理解できるよう説明をおこなってきました。では、この連載で記述しているノウハウは憶えておいても何の意味もないのでしょうか?

例えば、さきほど、<SafeControl> タグを例に web.config の書き換えについて記載しましたが、その他のタグ (例：ワークフロー用の <authorizedType> タグの追加、ASP.NET AJAX 用のタグの追加、など)の書き換えが必要な場合は、前回の「フィーチャーのカスタマイズ」のさいごで記述した方法で、プログラムコードを使った FeatureReceiver を作成することで実現できます (こうした処理のために、SharePoint には SPWebConfigModification クラスなども用意されています)。
また実際の製品開発では、フィーチャー単位での多チーム/多人数での開発や、統合ビルドなども必要になるかもしれません。こうした場合には、Visual Studio のビルドプロセスに組み込み可能な stsdev.exe を活用してカスタムなビルドプロセスを構築することなども可能となるでしょう。

補足 : stsdev は、CodePlex からダウンロード可能です。stsdev.exe を使用すると、MSBuild のカスタマイズに組み込んで、ddf の自動生成やソリューションパッケージ作成、サーバーへの配布など、ビルド方法をカスタマイズして独自なビルドプロセスを構築することが可能ですので、VSTS (Visual Studio Team System) と組み合わせた統合ビルド (及び配置) プロセスなどのカスタマイズが簡易に実現できます。

また VSeWSS (Windows SharePoint Services 3.0 ツール: Visual Studio 2008 Extensions) も「万能の剣」ではありません。ツールが自動化しない部分は、開発者が理解して該当のコードを修正しなければならないケースもあります。

SharePoint はその背景に美しく設計されたフレームワークを持っていますが、開発ツールが対応していないなど、それが故にかえって扱いづらくなっている側面があることも事実です。今後、SharePoint や開発ツールはますます進化し、最後には、こうした煩わしい XML の記述などはいっさい隠ぺいされてしまうかもしれません。しかし、その裏で実施されている処理では、細かな変更はあれ、基本 (ベース) の考え方は変わらないでしょう。単に「ツールの使い方」ではなく、このシリーズで記載した「背景にある基本概念」を抑えておくことは、SharePoint の開発の世界 (特に高度な開発を必要とする場合) においては、現在ばかりでなく、今後も必要不可欠な知識であることが実感して頂けるでしょう。