環境 :
Microsoft Office SharePoint Server (MOSS) 2007
Visual Studio 2005
Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 (VSeWSS) Version 1.0 または 1.1

VSeWSS で作る製品パッケージ

1. VSeWSS 進化のポイント
2. CAML によるサイト/フィーチャーカスタマイズの基本
3. Provisioning Handler の活用
4. 新機能 WSP View の活用（例 : Workflow feature の追加）
5. 新機能 WSP View の活用（例 : Master Page feature の追加）

こんにちは。

ブログがすっかり放置状態ですみません。(シリーズものを宣言していたのを忘れてしまうほど時間があいてしまいました)

今日は、VSeWSS 1.1 の新機能を使いこなしていただく前の準備として、まずは、CAML を使った基本的なカスタマイズについて実例をまじえてみていきたいと思います。(例として、カスタムのドキュメントテンプレートをサイト定義の中に設定してみましょう)

まずは、Solution Generator をご存じでない方も多いかもしれませんので、どのようなことをするものか簡単にみてみましょう。

VSeWSS のインストールと共にインストールされた [SharePoint Solution Generator] (下図) を使用して、SharePoint 上や SharePoint Designer などでカスタマイズしたサイトをウィザードに従って抽出してみてください。

Solution Generator のウィザード開始画面

ウィザードに従って抽出をおこなうと、Visual Studio のプロジェクトが作成されます。
このプロジェクトを Visual Studio で開くと、下記のように様々な定義ファイルやコードが生成されているのがわかります。

まずは、以下の手順でこれをそのまま配置して動きをみてみます。

1. プロジェクトをビルドします。
2. プロジェクトの bin/Debug フォルダへ行き、以下のコマンドを実行します。
   (またはソリューションエクスプローラから [配置] を選択します)

   setup.bat /install

はじめて使う方は、何が起こったか意味不明かもしれませんが、SharePoint 上でサイトの新規作成をおこなってみるとわかります。
サイト作成画面で使用するサイトテンプレートをみると、以下のように新しいテンプレートが表示されているのがわかります。

これを選択してサイトの作成をおこなうと、先ほどデザインされたサイトとそっくり同じサイトがそのまま新しいサイトとして作成されます。

このサイトで、[すべてのサイトコンテンツ] をクリックして見ると、作成したリストなども左のナビゲーションバーに表示されていないだけで、そのままコピーされているのがわかります。
アンインストールをおこなう際は、プロジェクトの bin/Debug フォルダへ行き、以下のコマンドを実行します。

setup.bat /uninstall

(再配置で「特定の言語に依存しないソリューション パッケージが見つかりませんでした。」などのエラーが表示される場合には、プロジェクトを開きなおすか、あるいはいったん pkg フォルダを削除してから再ビルドと再配置をしなおします。)

ここで、何がおこったかを簡単にご説明しましょう。上記のように Solution Generator でプロジェクトとして抽出をおこなうと、Visual Studio 上で 1 からサイト定義を作成しなくとも、default.aspx やテーマなどのデザインの情報や作成したリストなどがプロジェクトにサイト定義の中の情報として抽出され、このサイト定義をもとに .wsp (配布用のパッケージ) としてコンパイルされ、配置可能になります。つまり、サイトを配布するためのソリューションパッケージがほぼ自動で作成できるわけです。
特にリストについては、内部でカスタムリストの「フィーチャー」 (SharePoint上に組み込める機能) として再構築がおこなわれており、このフィーチャーを使ったリストがサイトの中で使用されています (リストの新規作成などをおこなっていただくと、このリストがフィーチャーとして選択可能になっているのがわかります)。サイトを配置すると、サイト定義の中で構築されているこうしたフィーチャーも一緒に配置 (インストール) されるということです。

