Visual Studio 2012

  • [アーティクル]

Visual Studio 2012 における Web 開発向け新機能

Clark Sell

 

最初に開発した Web サイトを覚えていますか。私はもちろん覚えています。最初の Web サイトはなんともごちゃごちゃしたものでした。このころから Web 開発は大きく変化しており、とどまることを知りません。1 年前の Web 開発がどのようなものだったか思い出すことすら難しくなってきており、Microsoft .NET Framework が最初にリリースされたときのことなど言うまでもありません。

Visual Studio も同様に進化しています。サイトを運用するために IIS や SQL Server が必要というだけで、Web 開発者が基本的にフル機能のサーバーを開発用コンピューターにインストールしなければならなかった時代を覚えていますか。その後、Cassini という軽量の環境が導入され、さらに IIS Express へとつながります。そして HTML5 が登場し、Visual Studio に取り入れられます。

今回は、このような新しい環境に携わる Web 開発者に Visual Studio がどのようなサポートを提供するかについて説明します。プロジェクトの共有、Page Inspector、DOM Explorer などの優れた新機能を紹介し、中核となる編集エクスペリエンスがどのように進化を続けているかを示します。

プロジェクトの共有

プロジェクト ファイルを開くとき、最初のマウス クリックで、Visual Studio の新機能に気づくでしょう。以前、プロジェクト ファイルは作成時に使用したエディターに直接依存していました。つまり、Visual Studio 2010 で作成したプロジェクト ファイルを Visual Studio 2012 で開こうとすると、プロジェクト ファイルのアップグレードを求められます。いったんプロジェクト ファイルをアップグレードすると、以前のバージョンではこのプロジェクトを開くことができなくなります。しかし、今は違います。

Visual Studio 2012 リリース候補 (RC) 版では、プロジェクトの共有という考え方が導入されました。同じソースの Visual Studio 2010 SP1 とプロジェクトを相互に交換して使用できるようになります。同じセットアップを使用しなければならないという要件をなくすことで、特に多様なチームやオープン ソース プロジェクトに参加している開発者に、あるいは開発組織でソフトウェアをアップグレードしているときでさえ、新しいエクスペリエンスがもたらされます。

もちろん、いくつか注意点があります。たとえば、プロジェクトでローカル データベース (App_Data フォルダー) を使用する場合は、依然として、同じバージョンのデータベース エンジンを使用する必要があります。また、ASP.NET MVC 2 など、プロジェクトの共有が機能しない古いプロジェクトの種類もいくつかあります。

新しいことに手をつけるときは何でもそうですが、本筋から分岐して、いくつか概念実証することを考えます。最も考えたくないのはビルド プロセスを中断することです。

HTML5 サポート

Visual Studio の HTML エディターに追加された最も重要な機能は、おそらく、Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) のサポートです。WAI-ARIA (w3.org/WAI/intro/aria、英語) は、障碍のある方がアクセスしやすい Web サイトや Web アプリケーションを作成することに重点を置いた Web 標準です。この仕様は、マークアップの 2 種類の属性を定義します。role 属性は、ウィジェットの種類または Web ページの構造を記述するために HTML 要素に適用されます。図 1 に示すように、Visual Studio は IntelliSense を含めて、ARIA の role 属性をサポートします。

ARIA Roles
図 1 ARIA の role 属性

もう 1 つの種類は、aria-busy や aria-valuemin など、プレフィックスとして「aria-」が付く属性です （図 2 参照)。これらの aria-* 属性はユーザーに要素を説明するために使用します。

ARIA-* Properties
図 2 ARIA-* 属性

HTML5 では 25 以上の新しいセマンティック タグが導入されています。Visual Studio は既にこのようなセマンティック タグの IntelliSense サポートを用意していましたが、Visual Studio 2012 では、audio タグや video タグ固有のスニペットを追加することで、マークアップを迅速かつ容易に記述できるようにしています。図 3 に示しているのは、video タグのスニペットです。これらのタグは複雑ではありませんが、コーデックの適切なフォールバックを追加するなど、細かい配慮が加えられています。

