次の方法で共有

SharePoint Foundation 2010 および SharePoint Server 2010 でのカスタマイズとソリューションの再展開

  • [アーティクル]

概要 : Windows SharePoint Services 3.0 および Microsoft Office SharePoint Server 2007 用に作成したカスタマイズとカスタム ソリューションを Microsoft SharePoint Server 2010 および Microsoft SharePoint Foundation 2010 に再展開する方法について学習します。

最終更新日: 2011年1月12日

適用対象: Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

この記事の内容
2010 オブジェクト モデルを使用する前に
アップグレードのインストール
2010 オブジェクト モデルの操作
ユーザー インターフェイスの変更
まとめ
参考資料

James Crowley (Microsoft Corporation)

Michael Washam (Microsoft Corporation)

2009 年 10 月

適用先 : Microsoft SharePoint Server 2010、Microsoft SharePoint Foundation 2010

目次

  • 2010 オブジェクト モデルを使用する前に

  • アップグレードのインストール

  • 2010 オブジェクト モデルの操作

  • ユーザー インターフェイスの変更

  • まとめ

  • 参考資料

使用すべきでない型およびメソッドの一覧のダウンロード (この資料の付属資料として):Microsoft SharePoint Server 2010: Deprecated Types and Methods (英語)

2010 オブジェクト モデルを使用する前に

Microsoft SharePoint Foundation 2010 および Microsoft SharePoint Server 2010 には、オブジェクト モデルのアップグレードが含まれています。これらのアップグレードは、Windows SharePoint Services 3.0 および Microsoft Office SharePoint Server 2007 用に開発された既存のソリューションと互換性を持つように設計されています。名前空間、クラス、およびメソッドによっては現在では使用すべきでないものもありますが、使用できないわけではないので、これからもカスタム コードで期待どおりに機能します。また、ユーザー インターフェイス (UI) も大幅に変更されていますが、下位互換性を考慮した視覚モードを使用すると、機能強化された UI を取り入れるまでは、視覚的なカスタマイズを保持できるようになっています。従来のカスタマイズとアプリケーションは再展開後に、アップグレード バージョンの Microsoft SharePoint Foundation 2010 および Microsoft SharePoint Server 2010 と同期できます。この資料では、Windows SharePoint Services 3.0 および Office SharePoint Server 2007 コードを SharePoint Foundation 2010 と Microsoft SharePoint Server 2010 にそれぞれ再展開、テスト、およびデバッグする過程で発生する可能性がある問題の回避および解決に役立つガイダンスについて説明します。

