Uncategorized

【VSeWSS で作る製品パッケージ(1)】 VSeWSS 進化のポイント

こんにちは。

Visual Studio 2005 Extensions for Windows Share Service 3.0 (VSeWSS) の新バージョン 1.1 について、その日本語版が、昨日提供されました。

[ダウンロード] Windows SharePoint Services 3.0 ツール (※1): Visual Studio 2005 Extensions Version 1.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=3E1DCCCD-1CCA-433A-BB4D-97B96BF7AB63&displaylang=ja

[MSDN フォーラム (速報)] VSeWSS Version 1.1 日本語版リリースのお知らせ
http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=3094999&SiteID=7&mode=1

また、以前下記のフォーラムで速報されましたが、次期 VSeWSS 1.2 では Visual Studio 2008 への対応も近々予定されています。(1.1 の段階は、まだ Visual Studio 2005 対応です)

[MSDN フォーラム (速報)] VSeWSS 1.1 と 1.2 (VS2008対応版)
http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=2834176&SiteID=7

今回は、SharePoint 上の製品開発などにおいて不可欠なこの VSeWSS について、その進化のポイントを記載したいと思います。(今回の進化は、地味そうにみえて結構インパクト大です。その辺りをコードをまじえてご紹介していきます)

まず、いきなり新機能だけご紹介しても、そもそも未だこのツールに馴染んでおられない方も居られるかもしれませんので、従来の機能も含めた構築のポイントから順に (かつ要素のみ) 以下の通りご紹介していきたいと思います。(と、また自分の首を絞めてしまいましたが、今ちょっと別件ではまっている上に、マシンの交換をしなくてはいけないので、投稿スピードは鈍くなるかもしれません、、、あらかじめ御容赦ください)

VSeWSS で作る製品パッケージ

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