A Snippet for the Video Element
図 3 Video 要素のスニペット

最近いくつかの Web サイトを HTML5 の新しいタグを利用するように変更しました。これらの各 Web サイトでは、div タグを section タグに変更するような簡単なセマンティックの変更を行っただけですが、何とかマークアップのリファクタリングを終えることができました。Visual Studio 2012 では、ある要素を変更すると、変更する要素に対応する開始要素または終了要素もエディターが変更します。この要素名の自動変更は、ケアレスミスを避けることに役立つエディター機能の 1 つです。

書式を整えるためにタブを使用するかスペースを使用するかは開発者によって意見が分かれます。いずれにせよ、一貫性を保つためにはスマート インデントが有効です。どちらを選択しても、要素を入力して Enter キーを押すと、次の行にカーソルが移動し、選択に応じてインデントが設定されます。開発者の期待どおり、IntelliSense は入力に応じたフィルター処理だけでなく、検索時に単語のタイトル ケースに基づくフィルター処理も追加しています。これにより、要素の挿入が迅速かつ容易になります。スマート インデントと組み合わせると、どこにカーソルがあっても Tab キーを押すことで、新しいマークアップがドキュメントの適切な位置に自動的に配置されます (図 4 参照)。

Intelligent Filtering and Indenting
図 4 インテリジェント フィルターとインデント

最後に、Visual Studio 2012 の HTML エディターには、スマート タスク、ユーザー コントロールの抽出、自動イベント バインドなど、 ASP.NET をサポートする、多くの優れた追加機能があります。これらの機能の詳細については、「ASP.NET 4.5 と Visual Studio 2012 の新機能」(bit.ly/MXcIbG、英語) を参照してください。

JavaScript のサポート

Visual Studio 2012 の JavaScript エディターはまったくの新機能で、ECMAScript 5 をサポートし、関数の折りたたみやかっこの照合のような優れた機能を提供します。関数を探すのにスクロールする必要がなくなります。F12 キーを押すだけで、関数や変数の定義に直接移動できます (図 5 参照)。

The JavaScript Editor
図 5 JavaScript エディター

エディターでは JavaScript 開発用に IntelliSense が強化され、同時にドキュメント オブジェクト モデル (DOM) のサポートも強化されています。HTML5 が主流になりつつあるため、基本的な新しい DOM API だけでなく、これらを拡張する場合のサポートも強化されている点が優れています (図 6 参照)。

IntelliSense for JavaScript
図 6 JavaScript 用の IntelliSense

ドキュメントを用意することは常にすばらしいことですが、このようなドキュメントを IntelliSense ウィンドウに対応させると最高です。Visual Studio にとって VSDoc のサポートは新しくありませんが、このサポートに、JavaScript 関数のオーバーロードを宣言するための新しい signature 要素を含むようになりました。この要素を使用して、詳細な IntelliSense コメントを作成できます。ちょっとの間コードの品質は無視して、図 7 を見てください。これは引数を 2 つまたは 3 つ受け取る関数を示しています。このコードにはオーバーロードごとに <signatures> のブロックがあり、これにより 図 8 のような結果が生み出されます。

図 7 Signature 要素を使用する JavaScript 関数

function myAwesomeFunction(a, b, c) {
    /// <signature>
    ///   <summary>This is my awesome function</summary>
    ///   <param name="a" type="String">Clearly you should pass A in here.</param>
    ///   <param name="b" type="String">Clearly you should pass B in here.</param>
    ///   <returns type="String" />
    /// </signature>
    /// <signature>
    ///   <summary>This is my awesome function</summary>
    ///   <param name="a" type="String">Clearly you should pass A in here.</param>
    ///   <param name="b" type="String">Clearly you should pass B in here.</param>
    ///   <param name="c" type="String">Clearly you should pass C in here.</param>
    ///   <returns type="String" />
    /// </signature>
    return "yea pretty awesome";
  }


図 8 IntelliSense に追加されたコメント

図 8 に示すようなシンプルなドキュメントがあれば、表示するコンテンツに IntelliSense がこのコメントをどのように使用したかがわかります。