さて、ここまで書くと至れり尽くせりといった感じ “のみ” を受けるかもしれませんが、前回も記載しましたが、ツールのみに 100 % 依存するのではなく、あくまでも「雛型」を作成してくれているということを忘れないでください。要件におうじて細かな部分は変更をおこなう必要があります。
例えば、ページの中で使用しているイメージファイルの参照先などは元の場所のファイルを参照していると思いますので、このあと述べる方法と同様の手法で別のイメージファイルを参照するように変更する必要があります。また、カスタムマスターページ (.master) などの配置も必要な場合には、第 4 回で述べるカスタムフィーチャーの追加方法を参考に別途外部のフィーチャーとして追加をおこなう必要があるでしょう。このように、「製品レベル」の細かな配置パッケージを作成する場合には、開発者自身がその仕組みを理解しておく必要があります。
今日は、その全部を書くわけにもいきませんので、「どんな感じの作業が必要なのか」、「どんなところにどんな設定があるのか」といった感覚をつかんで頂く意味で、簡単なカスタマイズを例にご説明していきます。

まず、試しにつぎのようなサイトを作成してみてください。

ドキュメントライブラリを作成し、テンプレートとして独自で作成したテンプレートファイル (Word で作成した .dot など) を設定し (ドキュメントライブラリの　[設定] – [ドキュメントライブラリの設定] の [詳細設定] で設定できます)、このリストを含んだサイトを Solution Generator でプロジェクトとして抽出してみましょう。そして、このプロジェクトを上記のようにサイトテンプレートとして配置し、このテンプレートを使用してサイトを新規作成してみてください。
このサイト内に配置されたドキュメントライブラリでは、前述で設定したはずのテンプレートファイルとは別のテンプレートが設定されていると思います。

上記のように設定したドキュメントテンプレートは、リスト定義のような 「フィーチャー」 としてサイトに組み込まれたオブジェクトではなく、各ドキュメントライブラリ (リスト) ごとに個別に設定されたものであるため、この情報の抜き出しまではおこなってくれません。ですので、これをサイトの定義として設定したい場合にはつぎの通り編集をおこなう必要があります。

まず、Visual Studio を使用して上記で生成したプロジェクトみてみましょう。
プロジェクトで作成されている [Site Definition] というフォルダの中の onet.xml というファイルは常に重要です。ここにはページ左のナビゲーションバーに表示する項目や、このサイトで使用可能なドキュメントテンプレート、このサイトで使用するフィーチャーなど、サイトの仕様を決める上での重要な情報が XML のデータとして定義されています。
また、上記のリスト (ドキュメントライブラリ) のフィーチャーのフォルダが表示されていると思いますので、ここを展開して、ListDefinition.xml を確認してみてください。

<?xml version="1.0" encoding="utf-8"?><Elements Id="6f443107-e34c-4315-8854-e39e0b8c9bda" xmlns="http://schemas.microsoft.com/sharepoint/">  <ListTemplate Name="WordTest" DisplayName="WordTest" Description="" BaseType="1" Type="101" OnQuickLaunch="TRUE" SecurityBits="11" Sequence="110" Image="/_layouts/images/itdl.gif" DocumentTemplate="101" /></Elements>

ここにはこのフィーチャー (カスタムのリスト定義) の定義が記述されています。ListTemplate タグの BaseType=1 は、このリストテンプレートが「ドキュメントライブラリ」であることを意味していて、BaseType が 1 の場合のみ「DocumentTemplate」という属性 (上記で 101 の値が指定された属性) を指定すると有効になります。この Type=”101″ の「101」という番号は、上述の onet.xml の中で以下のように指定されたテンプレート番号に対応しています。

<DocumentTemplates>  <DocumentTemplate Path="STS" Name="" DisplayName="なし" Type="100" Default="FALSE" Description="このドキュメント ライブラリはテンプレートを使用しません。" />  <DocumentTemplate Path="STS" DisplayName="Microsoft Office Word 97-2003 文書" Type="101" Default="TRUE" Description="空白の Microsoft Office Word 97-2003 文書"><DocumentTemplateFiles>  <DocumentTemplateFile Name="doctempwordwdtmpl.doc" TargetName="Forms/template.doc" Default="TRUE" /></DocumentTemplateFiles>  </DocumentTemplate>  <DocumentTemplate Path="STS" DisplayName="Microsoft Office Excel 97-2003 ワークシート" Type="103" Description="空白の Microsoft Office Excel 97-2003 ドキュメント"><DocumentTemplateFiles>  <DocumentTemplateFile Name="doctempxlxltmpl.xls" TargetName="Forms/template.xls" Default="TRUE" /></DocumentTemplateFiles>  </DocumentTemplate>　... to be continued 