まずこの VSeWSS は、ご存じかと思いますが、『開発』 で必須となるカスタムの Web パーツ作成や、カスタムリスト/カスタムフィールド (例:独自のボタンを持つフィールド、などなど) といった、SharePoint の骨組とも言える個々のフィーチャーをコード (C#, VB) を含んだ形で高度に実装でき、それらをフィーチャーとして (セットアッププログラムで) 配置できるツールです。
上記であえて「開発」という用語を強調して使いました。SharePoint のコンセプトとして 「コードを使わずにかなりのレベルまでビジネスが実装できる」 という点は皆さんご認識されていると思いますが、OBA の概念にもあるように、外部アプリケーション連携などを含む共通部品開発、さらには製品開発、など、さらにその上位のレベルの構築も可能とする優れた拡張性も有しており、このレベルでは「コード」を使ったありとあらゆる拡張が可能となっています。VSeWSS は、まさにそうした場面で必要となるツールです。

さて、こうしたコンセプトで使うことを考慮し、VSeWSS には単なる Web パーツ作成や、カスタムリスト作成など以外に、現実の製品開発 (「グループボード」に代表されるような完結したアドイン機能の提供) で必要となる重要な機能を有しています。このあと (次回以降) みていきますが、フィーチャーフレームワークとソリューションフレームワーク (wsp, Webソリューションパッケージ) を使用すると、以下のようなインストールパッケージを作成できます。

  • フィーチャーの登録 (リスト定義/フィールド定義、ワークフロー、マスターページ、レイアウトページ、など)
  • アセンブリのGAC登録と、そのための web.config の書き換え
  • モジュール (ライブラリ内のドキュメント, など) の登録
  • SharePoint ハイブへのファイル登録 (イメージ, etc)
  • サイト定義として機能一連のラッピング
  • サイト定義からのサイトを作成する際のカスタムロジックの作成

さらに、SharePoint の「フィーチャー」は、コードで自作 (単にコードが実行されるようなフィーチャーを作成) することも可能であるため、上記以外のコードで必要な処理もフィーチャーとしてソリューションパッケージに埋め込むことができます。 例えば、CodePlex には、ASP.NET AJAX 用に web.config を書き換えるフィーチャーというものも提供されています。

CodePlex : SharePoint 2007 Features
http://www.codeplex.com/features

さて、VSeWSS と共にインストールされる Solution Generator を使うと、SharePoint Designer 2007 でカスタマイズした UI もサイト定義 (Site Definition) という形で抽出し、サイトテンプレート (SharePoint でサイトを作成したことがある方は必ず目にする、あのテンプレートです) としてそのフィーチャーをインストールするパッケージ (セットアッププログラム) を自動で作成してくれます。そしてこのサイトテンプレートのプロジェクトを元に、独自に、上述したカスタムの Web パーツやカスタムフィールドなどを組み込んでいくことができます。
このレベルの SharePoint アプリケーション開発にとっては、Solution Generator は必須のツールでした。

VSeWSS 1.1 (新バージョン) では、

  • Visual Basic がサポートされた
  • List Instance や List Event Handler など新しいアイテムが使用できるようになった
  • デバッグ時などの配置に際して IIS reset をおこなわなくなり (アプリケーションプールをリサイクルします)、より高速になった

など、1.0 と比べいくつかの機能強化がおこなわれていますが、何といっても強力な強化点が WSP ビューア (WSP View) と呼ばれるソリューションパッケージ (.wsp) をメンテナンスする仕組みが提供されたことです。

VSeWSS 1.0 までは、上述の Solution Generator で生成したプロジェクトは、ビルド時に自動的にパッケージ作成がおこなわれ、このビルド時の動作を外からカスタマイズすることはできませんでした。1 例として、製品レベルのカスタムな機能が凝縮された「サイトテンプレート」をいざ作成しようとした場合、上述の Web パーツなどはカスタムに組み込めても、例えば、「ワークフロー」 を同時に組み込んでしまいたい場合などには、ワークフローはこのサイトテンプレートとは別のフィーチャーパッケージとして作成してインストールをおこなうか (この場合、特定のドキュメントライブラリとワークフローの関連付けはユーザに実施してもらうことになってしまうでしょう)、あるいは VSeWSS を使わずに CAML (構成を定義した XML) を 1 から自身で記述して統合されたパッケージを作成するか、などをしなければならなかったのです。
今回のバージョンからは、上述の WSP View を使って、このパッケージ構築のカスタマイズが可能になっています。

VSeWSS を単なる Web パーツ作成ツールのように思われていた方も多いかもしれませんが、このバージョンからは、完成された製品パッケージを作成する上で必要不可欠な機能がそろった形になります。

ただし、この後のサンプルなどでも見ていきますが、何でもかんでも Visual Studio 上のデザイナーの UI だけで自動に実施できるというわけではないので注意してください。Solution Generator などツールの機能だけに任せるのではなく、自身で構造の理解や、フィーチャーを管理できるようなスキルはある程度必要です。例えば、SharePoint Designer でお好みの状態に UI カスタマイズ (※2) をおこなって Solution Generator でその構築したサイトをサイト定義として抽出した後で WSP View でカスタマイズをおこない、その後で元の UI が変更されたとしましょう。この場合、中身がまったく理解できないと、また Solution Generator で抽出をしなおし、カスタマイズした部分は再度入れなおす必要が生じることでしょう。こうしたメンテナンスに備え、ある程度は自身でも CAML を理解して記述できるようにしておき (例 : 簡単なカスタムマスターページフィーチャーの追加、など)、さまざまな変化に備えてどこをさわれば良いか、といった点を理解しながら使用するようにしましょう (そのようにして利用すれば、「自動化」の恩恵と、カスタム作業を組み合わせて、思い思いの管理ができるようになります)。
製品パッケージ開発などの完結したソリューションを開発するプロフェッショナルデベロッパー向けの機能であるという点は考慮しておいてください。

では、以降の回では、まずは 1.1 の新機能ではありませんが、この Solution Generator を中心に構造の 1 例をみていき、さらに 1.1 の新機能の活用方法を例をまじえてみていきたいと思います。

【参考資料】

Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions User Guide, Version 1.1
http://www.microsoft.com/downloads/details.aspx?FamilyId=A8A4E775-074D-4451-BE39-459921F79787&displaylang=en

 

※1
今回、サンプルは MOSS を使って開発をおこなっていきますが、VSeWSS では、MOSS ではなく WSS を前提としている点は片隅におぼえておいてください。MOSS 上でも概ね問題はありませんが、例えば、サポートされていないサイトテンプレートなどのアイテムが存在する場合があります (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2335127&SiteID=1 など)

※2
SharePoint Designer における製品レベルでの UI のカスタマイズでは、マスターをまったく独自なデザインで 1 から編集することが多いと思いますが、マスターページ (.master ファイル) には数多くのプレースホルダー (ContentPlaceHolder) が存在しているため、編集には少々のコツが必要となります。
以前 Microsoft Conference ‘(2006 年?) でもお話したのですが、デザインを含まない最小限のプレースホルダのみを含んだ .master ファイル (mininal master) を作成し、これとは別ファイルでテーブル (table タグ) 等々を使って自由にデザインして、最後にデザインしたタグの内容 (タグ付きのテキストソース) を最初のマスター (mininal master) にコピーしてから SharePoint Designer 上でプレースホルダーを移動するなどして構築していくと、こうした点を気にせず思い思いに編集することができます。

(参考) MSDN : 最低限のマスタ ページを作成する
http://msdn2.microsoft.com/ja-jp/library/aa660698.aspx

Categories: Uncategorized

Tagged as:

10 replies»

  1. 澤田です。
    いつのまにやら、基幹処理にSharePoint を使用することが決まりました。
    まずは、Windows SharePoint Services 3.0でどこまで実装可能かどうかを調べないといけません。
    6月から稼動しますという結構○某なスケジュールでもあります。

    Like

Leave a Reply