CSS3 のサポート

CSS は相変わらず不思議な芸術のようで、十分利用できたと感じたことはありません。さいわい、Visual Studio 2012 では CSS のサポートも強化されています。Region ブロック、IntelliSense、およびスニペットはスタイルの改善に役立つごくわずかの機能です。まず、Region ブロックから見てみましょう。Region ブロックを作成するのに必要なのは特別なコメントだけです。図 9 は、表のスタイルを設定するシンプルな Region ブロックを、展開した状態と折りたたんだ状態で示しています。


図 9 Region ブロック

ご存じのとおり、Web では複数のブラウザーをサポートしなければなりません。つまり、CSS ではさまざまなベンダーのプレフィックスを考慮することになります。Visual Studio 2012 の CSS エディターは、プロパティの標準リストと組み込みのスニペットの両方にベンダー プレフィックスを含むようになりました (図 10 参照)。

Properties for Vendor Prefix -moz
図 10 ベンダー プレフィックス -moz のプロパティ

自由に使用できる多くの CSS プロパティがあるため、当然、フィルター処理が不可欠です。C# や Visual Basic の IntelliSense と同様、入力するだけで CSS のプロパティの長いリストをフィルター処理できます。図 11 は borr (border-radius) を検索するようすを示しています。

CSS IntelliSense
図 11 CSS の IntelliSense

これは優れた機能です。border-radius がなければ、実際には、ベンダー プレフィックスをすべてサポートする必要があります。border-radius アイコンを注意深く見てください。実はこれがスニペットであることを示しています。Tab キーを 2 回押します。1 回押すとプロパティをオートコンプリートし、もう 1 回押すとこのスニペットが挿入されます (図 12 参照)。

A CSS Snippet
図 12 CSS のスニペット

ベンダー プレフィックスがすべて追加され、さらに変更しやすいように値が強調表示されます。radius に希望する値を入力すると、この値に応じてすべてのベンダー固有の値が変更されます。では、メディア クエリのようなより高度なものはどうでしょう。「@」を入力すると、@media などの高度なスニペットのリストが表示されます。@media を選択してから、Tab キーを押すと、メディア クエリのスニペットが挿入されます。ここで、新しく width を入力して、Tab キーを押すだけで、height が調整されます (図 13 参照)。

The @media Snippet
図 13 @media スニペット

スニペットはキー操作の回数を減らすすばらしい方法です。C# や Visual Basic と同様に、Visual Studio のコード スニペット マネージャーを使って、新しいスニペットを作成したり、既存のスニペットを修正できます。コード スニペット マネージャーは、[ツール] メニューの [コード スニペット マネージャー] からアクセスできます。

Visual Studio には色を必要とするプロパティ向けに新しくカラー ピッカーが用意されます。これは、前バージョンの名前付きの色に代わるものです。図 14 に示すように、少し透明度がある色を選択すると、カラー ピッカーによって標準の 16 進表記から rgba 表記に変換されます。

The New CSS Color Picker
図 14 新しい CSS カラー ピッカー

最後に、階層インデントと CSS のサポートを調査した結果を bit.ly/MXcIbG (英語) で確認してください。

Page Inspector によるデバッグ

「こっちのコンピューターでも動いたよ。」キャリアを積むうちにこのような言葉を何回も発したり、耳にしたりするに違いありません。Web 開発でも、遅かれ早かれこのような言葉を聞くようになることはほぼ間違いあいません。それは、配置先と開発元が同じではないというのが理由の 1 つです。

セキュリティーやサーバー ファームのように明らかなものはひとまず置いておくと、ブラウザーが何を実行し、何をレンダリングするかということに行き着きます。長年にわたり、HTML5、CSS3、JavaScript などのテクノロジは進化しています。そして、以前はブラウザーだけで実行していたもの (knockout.js や backbone.js など) を含め、多数のフレームワークを使用するようになっています。つまり、Web 開発者は 2 つの異なる環境に対処する必要があります。1 つは、アプリを開発する環境、もう 1 つは、必須サポート対象のさまざまなブラウザーすべてでアプリをどのように実行するかという、アプリを実行する環境です。