また上記で、DocumentTemplateFile 要素の Name 属性に指定されているファイルは、SharePoint サーバ上の

%Program Files%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1041\STS

に保存されたファイルを指しています。

つまり、この SharePoint サーバ上の上記のフォルダ (テンプレートが見える場所) にテンプレートファイルを配置し、上述したサイトテンプレートの onet.xml の設定変更と ListDefinition.xml を編集することで、このドキュメントライブラリのドキュメントテンプレートをカスタマイズすることができることがわかります。
以下の手順で実施します。

1. SharePoint サーバ上の上記のフォルダ内に (必要に応じサブフォルダなども作成し)、作成したテンプレートファイル (.dot ファイル) を配置します。
   （実は、ここも、手作業で配置しなくとも、VSeWSS のソリューションパッケージ（wsp）に含めることができますが、この点については 第 4 回 でまとめて述べていきます …）
2. ソリューションプロジェクトの onet.xml を開き、以下のように、DocumentTemplate 要素を追加します。

   <DocumentTemplate Path="STS" DisplayName="松崎のテスト１" Type="10001" Default="TRUE" Description="これはテストで追加したテンプレートファイルである１">  <DocumentTemplateFiles><DocumentTemplateFile Name="doctemptestmatsutest.dotx" TargetName="Forms/template.docx" Default="TRUE" />  </DocumentTemplateFiles></DocumentTemplate>

   なお、Type は SharePoint で登録されている値とかぶらないように、10000 より大きな一意の値を指定します。また TargetName は、サーバ上のテンプレート (dotx) から生成するテンプレートで、ドキュメントライブラリからの相対パスで指定します。

3. 該当のリストテンプレートフィーチャーの ListDefinition.xml を開き、DocumentTemplate 属性に上記の Type の値を指定します。

このプロジェクトを使用して、再度、このサイトテンプレートを配置して、サイト作成を実施してみましょう。

すると、今度は追加したテンプレートが表示されているのがわかります。
この追加したドキュメントテンプレートは、ドキュメントライブラリの作成の際などにもテンプレートとして選べるようになります。(このサンプルでは、このリストテンプレートのフィーチャは特に何の特別な処理もおこなっていませんのであまり意味がありませんが、実際は、このリストテンプレートにレシーバーの処理などのカスタムな開発をいろいろとおこなって独自のリスト定義を構築していくことになるでしょう。)

こうした例の他にも、例えば、サイト定義のプロジェクトに新規の Web パーツを追加した場合などには、default.aspx 上に配置したくなることでしょう。こうした場合には、onet.xml にページ上の Web パーツ設定が Module として挿入されていますので (Module とは、SharePoint のサイトやサイトコレクション上にデフォルトで配置しておきたいアイテムのことです)、onet.xml のこの箇所に以下のように AllUsersWebPart を追加することで、Custom の WebPart が表示されることでしょう。(WebPartOrder は、他の WebPart についても順番を変更しておいてください。他の属性についても、内容に応じて適宜設定します)

. . .<View List=" . . . >   . . .</View><View List=" . . . >   . . .</View><AllUsersWebPart . . .>   . . .</AllUsersWebPart><AllUsersWebPart . . .>  . . .</AllUsersWebPart><AllUsersWebPart WebPartZoneID="Left" WebPartOrder="2">  <![CDATA[<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">  <Assembly>SiteDefinition1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=afbcd95c6cacfe6f</Assembly>  <TypeName>SiteDefinition1.MyCustomDemoWebPart</TypeName>  <FrameType>Standard</FrameType>  <Title>担当者別営業成績</Title>  <Description>This webpart is inserted by custom</Description></WebPart>]]></AllUsersWebPart>. . .

このように、CAML を理解することは、製品開発などにおいて独自のフィーチャーやサイトを配置する上で必要不可欠な要素ですが、この CAML だけでも解決しないさらに特殊なケースもあります。こうした場合には、ついにコード (プログラム) の力を借りる必要が生じてきます。
次回は、Provisioning Handler という仕組みを使用して、さらに細かなカスタマイズをサイトやフィーチャに対しておこなっていく方法を (簡単なサンプルを使って) ご紹介していきたいと思います。