Visual Studio 2008のXMLツール
XMLは、Webサービス、データベース、構成ファイル、オフィス文書など、あらゆる場所で使用されます。 この記事では、Visual Studio 2008が提供するツールサポートを紹介します。これにより、XMLの操作が簡単になります。 この記事では、XMLファイルの編集、XMLスキーマの操作、XSLTスタイルシートのデバッグ、独自のXMLデザイナーの作成によるVisual Studioの拡張について説明します。
Visual Studio 2008でXMLファイル（.xml、.xsd、.xslt、.svg、.configなど）を開くと、組み込みのXMLエディターが起動します。 XMLエディターには、IntelliSense、コードの色付け、括弧の強調表示、折りたたみ/展開、コードの書式設定など、Visual Studioエディターに期待されるすべての機能が備わっています。 完全なXML 1.0構文チェック、タグ補完、およびXMLスキーマサポートのリアルタイム検証を提供します。
XMLファイルの編集
確かに、XMLファイルを手動で編集するのは非常に面倒で時間がかかる場合があります。 これを支援するために、Visual Studio 2008のXMLエディターには、パフォーマンスを向上させる多くの機能が付属しています。 これらの機能の1つは、XMLコードのフラグメントの拡張可能なライブラリです。これは、ドキュメントの編集中に使用するテンプレートとして機能するコードの構成可能なセクションを含むXMLファイルです。 Visual Studioは、開発者がXMLスキーマとXSLTスタイルページを記述するのに役立つ多くのXMLスニペットファイルをインストールします。 XMLファイルの編集中にフラグメントを呼び出すには、[編集]> [IntelliSense]メニューから[スニペットの挿入]を選択します。 フラグメントを挿入したら、強調表示されたフィールド間を移動できます。このフィールドは、Tabキーで変更してデータを入力できます。 図1は、フラグメントを挿入する例を示しています。
図1 ：Visual Studio 2008でXMLコードのスニペットを呼び出す。
独自のスニペットを記録することもできます。 単純なフラグメントを作成する場合は、次の手順を実行します。
XMLファイルを作成して入力します。
<スニペット
ESCAPEを押して、IntelliSenseウィンドウを閉じます。
TABを押します。
値を入力してください。
ENTERを押して完了します。
詳細については、Visual Studio Editorでブログを作成することをお勧めします。
「コードスニペット-スキーマの説明」
既成のXMLコードのフラグメントがなく、既存のスキーマに基づいてXMLファイルを作成する必要がある場合はどうしますか？ XMLエディターは、XML文書をXMLスキーマに関連付けることができる幅広い可能性を提供します。 IntelliSenseスキーマベースのリアルタイム検証、エラーレポートはほんの一部です。 上記に加えて、XMLエディターは既存のスキーマに基づいてコードフラグメントを動的に生成できます。 追加する要素の名前を指定すると、XMLエディターはスキーマで必要な情報を分析し、コードフラグメントを生成して貼り付けることができます。 XMLコードのフラグメントを動的に構築する機能を呼び出すには、次の例に示すように要素名を入力するだけです。
Tabキーを押します。 XMLエディターは、 図1に既に示したものと非常によく似たコードを作成しますが、事前に何もする必要はありません。 これは、特に大規模なコンテンツモデルでドキュメントを作成する必要がある場合に非常に強力な機能です。
デフォルトでは、XMLエディターは必要なコンテンツのみを生成しますが、この動作はXMLスキーマの注釈を使用してオーバーライドできます。 詳細については、MSDNの「方法：XMLスキーマからXMLスニペットを生成する」を参照してください。
スキーマキャッシュとスキーマカタログ
上級ユーザー向けに、XMLエディターはスキーマキャッシュスキーマファイルディレクトリなどの機能を提供します。 スキーマキャッシュは、よく知られた多くのW3Cスキームと、Microsoftによって特別に作成された、またはそれらの技術に関連する多くのスキームを含むフォルダーです。 通常は変更されない一般的に使用されるスキーマのリポジトリとして機能します。 デフォルトのスキーマの場所は、％vsinstalldir％\ xml \ schemasにあります。ここで、「％vsinstalldir％」は、Visual Studioがインストールされている場所を表す変数です。 XMLファイルでこれらのスキーマによって定義された名前空間の1つを宣言すると、エディターはキャッシュの場所から適切なスキーマを自動的に関連付け、そのスキーマのIntelliSenseと検証をすばやく提供します。
スキーマカタログは、スキーマキャッシュディレクトリ（デフォルトではcatalog.xmlファイル）にあるXMLファイルです。 上級ユーザーは、使用できるさまざまなネームスペースをより正確に制御できます。 たとえば、特定の名前空間を外部ソースに関連付けることができます。
また、ディレクトリファイルを使用して、スキーマファイルとファイル拡張子との関連付けを作成することもできますが、スキーマにtargetNamespaceがない場合に役立つことがあります。
Visual Studio 2008の革新により、条件を追加することもできます。
この条件は、現在のプロジェクトが.NET Frameworkバージョン3.0を使用する場合にのみdotNetConfig30.xsdスキーマを関連付ける必要があることを意味します。
最後に、あるディレクトリファイルから別のディレクトリファイルを参照するチェーンを作成できます。
大きなファイルを扱う
もう1つの重要な編集機能は、XMLエディターが大きなファイルをサポートしていることです。 以前のバージョンでは大きなファイルを操作できましたが、Visual Studio 2008はXMLドキュメントの増分解析をサポートしています。 現在、10 MBのファイルを使用している場合、変更を加えるたびにVisual Studioがファイル全体を分析するまで待つ必要はありません。 XMLエディターは編集を分離し、必要な部分のみを再分析するため、パフォーマンスと応答性が向上します。
XMLエディターのいくつかの興味深い機能のみを説明しましたが、明らかに、ここですべてを検討することはできません。 表1は、Visual Studioユーザーが利用できる機能の一部を示しています。
XSLTスタイルシートのデバッグ
XSLTは、W3Cが承認した標準の変換言語であり、多くの開発者グループの間で非常に人気があります。 Visual Studio Professional Editionは、XSLTスタイルシートの編集とデバッグのサポートを提供します。 XSLTファイルの編集は、XMLファイルの編集に似ています。 XSLTのデバッグに関しては、Visual Studioは2つの主なシナリオをサポートしています。
単一の変換をデバッグします。これは、最初の関心が入力ドキュメント、実際の変換、および出力ドキュメントである場合に役立ちます。
CLR統合デバッグ。CLRアプリケーションのコンテキストで変換をデバッグするのに役立ちます。
個々の変換をデバッグする
図2は、XSLT変換を使用しているときのデバッグ環境を示しています。 デフォルト構成では、XSLTファイルと、ドキュメント入力およびドキュメント出力の種類のタブを確認できます。 Visual Studioを構成して、3つのドキュメントすべてを一度に表示することもできます。 変換コードを実行すると、入力データ、この入力を処理して出力ファイルを生成する変換を確認できます。
図2 ：個々のXSLT変換のデバッグ。
C＃またはVisual Basicデバッグ環境を使用している場合、XSLTのデバッグはCLR言語を使用した他のプログラムのデバッグと非常に似ていることに気付くでしょう。 すべての制御方法とキーの組み合わせは同じままです。 図2には、テンプレートで定義されている変数と同様に、非表示のXSLT変数（self、position、およびlast）を表示できる[ローカル]ウィンドウもあります。 コールスタックウィンドウも表示できます。このウィンドウを使用して、スタックの最上部と最下部にあるさまざまなXSLTテンプレートに移動できます。 XSLTデバッガーを使用して、XSLTコードとXMLドキュメントの両方にブレークポイントを設定することもできます。
CLR統合デバッグ
個々の変換のデバッグは便利ですが、C＃またはVisual Basicアプリケーションの一部としてXSLTをデバッグする必要がある場合があります。 XSLTデバッガーは、他のCLRデバッガーと緊密に統合されており、アプリケーションのデバッグ中にC＃からXSLTに、そしてVisual Basicにシームレスに切り替えることができます。 次の例は、XslCompiledTransformクラスを使用してXSLT変換を初期化するC＃コードスニペットを示しています。
メソッド呼び出しにブレークポイントを設定して渡すと、デバッガーはXSLTスタイルシートを表示します（ 図3 ）。 別のスタイルシートのデバッグセクションで説明されているすべての機能もここで適用できます。 1つの例外は、データファイルにブレークポイントを設定する機能です。 別のCLRプログラムからXSLTに切り替える場合、この機能は使用できません。 他のすべては上記のとおりに動作します。
図3 ：C＃アプリケーションからのXSLT変換のデバッグ。
表2は、XSLT変換のデバッグ中に使用可能なさまざまな機能の概要を示しています。
XMLツール拡張
XMLエディターは、開発者がその上にカスタムデザイナーを作成するための優れた基盤を提供します。 図4 Visual Studioの以前のバージョン（Visual Studio 2005）でこれがどのように行われたか。 開発者は、バッファ共有を通じてXMLエディタの上に拡張機能を構築できます。 IVsTextLinesバッファを共有し、System.Xml.XmlReaderまたはXmlDocumentを使用してXMLを解析することにより、カスタムデザイナーを作成することにbeat折しているはずです。 Don Demsakは、Visual Studio用のXPathmaniaおよびXPathアドオンを作成するときにこのメソッドを使用します（XPathmaniaの詳細については、 http： //www.donxml.comを参照してください ）。 ただし、統合はバッファレベルで行われるため、この方法では多くの大きなバッファ編集が作成されます。 これに加えて、System.Xmlパーサーは有効なXMLのみを受け入れるのに対し、デザイナーは定義上、無効なファイルを処理する必要があるため、いくつかの制限があります。
図4 ：XMLエディターの上にカスタムXMLデザイナーを作成する古い方法。
一方、XMLエディターには、エラー回復機能を備えた独自のパーサーがあります。 また、バッファの内容を表す独自の分析ツリーを作成します。 MicrosoftはVisual Studio 2008で、このLINQ to XMLツリーをサードパーティの開発者向けに公開しました。 新しいアーキテクチャを図5に示します。新しいAPIを使用すると、開発者はXMLエディター分析ツリーの上にカスタムビューを作成し、XMLエディターのエラー回復ロジックと更新トランザクションを含むLINQ to XML分析ツリーを提供できます。 これらの変更により、開発者はVisual Studio 2008の上にXMLツールを簡単に作成できます。
図5 ：Visual Studio 2008でXMLエディターを拡張する方法。
Visual Studio 2008でXMLファイル（.xml、.xsd、.xslt、.svg、.configなど）を開くと、組み込みのXMLエディターが起動します。 XMLエディターには、IntelliSense、コードの色付け、括弧の強調表示、折りたたみ/展開、コードの書式設定など、Visual Studioエディターに期待されるすべての機能が備わっています。 完全なXML 1.0構文チェック、タグ補完、およびXMLスキーマサポートのリアルタイム検証を提供します。
XMLファイルの編集
確かに、XMLファイルを手動で編集するのは非常に面倒で時間がかかる場合があります。 これを支援するために、Visual Studio 2008のXMLエディターには、パフォーマンスを向上させる多くの機能が付属しています。 これらの機能の1つは、XMLコードのフラグメントの拡張可能なライブラリです。これは、ドキュメントの編集中に使用するテンプレートとして機能するコードの構成可能なセクションを含むXMLファイルです。 Visual Studioは、開発者がXMLスキーマとXSLTスタイルページを記述するのに役立つ多くのXMLスニペットファイルをインストールします。 XMLファイルの編集中にフラグメントを呼び出すには、[編集]> [IntelliSense]メニューから[スニペットの挿入]を選択します。 フラグメントを挿入したら、強調表示されたフィールド間を移動できます。このフィールドは、Tabキーで変更してデータを入力できます。 図1は、フラグメントを挿入する例を示しています。
図1 ：Visual Studio 2008でXMLコードのスニペットを呼び出す。
独自のスニペットを記録することもできます。 単純なフラグメントを作成する場合は、次の手順を実行します。
XMLファイルを作成して入力します。
<スニペット
ESCAPEを押して、IntelliSenseウィンドウを閉じます。
TABを押します。
値を入力してください。
ENTERを押して完了します。
詳細については、Visual Studio Editorでブログを作成することをお勧めします。
「コードスニペット-スキーマの説明」
既成のXMLコードのフラグメントがなく、既存のスキーマに基づいてXMLファイルを作成する必要がある場合はどうしますか？ XMLエディターは、XML文書をXMLスキーマに関連付けることができる幅広い可能性を提供します。 IntelliSenseスキーマベースのリアルタイム検証、エラーレポートはほんの一部です。 上記に加えて、XMLエディターは既存のスキーマに基づいてコードフラグメントを動的に生成できます。 追加する要素の名前を指定すると、XMLエディターはスキーマで必要な情報を分析し、コードフラグメントを生成して貼り付けることができます。 XMLコードのフラグメントを動的に構築する機能を呼び出すには、次の例に示すように要素名を入力するだけです。
<element_name
Tabキーを押します。 XMLエディターは、 図1に既に示したものと非常によく似たコードを作成しますが、事前に何もする必要はありません。 これは、特に大規模なコンテンツモデルでドキュメントを作成する必要がある場合に非常に強力な機能です。
デフォルトでは、XMLエディターは必要なコンテンツのみを生成しますが、この動作はXMLスキーマの注釈を使用してオーバーライドできます。 詳細については、MSDNの「方法：XMLスキーマからXMLスニペットを生成する」を参照してください。
スキーマキャッシュとスキーマカタログ
上級ユーザー向けに、XMLエディターはスキーマキャッシュスキーマファイルディレクトリなどの機能を提供します。 スキーマキャッシュは、よく知られた多くのW3Cスキームと、Microsoftによって特別に作成された、またはそれらの技術に関連する多くのスキームを含むフォルダーです。 通常は変更されない一般的に使用されるスキーマのリポジトリとして機能します。 デフォルトのスキーマの場所は、％vsinstalldir％\ xml \ schemasにあります。ここで、「％vsinstalldir％」は、Visual Studioがインストールされている場所を表す変数です。 XMLファイルでこれらのスキーマによって定義された名前空間の1つを宣言すると、エディターはキャッシュの場所から適切なスキーマを自動的に関連付け、そのスキーマのIntelliSenseと検証をすばやく提供します。
スキーマカタログは、スキーマキャッシュディレクトリ（デフォルトではcatalog.xmlファイル）にあるXMLファイルです。 上級ユーザーは、使用できるさまざまなネームスペースをより正確に制御できます。 たとえば、特定の名前空間を外部ソースに関連付けることができます。
<Schema
href="mylocation/myschema.xsd"
targetNamespace="http://myschema"/>
また、ディレクトリファイルを使用して、スキーマファイルとファイル拡張子との関連付けを作成することもできますが、スキーマにtargetNamespaceがない場合に役立つことがあります。
<Association
extension="config"
schema="xml/schemas/dotNetConfig.xsd"/>
Visual Studio 2008の革新により、条件を追加することもできます。
<Association
extension="config"
schema="xml/schemas/dotNetConfig30.xsd"
condition="%TargetFrameworkVersion% = 3.0" />
この条件は、現在のプロジェクトが.NET Frameworkバージョン3.0を使用する場合にのみdotNetConfig30.xsdスキーマを関連付ける必要があることを意味します。
最後に、あるディレクトリファイルから別のディレクトリファイルを参照するチェーンを作成できます。
<Catalog href="http://mycompany/catalog.xml"/>
大きなファイルを扱う
もう1つの重要な編集機能は、XMLエディターが大きなファイルをサポートしていることです。 以前のバージョンでは大きなファイルを操作できましたが、Visual Studio 2008はXMLドキュメントの増分解析をサポートしています。 現在、10 MBのファイルを使用している場合、変更を加えるたびにVisual Studioがファイル全体を分析するまで待つ必要はありません。 XMLエディターは編集を分離し、必要な部分のみを再分析するため、パフォーマンスと応答性が向上します。
XMLエディターのいくつかの興味深い機能のみを説明しましたが、明らかに、ここですべてを検討することはできません。 表1は、Visual Studioユーザーが利用できる機能の一部を示しています。
| 機能
| Visual Studio 2008でのサポート
|
| オートコンプリート
| X
|
| 構文の強調表示
| X
|
| コードを折りたたむ/展開する
| X
|
| IntelliSense
| X
|
| 拡張可能なコードスニペットライブラリ
| X
|
| コードの動的スニペット
| X
|
| 定義への移行（XMLからXSDへ）
| X
|
| 後方/前方ナビゲーション
| X
|
| プロジェクトおよびユーザープロファイルのサポート
| X
|
| リアルタイム検証
| X
|
| XSDの完全サポート
| X
|
| 名前空間のサポート
| X
|
| DTDサポート
| X
|
| XML生成XSD
| X
|
| DTDからXSDへの変換
| X
|
| Unicodeサポート
| X
|
| 大きなファイルのサポート（10 MB +）
| X
|
XSLTスタイルシートのデバッグ
XSLTは、W3Cが承認した標準の変換言語であり、多くの開発者グループの間で非常に人気があります。 Visual Studio Professional Editionは、XSLTスタイルシートの編集とデバッグのサポートを提供します。 XSLTファイルの編集は、XMLファイルの編集に似ています。 XSLTのデバッグに関しては、Visual Studioは2つの主なシナリオをサポートしています。
単一の変換をデバッグします。これは、最初の関心が入力ドキュメント、実際の変換、および出力ドキュメントである場合に役立ちます。
CLR統合デバッグ。CLRアプリケーションのコンテキストで変換をデバッグするのに役立ちます。
個々の変換をデバッグする
図2は、XSLT変換を使用しているときのデバッグ環境を示しています。 デフォルト構成では、XSLTファイルと、ドキュメント入力およびドキュメント出力の種類のタブを確認できます。 Visual Studioを構成して、3つのドキュメントすべてを一度に表示することもできます。 変換コードを実行すると、入力データ、この入力を処理して出力ファイルを生成する変換を確認できます。
図2 ：個々のXSLT変換のデバッグ。
C＃またはVisual Basicデバッグ環境を使用している場合、XSLTのデバッグはCLR言語を使用した他のプログラムのデバッグと非常に似ていることに気付くでしょう。 すべての制御方法とキーの組み合わせは同じままです。 図2には、テンプレートで定義されている変数と同様に、非表示のXSLT変数（self、position、およびlast）を表示できる[ローカル]ウィンドウもあります。 コールスタックウィンドウも表示できます。このウィンドウを使用して、スタックの最上部と最下部にあるさまざまなXSLTテンプレートに移動できます。 XSLTデバッガーを使用して、XSLTコードとXMLドキュメントの両方にブレークポイントを設定することもできます。
CLR統合デバッグ
個々の変換のデバッグは便利ですが、C＃またはVisual Basicアプリケーションの一部としてXSLTをデバッグする必要がある場合があります。 XSLTデバッガーは、他のCLRデバッガーと緊密に統合されており、アプリケーションのデバッグ中にC＃からXSLTに、そしてVisual Basicにシームレスに切り替えることができます。 次の例は、XslCompiledTransformクラスを使用してXSLT変換を初期化するC＃コードスニペットを示しています。
XslCompiledTransform xsltcmd =
new XslCompiledTransform( true );
xsltcmd.Load(XSLTFile);
XmlUrlResolver resolver = new XmlUrlResolver();
XmlWriter writer = XmlWriter.Create(OutputFile);
xsltcmd.Transform(XMLFile, writer);
* This source code was highlighted with Source Code Highlighter .
メソッド呼び出しにブレークポイントを設定して渡すと、デバッガーはXSLTスタイルシートを表示します（ 図3 ）。 別のスタイルシートのデバッグセクションで説明されているすべての機能もここで適用できます。 1つの例外は、データファイルにブレークポイントを設定する機能です。 別のCLRプログラムからXSLTに切り替える場合、この機能は使用できません。 他のすべては上記のとおりに動作します。
図3 ：C＃アプリケーションからのXSLT変換のデバッグ。
表2は、XSLT変換のデバッグ中に使用可能なさまざまな機能の概要を示しています。
| 特徴
| Visual Studio 2008のサポート
|
| ブラウザビュー
| X
|
| ローカル、監視、コールスタック
| X
|
| デバッグ中の入力XML、出力、XLSTの表示
| X
|
| XMLのブレークポイント
| X
|
| xsltのブレークポイント
| X
|
| CLR言語デバッガーの統合
| X
|
XMLツール拡張
XMLエディターは、開発者がその上にカスタムデザイナーを作成するための優れた基盤を提供します。 図4 Visual Studioの以前のバージョン（Visual Studio 2005）でこれがどのように行われたか。 開発者は、バッファ共有を通じてXMLエディタの上に拡張機能を構築できます。 IVsTextLinesバッファを共有し、System.Xml.XmlReaderまたはXmlDocumentを使用してXMLを解析することにより、カスタムデザイナーを作成することにbeat折しているはずです。 Don Demsakは、Visual Studio用のXPathmaniaおよびXPathアドオンを作成するときにこのメソッドを使用します（XPathmaniaの詳細については、 http： //www.donxml.comを参照してください ）。 ただし、統合はバッファレベルで行われるため、この方法では多くの大きなバッファ編集が作成されます。 これに加えて、System.Xmlパーサーは有効なXMLのみを受け入れるのに対し、デザイナーは定義上、無効なファイルを処理する必要があるため、いくつかの制限があります。
図4 ：XMLエディターの上にカスタムXMLデザイナーを作成する古い方法。
一方、XMLエディターには、エラー回復機能を備えた独自のパーサーがあります。 また、バッファの内容を表す独自の分析ツリーを作成します。 MicrosoftはVisual Studio 2008で、このLINQ to XMLツリーをサードパーティの開発者向けに公開しました。 新しいアーキテクチャを図5に示します。新しいAPIを使用すると、開発者はXMLエディター分析ツリーの上にカスタムビューを作成し、XMLエディターのエラー回復ロジックと更新トランザクションを含むLINQ to XML分析ツリーを提供できます。 これらの変更により、開発者はVisual Studio 2008の上にXMLツールを簡単に作成できます。
図5 ：Visual Studio 2008でXMLエディターを拡張する方法。
All Articles