ブラウザーのツールがそれなりに進化していることは非常に役立ちますが、遺跡の発掘作業のように、オリジナルのソース ファイルを見つける必要が生じる可能性があります。単純な JavaScript の縮小やスクリプト ローダーを考えるだけでも、サーバーに送信するものは、以前開発したものとは大きく異なる可能性があります。さいわい、このような状況には Visual Studio 2012 に追加された Page Inspector が役に立ちます。Page Inspector は、Visual Studio に直接組み込まれるブラウザー診断ツールです。そのため、Page Inspector は、ブラウザーから ASP.NET へ、さらには適切であればソース コードへの統合エクスペリエンスを提供します。最小限のセットアップでこれらすべてが可能になります。

既定では機能が限定された状態の Page Inspector を実行できます。実行するには、検査するページを右クリックし、[View in Page Inspector] (Page Inspector で表示) をクリックします。さて、皆さんは、「自分の MVC プロジェクト機能したり、独自の経路をすべてたどって機能するのは無理ではないか」とお考えではないでしょうか。ある程度、その考えは当たっています。

Page Inspector は、使用している URL の表記法にファイルを実際にマッピングすることに最善を尽くします。マッピングに失敗した箇所では、手動でマッピングを追加できます。Page Inspector とその機能をすべて完全に有効にするには、web.config の appSettings セクションに以下の新しいキーを追加するだけです。

<add key="VisualStudioDesignTime:Enabled" value="true" />

Page Inspector は前に述べたように、開発した内容とレンダリングされる内容の間にある「ギャップ」を埋めるだけです。レンダリングされた出力内容の一部を強調表示し、その部分がどのファイルにあるかを示し、さらにはこれを変更できたらすばらしいと思いませんか。このような変更を行えるブラウザー ツールが既にあることは知っていますが、ここでいうすばらしいこととは、実際のソースを変更するということです。Page Inspector では、レンダリングされた出力とその出力のソース ファイルをマップすることでこれを実現します。Page Inspector を起動すると、基本的には、Visual Studio 内部にブラウザー ウィンドウが表示されます (図 15 参照)。

Page Inspector
図 15 Page Inspector

ここでは多くのことが行われていますが、細かく見てみましょう。

  • ウィンドウのクロムはブラウザー フレームで、上部にアドレス バーがあります。
  • ページの上半分はブラウザーにレンダリングされる実際の Web ページです。
  • 左下はレンダリングされたページの HTML マークアップです。HTML マークアップが表示されているのは、すぐ上にあるタブで [HTML] を選択しているためです。
  • 右下はレンダリングされたページのスタイルです。

ブラウザーに含まれるツールと同様、検査機能があります。[Inspect] (検査) をクリックしてページを見てみると、さまざまな DOM 要素が強調表示され、ラベルが付けられています。図 15 の要素は title という class 属性が付いた hgroup です。HTML ウィンドウで対応するマークアップが強調表示されているのを確認できます。これはドキュメントを移動するにつれてリアルタイムに行われます。これだけでは、まだ十分に優れた機能とは言えません。図 16 を見てください。Page Inspector で要素を 1 つ選択またはポイントすると、背後のウィンドウで、選択またはポイントした 1 つの要素のテキストが、正しいソース ファイルで強調表示されているのがわかります。これは要素レベルだけ行われるのではなく、文字レベルでも行われます。ライブで文字ごとに結び付けられ、ソース ファイルからレンダリングされた出力への双方向のマッピングが行われます。ソースまたはレンダリング出力のどちらを選択しても、その文字が強調表示されるのがわかります。

Mapping Between Source and Rendered Output
図 16 ソースとレンダリングされた出力のマッピング

ここでは、Page Inspector の機能にほんの少し触れただけです。これは、どのようにして作業を簡単にするかを十分評価するために使用する必要がある機能の 1 つです。では、心の準備をして、Web プロジェクトに携わる次の機会にページを右クリックして、[View in Page Inspector] (Page Inspector で表示) をクリックしてください。