Windows SharePoint Services 3.0 または Office SharePoint Server 2007 プロジェクトが Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 バージョン 1.1、Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 バージョン 1.2、および Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 バージョン 1.3 で作成されている場合、これらのアップグレードには VSeWSS アップグレード ツール (英語)を使用できます。このツールを使用すると、Windows SharePoint Services ソリューション パッケージ用の既存の Visual Studio 拡張機能 (Microsoft Visual Basic または Microsoft Visual C# で記述) を Microsoft Visual Studio 2010 ソリューションに変換するテンプレートがインストールされます (図 1)。

図 1. Windows SharePoint Services プロジェクト用の Visual Studio 機能拡張の Visual Studio 2010 へのインポート

VSeWSS の Visual Studio 2010 へのインポート

Windows SharePoint Services ソリューション用の Visual Studio 拡張機能を Visual Studio 2010 ソリューションに変換したら、新しいソリューション パッケージをアップグレードされたフレームワークに展開する必要があります。

アップグレードのインストール

アップグレードは、(Windows SharePoint Services 3.0 または Office SharePoint Server 2007 がインストール済みのサーバー ファームで) インプレースで実行することも、ユーザーや管理者が既存のコンテンツ データベースを接続する新しいサーバー ファームで実行することもできます。どちらの場合も、通常は Windows インストーラー (.msi) パッケージではなく、SharePoint ソリューション パッケージ (.wsp) ファイルを使用することで、最適に再展開できます。サイト テンプレートを再展開する必要がある場合は、そのテンプレートを基にサイトを作成し、そのサイトをソリューション パッケージとして保存する必要があります。最初に考慮すべき最も重要な点は、すべての展開のターゲットとなるのは "14" フォルダーであり、"12" フォルダーではないということです。ソリューション パッケージではこれが容易です。SharePoint Foundation 2010 および SharePoint Server 2010 のどちらでも、対応する "14" フォルダー内にファイルが見つからなければ、12\TEMPLATE\FEATURES フォルダーが確認されます。ただし、カスタム ファイルが他のフォルダーに展開されていると検出されない可能性があります。カスタム ファイルがすべて "14" フォルダーに展開されていると、インストールのデバッグは大幅に容易になります。

ソリューション パッケージ (.wsp ファイル) の使用

カスタム ソリューションの展開には、できるだけソリューション パッケージ (.wsp ファイル) を使用してください。ソリューション パッケージを使用すると、すべてのカスタム ファイルを適切な場所に正しく展開できます。Windows SharePoint Services 3.0 および Office SharePoint Server 2007 でのソリューション ファイルの作成については、「ソリューションの作成」を参照してください。SharePoint Foundation 2010 および SharePoint Server 2010 へのソリューション ファイルの展開については、「SharePoint 2010 へのファーム ソリューションのインストールと展開」を参照してください。

Windows インストーラー ファイルの使用

カスタム ソリューションの展開に Windows インストーラー (.msi) パッケージを使用する場合は、カスタム ファイルが "14" フォルダー内の適切な場所に展開されるように Windows インストーラー (.msi) パッケージを変更してください。特に、ファイルを TEMPLATE\FEATURES フォルダー以外の場所に展開する場合は、これが重要です。

サイト テンプレートの再展開

サイト テンプレートの使用は避けてください。サイト テンプレートを SharePoint Foundation 2010 または SharePoint Server 2010 に再展開する必要がある場合は、次の手順に従います。

  1. サイト テンプレートを基にしてサイトを作成します。

  2. SharePoint Foundation 2010 または SharePoint Server 2010 を既存のサーバー ファームまたは新しいサーバー ファームにインストールします。アップグレードを新しいサーバー ファームにインストールする場合は、作成したサイトを含むコンテンツ データベースを新しいファームに接続します。

  3. 新しいインストールで、[サイトの設定] ページから [テンプレートとしてサイトを保存] を選択します。これにより、拡張子 .wsp のソリューション パッケージが作成されます。

2010 オブジェクト モデルの操作

オブジェクト モデルには変更点や機能強化が多数含まれていますが、現在でもカスタム コードをコンパイルすれば、期待どおりに機能します。ただし、1 つだけ潜在的な例外事項があります。それは、カスタマイズでリスト クエリを利用しているが、生成される結果セットの項目数が 5,000 を超える可能性がある場合や、項目数が 5,000 を超えるリストのすべての行をスキャンする場合は、クエリ サイズのしきい値を変更する必要があるということです (変更手順については、「 項目数が多いリストに対して実行するクエリのしきい値の調整」を参照してください)。これらが該当しない場合は、変更点を慎重に調べたうえで、独自のスケジュールでオブジェクト モデルの新しい要素を組み込むことができます。アップグレードされたオブジェクト モデルは、カスタマイズの設計とパフォーマンスを多くの点で強化できる代替的なアプローチです。

下位互換性

アップグレードでは API も変更されていますが、下位互換性があるため、SharePoint Foundation 2010 または SharePoint Server 2010 にカスタム コードを再展開する前に変更を加える必要はありません。一部のクラスと名前空間については使用すべきでないものもありますが、期待どおりに機能します。アプリケーションをアップグレードして最新のクラスとメソッドを使用する場合は、コードを再コンパイルします。使用すべきでないオブジェクト モデルの要素と、その代わりとして新しく使用する必要がある要素を示す警告がコンパイラーに表示されます。図 2 に、Visual Studio 2010 に表示されるコンパイラーの警告の例と、それに対応するマウスオーバー警告を示します。

図 2. 使用すべきでないコンストラクターを示すコンパイラーの警告 (Visual Studio 2010)

Visual Studio 2010 のコンパイラ警告

Microsoft SharePoint 2010 オブジェクト モデルで使用すべきでない型およびメソッドの一覧については、「Microsoft SharePoint Server 2010: Deprecated Types and Methods (英語)」を参照してください。

SharePoint Server 2010 では、1,500 個を超えるほどの型が使用されなくなりました。その中で最も多いのが Microsoft.SharePoint.Portal 名前空間です。それと比べると、SharePoint Foundation 2010 で使用されなくなった型の数はごく少数ですが、それでも数百ものメソッドとプロパティが該当します。

Windows SharePoint Services 3.0 および Office SharePoint Server 2007 用のカスタム コードのうち、インターネット インフォメーション サービス (IIS) 上で実行するものについては、再コンパイルする必要はありません。つまり、カスタム DLL は、再コンパイルしなくても再使用できます。ただし、場合によっては期待どおりに機能しないこともあります。たとえば、ファイルをすべて "14" フォルダーに再展開して "12" フォルダーを空にすると、"12" フォルダー下にあるファイルへの参照は機能しなくなります。これはちょうど、Windows インストーラー パッケージが "12" フォルダー内の場所を参照している場合は、Windows インストーラー パッケージを書き換える必要があるのと同じことです。つまり、新しい場所に移動したファイルとリソースを参照するコードを書き換えて再コンパイルする必要があります。新しいインストールの観点からカスタマイズを評価し、古いインストールの細部に依存しているコードがあれば、それらのコードがアップグレードのインストール後も正しく機能することを確認する必要があります。

Office SharePoint Server 2007 用に記述されたカスタム コードの再コンパイルが必要となる場合もあります。それは、FeatureInstalled、FeatureUninstalling、FeatureActivated、または FeatureDeactivating メソッドを実装する機能レシーバーがソリューションに含まれていて、その機能レシーバーを Stsadm コマンドライン ツールまたは Timer Service で展開する場合です。SharePoint Server 2010 でのアセンブリのリダイレクトは、サーバーの web.config ファイル内のエントリによって処理され、コマンドライン ツールはソリューションがインストールされてからでないと、新しいアセンブリ バージョンにリダイレクトしない可能性があります。

Windows SharePoint Services 3.0 および Office SharePoint Server 2007 用に記述されたカスタム コードのうち、IIS 上で実行されないもの (コンソール アプリケーションやサービス) については、再コンパイルする必要があります。

項目数が多いリストに対して実行するクエリのしきい値の調整

SharePoint Foundation 2010 および SharePoint Server 2010 では、クエリのしきい値には既定で 5,000 項目が適用されます。クエリの結果セットに依存するカスタム コードのうち、この上限を超える可能性があるものは、アップグレード後は期待どおりに機能しません。また、項目数が 5,000 を超えるリストに対して実行するクエリのうち、クエリ条件に非インデックス フィールドが含まれているものは、リスト内の行をすべてスキャンするため失敗します。このような場合は、上限をさらに高く設定するか (SPList オブジェクトの EnableThrottling プロパティを設定)、オブジェクト モデルで上限を上書きできるようにします。大きなフォルダーとリストを効率的に処理する方法のガイダンスについては、「規模の大きなフォルダーやリストの操作」および「SharePoint Server での効率的なコードの作成」を参照してください。

クエリの既定のしきい値を増やす

  1. サーバーの全体管理サイトで、[アプリケーション構成の管理] の [Web アプリケーションの管理] をクリックします。

  2. [全般設定] をクリックし、[リソースの調整] をクリックします (図 3)。

図 3. SharePoint Foundation 2010 および SharePoint Server 2010 でのクエリ サイズのしきい値の設定

クエリ サイズのしきい値設定

SharePoint の新機能

SharePoint Foundation 2010 および SharePoint Server 2010 オブジェクト モデルには、次のような注目すべき新機能も追加されています。

  • Microsoft.SharePoint.Linq 名前空間。これは LINQ クエリを Collaborative Application Markup Language (CAML) クエリに変換する LINQ to SharePoint プロバイダーを定義します (この変換の結果、リストと CAML クエリを LINQ で置き換えるオプションが得られます)。

  • Microsoft.SharePoint.Client 名前空間の 3 つのクライアント側の API。これらを使用すると、Microsoft .NET Framework マネージ コードからブラウザー内または Microsoft Silverlight 内でスクリプトを実行して、SharePoint サイトを対話的に操作できます。

  • SharePoint Foundation 2010 および SharePoint Server 2010 には、Business Connectivity Services から提供される多くの追加事項が含まれています。これらの変更により、外部の業務データや業務プロセスをサーバー アプリケーションとクライアント アプリケーションの両方に容易に統合できるようになります。

これらの API や他の新しい API の使用方法については、「SharePoint Foundation 2010 の新機能」および「SharePoint Server 2010 の新機能」を参照してください。

図 4 のグラフは、多くの型が追加された名前空間の例を示しています。

図 4. SharePoint Server 2010 の名前空間別の新しい型

名前空間による新しいタイプ

ユーザー インターフェイスの変更

SharePoint Foundation 2010 および SharePoint Server 2010 では UI が大幅に変更されているため、特定の CSS クラスと UI 要素に依存するカスタマイズは、下位互換性モードのユーザーに対して最適に機能します。SharePoint Foundation 2010 または SharePoint Server 2010 にアップグレードすると、下位互換性モードまたはアップグレードされたユーザー インターフェイスのどちらかを選択できます。下位互換性モードと新しいインターフェイスは、サイトコレクション レベルまたはサイト レベルで切り替えることができます。

  • 既存のサイトの外観を保持するには、PSConfig および PSConfigUI のどちらかを使用します。

  • 古いコンテンツ データベースを新しいサーバー ファームに接続してアップグレードする場合に、既存のサイトの外観を保持するには、Stsadm を使用します。

また、Web インターフェイスを使用して、サイト コレクション内のすべてのサイトをアップグレードされた UI に設定することもできます (ユーザーは古いインターフェイスを使用できません)。

サイト コレクション内のすべてのサイトをアップグレードされた UI に設定する

  1. [サイトの設定] で [サイト コレクションの管理] をクリックします。

  2. [ビジュアル アップグレード] をクリックします (図 5)。

図 5. サイトコレクション レベルでの UI の変更

サイト コレクション レベルでの UI の変更

また、特定のサイトに対して以前の外観を選択することもできます。[サイトの設定] で [タイトル] をクリックし、[説明] をクリックして、[外観] をクリックします (図 6)。

図 6. サイト レベルでのユーザー インターフェイスの変更

サイト レベルでの UI の変更

また、UI バージョンは、SPWeb.UIVersion プロパティを使用してプログラムで取得または設定することもできます (下位互換性モードは 3、新しいインターフェイスは 4)。

注意

SPWeb.UIVersion を 3 または 4 に設定した後は、SPWeb.Update メソッドを使用して変更を保存する必要があります。

また、UIVersion プロパティは、SharePoint:VersionedContent コントロールと SharePoint:VersionedPlaceHolder コントロールでも使用できます。これらのコントロールは、バージョン管理されたコンテンツをページ上に配置しますが、SharePoint:VersionedPlaceHolder が機能するのは表示時、つまり、ページの読み込みが終了した後です。

次の例は、これらのコントロールを .aspx ファイルに実装する方法を示しています。

<SharePoint:VersionedPlaceHolder ID="vph4" runat="server" UIVersion="4">
   <div>Content</div>
</SharePoint:VersionedPlaceHolder>

<SharePoint:UIVersionedContent ID="vc4" runat="server" UIVersion="4">
<ContentTemplate>
<div>Content</div>
</ContentTemplate>
<SharePoint:UIVersionedContent>

Web インターフェイスの [ビジュアル アップグレード] 設定はプログラムで有効または無効にできます。その場合は、SPWeb.UIVersionConfigurationEnabled、SPSite.UIVersionConfigurationEnabledInAllWebs、および SPSite.UIVersionConfigurationEnabled プロパティ (ブール型) を設定します。SPSite.UIVersionConfigurationEnabled を false に設定すると、[サイトの操作] の [新しいユーザー エクスペリエンスのコミット] オプションを選択した場合と同じ結果になります。どちらの方法で設定した場合も、Web インターフェイスを使用して一方の UI バージョンから他方の UI バージョンに切り替えることはできなくなります (ただし、前に説明したプロパティを設定すれば、プログラムで切り替えることができます)。

下位互換性モードでは、視覚的なカスタマイズは引き続き有効で、テーマに関連するすべてのインフラストラクチャ (CSS を含む) にアクセスできます。下位互換性モードでは、カスタマイズを移行およびアップグレードして、新しいインターフェイスを使用するようになるまで時間を取ることができます。視覚的な要素によっては新しいインターフェイスでも期待どおりに機能するものもありますが、ユーザー設定アクション (ControlAssembly、ControlClass、および ControlSrc 属性を使用するアクション) によっては機能しないものもあります。多数の視覚的なカスタマイズ (特に CSS やツール バーのカスタマイズ) を加えている場合は、下位互換性モードから始める必要があります。カスタマイズを展開したら、アップグレードされたインターフェイスでカスタマイズをテストして、変更が必要な要素を特定する必要があります。

CSS クラスの変更

新しい CSS には大幅な変更が加えられているため、Windows SharePoint Services 3.0 および Office SharePoint Server 2007 の CSS クラスに依存するカスタマイズや設計は下位互換性モードでのみ機能します。SharePoint Foundation 2010 および SharePoint Server 2010 ではテーマを使用しないようになったため、カスタマイズや、テーマに関連するデザイン ワークは、新しいインターフェイスにインポートされません。アップグレードおよび再展開後にページを再設計するときは、再設計された UI を古い CSS で操作するのではなく、新しいマスター ページをカスタマイズする必要があります。

ユーザー設定アクションとツール バーの追加

リンクやエディット コントロール ブロック (ECB) メニューのターゲットになるユーザー設定アクションも含め、ほとんどのユーザー設定アクションは、アップグレードされたインターフェイスでも期待どおりに機能します。ツール バーはリボンに置き換えられているため、ツール バーにボタンを追加するほとんどのユーザー設定アクションは、リボンの [カスタム コマンド] タブに配置されます (図 7)。

図 7. ツール バーとリボンの [カスタム コマンド] タブのユーザー設定アクション

ツールバーとリボンでのユーザー設定アクション

ただし、ControlAssembly 属性、ControlClass 属性、または ControlSrc 属性を使用する Custom Action Element は、新しいインターフェイスに表示されません。ツール バーに追加した要素が機能するようにしてからアプリケーションを再設計するには、下位互換性モードを使用します。また、このようなユーザー設定アクションを含むカスタマイズされたツール バーを使用するリスト ビューとリスト フォームについては、個々に [完全なツール バーの表示] オプションを選択することができます。[完全なツール バーの表示] オプションを使用すると、リボンのほかにツール バーも表示されるため、冗長な機能にも思えますが、カスタマイズされたツール バーを表示するコンテキスト数が限られている場合は役立つこともあります。

まとめ

SharePoint Foundation 2010 および SharePoint Server 2010 の強化された機能は、これらをインストールした後すぐに利用できます。ただし、コードをすぐに書き換える必要はありません。使用されなくなった API の要素もありますが、使用できなくなったわけではありません。したがって、時間を取って API の新しい要素を確認したうえで、カスタマイズに組み込むことができます。さらに、下位互換性モードを使用すると、時間をかけて再検討し、新しい UI をすべて活用できるように必要に応じてカスタマイズを再設計できます。また、一度にすべてのサイトに新しい UI を取り入れる必要はありません。一部のサイトでは最後のバージョンのインターフェイスを使用し、その一方で、別のサイトでは即座に新しいバージョンを取り入れることができます。このフレームワークでは、カスタマイズを移行し、新機能を順序立てて段階的に利用することができるため、各自に最適なペースで拡張機能を取り入れることができます。

参考資料