ページと Web パーツをアップグレードする

一般的なページのアップグレード

Windows SharePoint Services は、そのページがカスタマイズされている (ゴースト化解除されている) かどうかに応じて、ページのアップグレードに異なる戦略を使用します。

Windows SharePoint Services は、Web サイトが Windows SharePoint Services 2.0 (\web server extensions\60) で作成されたか、Windows SharePoint Services 3.0 (\web server extensions\12) サイト定義で作成されたのかということを追跡しています。Web サイトは、カスタマイズされていないフロントエンド サイト定義を変換する更新定義を持つことによりアップグレードできます。アップグレード プロセスの後は、カスタマイズされていないフロントエンド ファイルへの参照はすべて \web server extensions\60 ディレクトリから \Web server extensions\12 にマッピングされます。 

最初のアップグレードのときに、すべての Web サイトが \60 から \12 にアップグレードされるわけではありません。アップグレード パスを持たない既存のサイト定義は、アップグレード後も機能はしますが、元の \60 ページを指したままです。また、\60 から \12 に更新された Web サイトでも、まだ、カスタマイズされていてデータベースに格納されている Windows SharePoint Services 2.0 ページ (つまり、マスタ ページも Web パーツ マネージャもないページ) を持っている可能性があります。

Windows SharePoint Services は、ページの解析とレンダリングを行うときに、そのページがどの Web サイトに関連付けられているかを調べて、フロントエンド Web サーバー上のカスタマイズされていない (ゴースト化されている) ファイルが Windows SharePoint Services 2.0 なのか Windows SharePoint Services 3.0 なのかを判断します。Windows SharePoint Services 2.0 ページは、Windows SharePoint Services 3.0 の標準と、直接の互換性はありません。これらのページは、まだサイトがアップグレードされていない場合は互換モードで実行されますが、アップグレード定義が適用されてサイトがアップグレードされた後は、Windows SharePoint Services は、ページが Microsoft ASP.NET 2.0 と完全に互換であると見なすようになります。つまり、たとえば、Web パーツ ゾーンを含むページは Web パーツ マネージャを持つと見なされ、各ページが有効なコントロール ID を持ち、マスタ ページと関連付けられているものと見なされます。

ページの互換性

Windows SharePoint Services 2.0 では、データベース内のカスタマイズされたページは、Windows SharePoint Services パーサーを使用して解析されます。このパーサーは、ASP.NET パーサーとは許容範囲が異なります。ページに無効な形式のマークアップ言語が含まれている場合、そのページは Windows SharePoint Services Windows SharePoint Services 2.0 ではうまく機能する場合がありますが、パーサーの違いが原因で、ASP.NET や新しいバージョンの Windows SharePoint Services ではうまく機能しません。

新しい Windows SharePoint Services パーサーでは、ページのマークアップ内の既知のブレーキング問題の一部が対処されています。対処されている問題には、以下のものがあります。

• ASP.NET と互換性のない無効なコントロール ID。ID が数字またはサポートされていない文字で始まるため名前が無効な場合や、ID が空の文字列の場合、ID がページ上の他の ID との兼ね合いで一意ではない場合などが該当します。この変更で、クライアント側のスクリプトが以前の ID 名に依存している場合にページが壊れる可能性があります。

• Windows SharePoint Services によりページに挿入された既知の属性 (たとえば、__Preview、__Error、__Web PartId、WebPart) は、Web パーツに SharePoint IAttributeAccessor インターフェイスを実装することにより処理されます。

• Trace 属性の削除。

• <WebPart:WebPartZone>、<SharePoint:Theme> などのタグを登録するための適切なディレクティブの追加。

Windows SharePoint Services は、ページ上の以下のブレーキング問題は修正しようとしません。

• コントロールの不明属性。

• <object runat=server> タグの存在。

• 属性内にあるデータ バインド式 (<% ... %>)。

Windows SharePoint Services は、カスタマイズされた各ページのバージョンの整数値をデータベースに格納します。カスタマイズされているページが参照されると、SharePoint はページのバージョン番号をチェックします。バージョン番号がアップグレードされていない Windows SharePoint Services 2.0 に対応する場合は、SharePoint は、自動的に上記のさまざまなブレーキング問題を修正し、ページを更新します。

Version 3 での Version 2 のレイアウト ページ

Windows SharePoint Services 2.0 のレイアウト ページは、通常、\Web Server Extensions\60\TEMPLATE\LAYOUTS\Locale_ID セットアップ ディレクトリにインストールされている、最初から用意されていたレイアウト ファイルを直接参照します。Windows SharePoint Services 3.0 のレイアウト ファイルは言語に依存しないフォルダに格納されるようになっているため、Windows SharePoint Services は、ユーザーを /_layouts/Locale_ID/nameofoldpage.aspx から /_layouts/newpage.aspx に移動させるリダイレクトを自動的にセットアップします。

レイアウト ページは、通常、SPWeb.MasterUrl プロパティで設定されたマスタ ページを使用するように調整されています。Windows SharePoint Services 2.0 のサイト定義の場合は、このプロパティは Windows SharePoint Services 2.0 の外観を保つマスタ ページを参照するようになっている必要があります。

Web パーツをアップグレードする

Windows SharePoint Services 2.0 の Web パーツは Windows SharePoint Services 3.0 でも機能し続けますが、構成に若干変更を加える必要があります。Windows SharePoint Services 3.0 インストールをホストするために新しい Web アプリケーションを作成する場合は、そのインストール用の web.config ファイルを更新して、安全なコントロールとコード アクセス セキュリティ (CAS) の追加のポリシー設定を含める必要があります。

CAS の制限事項の基本レベルは Windows SharePoint Services 3.0 と同じですが、Windows SharePoint Services のポリシー ファイルは、それらが ASP.NET 2.0 用の最新になるように修正されています。このため、基本的に Windows SharePoint Services 2.0 の CAS ポリシー ファイルを Windows SharePoint Services 3.0 で再利用することはできません。  最もよい方法は、Windows SharePoint Services 3.0 の wss_minimaltrust.config ファイルをコピーし、必要に応じて権限を追加していくことです。