発行

Web サイトを配置できなければ何ができるでしょう。Visual Studio には長い間、発行プロファイルという機能など、サイトを配置するためのサポートがありました。従来は、いったんプロファイルが作成されると、これはローカル コンピューターのアセットになるだけでした。Visual Studio 2012 では、このプロファイルがプロジェクト全体のアセットの一部になります。これはシンプルな MSBuild ファイルで、MSBuild チェーン全体にインポートされます。シンプルな FTP プロファイルは、次のようになります。

<Project ToolsVersion="4.0"
  xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FTP</WebPublishMethod>
    <SiteUrlToLaunchAfterPublish>http://thatconference.com
      </SiteUrlToLaunchAfterPublish>
    <publishUrl>ftp://thatConference.com</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
    <FtpPassiveMode>True</FtpPassiveMode>
    <UserName>foooooo</UserName>
    <_SavePWD>True</_SavePWD>
  </PropertyGroup>
</Project>

プロファイルを保存すると、以下のように、プロジェクト全体のプロパティ フォルダーに格納されます。

  • C# の場合: Properties\PublishProfiles
  • Visual Basic の場合: MyProject\PublishProfiles

保存されるのは MSBuild プロジェクト ファイルなので、当然、次のようにコマンド ラインから呼び出すことができます。

msbuild.exe myProject.csproj /t:WebPublish /p:PublishProfile=ProfileName

Windows 8 での HTML5

昨年の BUILD カンファレンスで、マイクロソフトは Windows 8 のネイティブ アプリ構築用の新しいプログラミング モデルを発表しました。しかし、この新しいプログラミング モデルはまったく新しものとは言えないことがわかりました。アプリケーションをビルドする開発作業の一環として、HTML5、CSS3、および JavaScript を新たに使用できるようになっただけです。つまり、Web 開発の経験があればだれでも Windows 8 のネイティブ アプリを作成するために応用できるスキルがあります。もちろん、そこには役に立つ Visual Studio があります。

ここで紹介した主な編集の機能強化の多くは、Page Inspector を除いて (Windows ストア アプリはブラウザーで実行されないため)、Windows Store アプリの開発にも当てはまります。それでは、HTML5 Windows Store アプリケーションのデバッグはどうすればよいでしょう。これには、DOM Explorer と JavaScript コンソールを使用します (図 17 参照)。

The DOM Explorer
図 17 DOM Explorer

Page Inspector と同様、実行中のアプリケーションから要素を選択でき、ソースの該当箇所に直接移動できます。アプリケーションを実行しながら、適用されたスタイルを確認し、値を変更することができます。JavaScript プロジェクトにブレークポイントを設定できます。ブレークポイントによるライブ デバッグが可能です。JavaScript コンソールを起動し、調査を開始することもできます。Windows 8 向けに Web サイトやアプリケーションを構築している場合、どちらを構築していても、1 つの優れたエディターで、両方のプラットフォームの同じ機能を使用してデバッグできます。

この記事をお読みの読者なら、おそらく Visual Studio を使用しているでしょう。私自身、10 年以上 Visual Studio を使用しており、新たなリリースのたびに新しい機能のすべてを試すようにしてきました。ときには安易に、既に知っていることだけにこだわることもあるでしょう。それならば、新しいことに挑戦し、調べてみましょう。標準の変更としてアップグレードするために適切な機能を配備しながら、Visual Studio で採用されている HTML5、CSS3、および ECMAScript 5 のような現在のテクノロジを確認することをお勧めします。

Clark Sell は、シカゴ郊外でマイクロソフトのシニア Web エバンジェリストおよび Windows 8 エバンジェリストとして活躍しています。彼のブログは csell.net (英語) で、ポッドキャストは DeveloperSmackdown.com (英語) で公開されており、Twitter は twitter.com/csell5 (英語) からアクセスできます。

この記事のレビューに協力してくれた技術スタッフの Matt Carter と Orville McDonald に心より感謝いたします。