次の方法で共有


ASP.NET 2.0 の新しいコード コンパイル機能

G. Andrew Duthie
Graymad Enterprises, Inc.

October 2003

概要 : ASP.NET 2.0 では、コードをこれまでで最も簡単に処理できるようになりますが、それをどのように実現するかを検証します。 Code ディレクトリを使用するとサイトのコードが自動的にコンパイルされると同時に、プリコンパイルを行うことで配置がこれまでで最も簡単にできるようになります。

この資料のソース コードのダウンロード

目次

はじめに
"新しい" 分離コード モデル
\Code ディレクトリ
利息計算機
プリコンパイルのサポート
インプレース プリコンパイル
配置用プリコンパイル
あらゆる場所で IntelliSense
まとめ

はじめに

コード ネーム ASP.NET 2.0 (後ろに続くコード ネームは次期リリースの Microsoft® Visual Studio® .NET を指します) という次期リリースの Microsoft® ASP.NET には、新機能 (と既存の機能からの変更点) が数多く含まれています。 ASP.NET 2.0 の新機能の一部は、基盤となっている Microsoft® .NET Framework の新機能を利用します。 利便性が高まった機能の 1 つとして、コードのコンパイルに関連する機能があります。

この資料では、ASP.NET 2.0 で主にどのようにコンパイル モデルが変更され、その結果 ASP.NET アプリケーションを記述する際にどのような影響があるかについて説明し、使用例を紹介します。

コンパイル機能の変更点と新機能を分類すると、次の 4 つの基本領域に分けられます。

  1. 分離コード モデルの変更点
  2. 新しい Code ディレクトリ
  3. ASP.NET アプリケーションをプリコンパイルする機能のサポートの追加
  4. Microsoft® IntelliSenseR の機能強化

"新しい" 分離コード モデル

Visual Studio .NET 2002 または 2003 でサイトを開発すると、"分離コード" と呼ばれる機能が既定で使用され、表示関連の要素 (HTML マークアップ、コントロールなど) と UI 関連のプログラミング ロジックが分離されます。 開発者が Web フォームを新しく作成すると (たとえば foo.aspx とします)、Codebehind クラス ファイルが自動的に作成されて関連付けられます。このクラス ファイルは、その Web フォームと同じ名前が付けられ、プロジェクトに使用している言語に応じて、拡張子 .vb または .cs が付けられます。 クラス ファイルと Web フォームの関連付けは、@ Page ディレクティブの CodebehindInherits 属性で行います。

クラス ファイルに記述されるイベント処理コードには、イベント ハンドラを適切なイベントにつなぐコードと共に、Visual Studio Web フォーム エディタで .aspx ファイルに追加したそれぞれのコントロールの宣言を分離するコードが含まれます。 Web アプリケーション プロジェクトをコンパイル (ビルド) すると、プロジェクト内の Codebehind クラスが一括して .NET アセンブリにコンパイルされ、アプリケーションの \bin ディレクトリに保存されます。 Web フォーム ページ自体は、実行時に動的にコンパイルされます。このとき、各 Web フォームに関連付けられている Codebehind クラスから継承が行われます。 Visual Studio .NET 2003 と ASP.NET 1.1 を使用した分離コード モデルについては、MSDN ライブラリの資料「Web フォームのコード モデル」を参照してください。

本来、理論上は分離コード モデルは優れたモデルです。だれしもプログラミング ロジックと UI 要素を分離しようと考えるものです。しかし分離コード モデルには難点もいくつかあります。

  • 再ビルドが必要になる。 Visual Studio .NET で Codebehind クラスが実行時に自動的にコンパイルされることはありません。したがって、Codebehind クラスを変更した場合は、プロジェクト全体を再ビルドして、変更が認識されるようにする必要があります。 (@ Page ディレクティブの src 属性を使用して、分離コード ファイルを動的にコンパイルするように指定できます。ただし、Visual Studio .NET の既定動作ではありません)
  • 共同で開発する場合に問題がある。 1 つのアセンブリ ファイルにプロジェクトの Codebehind クラスがすべてコンパイルされるので、複数の開発者で作業すると、ボトルネックが発生しがちです。
  • コードが破損しやすい。 コントロールが (.aspx ページの) 宣言としても、(Codebehind クラスの) プログラムとしても存在するので、両方のコントロールを正しく同期を取りながら保持しないと、コードは簡単に破損します。
  • 複雑性が増し、単一ファイル サポートがない。 Visual Studio .NET では、IntelliSense による入力補完等、生産性向上のための多くの機能に分離コードを使用する必要があります。 あいにく、そのような機能を使用すると、比較的複雑なコードが Codebehind クラスに大量に書き込まれ、コードの脆弱性が高まります。これは、Visual Studio .NETによって書き込まれたコードを変更すると、ページが容易に破損する場合があるためです。

上記の難点を念頭に置いて、ASP.NET および Visual Studio 2005 の担当チームは分離コード モデルを見直すことにしました。 新しい分離コード モデルには、Microsoft® Visual Basic® .NET および C# の新機能である、パーシャル クラス (C# ではパーシャル タイプ) を利用します。 パーシャル クラスを使用すると、クラスのさまざまな部分を複数のファイルに定義できます。 定義した各部分は、コンパイラによりコンパイル時にコンパイルされます。 ASP.NET 2.0 では、@ Page ディレクティブの新しい CompileWith 属性と Classname 属性を使用して、.aspx ページと組み合わせる Codebehind パーシャル クラスを識別します。 パーシャル クラスを利用し、その他にも変更を行ったことで、ASP.NET チームは以下のことを実現しました。

  • Codebehind クラスでコントロールを宣言したり、イベントをつなぎ合わせるコードを記述する必要がなくなりました (イベントはコントロールの宣言部分で宣言としてつなぎ合わされます)。
  • Web フォーム ページと Codebehind クラスの両方を実行時にコンパイルできるようになり、変更を行うたびにプロジェクト全体を再ビルドする必要がなくなりました。
  • 共同開発のときにファイルが競合することが減りました。
  • 分離コード ファイルを使用して作業する開発者と、(すべてのコードとマークアップを .aspx ファイルに記述する) 単一ファイルで開発する開発者が、いずれも同じ IDE エクスペリエンスを共有できます。

次に、変更前と変更後の分離コード モデルを示します。 次のコードは、分離コードを使用して新しい Web フォームを追加した (Visual Studio 2005 ではコード分離 Web フォームと呼びます) ときに、Visual Studio により作成される既定のままのコードです。

Visual Studio .NET 2002/2003

WebForm1.aspx:


<%@ Page Language="vb" AutoEventWireup="false"
  Codebehind="WebForm1.aspx.vb" Inherits="TestWebApp_121602.WebForm1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
  <head>
    <title>WebForm1</title>
    <meta name="GENERATOR" content="Microsoft Visual Studio .NET 7.1">
    <meta name="CODE_LANGUAGE" content="Visual Basic .NET 7.1">
    <meta name=vs_defaultClientScript content="JavaScript">
    <meta name=vs_targetSchema
      content="https://schemas.microsoft.com/intellisense/ie5">
  </head>
  <body MS_POSITIONING="GridLayout">    <form id="Form1" method="post" runat="server">
   </form>
  </body>
</html>

WebForm1.aspx.vb:


Public Class WebForm1
    Inherits System.Web.UI.Page

#Region " Web Form Designer Generated Code "

    'This call is required by the Web Form Designer.
    <System.Diagnostics.DebuggerStepThrough()> _
    Private Sub InitializeComponent()

    End Sub

    'NOTE: The following placeholder declaration is 
    'required by the Web Form Designer.
    'Do not delete or move it.
    Private designerPlaceholderDeclaration As System.Object

    Private Sub Page_Init(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles MyBase.Init
        'CODEGEN: This method call is required by the Web Form Designer
        'Do not modify it using the code editor.
        InitializeComponent()
    End Sub

#End Region

    Private Sub Page_Load(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles MyBase.Load
        'Put user code to initialize the page here
    End Sub

End Class

Visual Studio 2005

Default.aspx:


<%@ page language="VB" compilewith="Default.aspx.vb"
  classname="ASP.Default_aspx" %>

<html>
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form runat="server">

    </form>
</body>
</html>

Default.aspx:


Imports Microsoft.VisualBasic

Namespace ASP

Expands Class Default_aspx

End Class

End Namespace

上記の例から明らかなとおり、Visual Studio 2005 で生成したコードの方が、断然すっきりとした読みやすいコードになっています。 読みやすいだけでなく、ドラッグ アンド ドロップ機能や IntelliSense を犠牲にすることなくコードを作成できます。

\Code ディレクトリ

\Code ディレクトリを追加したことも ASP.NET 2.0 の便利で優れた新機能といえます。 \Code ディレクトリは、\bin ディレクトリと同様に ASP.NET で使用する特別なディレクトリですが、さらにひと工夫されています。 \bin ディレクトリがアプリケーションで使用するアセンブリをあらかじめコンパイルして保存するデザインになっているのに対し、\Code ディレクトリは実行時に動的にコンパイルするクラス ファイルを保存するデザインになります。 したがって、ビジネス ロジック コンポーネント、データ アクセス コンポーネントなどのクラスをアプリケーションのある 1 か所に配置して、どのページからも使用できるようにすることができます。 クラスは実行時に動的にコンパイルされ、\Code ディレクトリのあるアプリケーションから自動的に参照されます。配置前にプロジェクトをビルドしたり、明示的にクラスへの参照を追加する必要がありません。つまり、コンポーネントを変更したり、XCOPY だけで配置したりドラッグ アンド ドロップ操作で配置することが簡単にできます。 コンポーネントを簡単に配置したり、参照できるだけではありません。\Code ディレクトリを導入することで、ローカライズに使用するリソース ファイル (.resx) を簡単に作成したり .resx ファイルに簡単にアクセスできるほか、WSDL ファイル (.wsdl) のプロキシ クラスが自動的に生成およびコンパイルされます。

\Code ディレクトリの機能について、例を見ながら詳しく理解しましょう。 最初の例は、簡単なビジネス コンポーネントを作成し、Web フォーム ページからアクセスする方法です。

利息計算機

まず、Visual Studio 2005 を開き、Compilation という新しい Web サイトを作成します。 Web サイトを作成すると、IDE は図 1 のようになります。

Dd297731.codecompilation_fig01(ja-jp,MSDN.10).gif

図 1. Visual Studio 2005 の Web サイト

次に、プロジェクトを右クリックして [新しいフォルダ] をクリックし、Web サイトに \Code フォルダを追加します。 フォルダ名は「Code」としてください。ただし、大文字と小文字を区別する必要はありません。 \Code フォルダを追加したら、新しいクラス ファイルを追加できます。フォルダを右クリックして [新しい項目の追加] をクリックします。[新しい項目の追加] ダイアログ ボックスの [テンプレート] ペインの [クラス] をクリックします。 このクラスの名前を「CalculateInterest.vb」とします。 続けて、利息を計算するコードを追加します (コードは Class ステートメントと End Class ステートメントの間に記述します)。


Public Function CalcBalance(ByVal Prncpl As Integer, _
                        ByVal Rate As Double, _
                        ByVal Years As Integer, _
                        ByVal Period As Integer) As String
    Dim BaseNum As Double = (1 + Rate / Period)
    CalcBalance = _
        Format(Prncpl * System.Math.Pow(BaseNum, _
        (Years * Period)), "#,###,##0.00").ToString
End Function

コンポーネント クラスが完成したら、Default.aspx ページを変更して、データ入力に必要なフィールドを用意しコンポーネントの CalcBalance メソッドを呼び出す必要があります。 話を簡単にするために、Default.aspx のコード リストを省略せずに記載します (Default.aspx では単一ファイル コード モデルを使用しています)。

Default.aspx:


<%@ page language="VB" %>

<script runat="server">    
    Sub Button1_Click(ByVal sender As Object, _
        ByVal e As System.EventArgs)
        Dim Calc As New CalculateInterest
        Label6.Text = "$" & _
            Calc.CalcBalance(Convert.ToInt32(TextBox1.Text), _
                (Convert.ToInt32(TextBox2.Text) / 100), _
                Convert.ToInt32(TextBox3.Text), _
                Convert.ToInt16(Dropdownlist1.SelectedValue))
        Label6.Visible = True
    End Sub
</script>

<html>
<head runat="server">
    <title> Interest Calculator</title>
</head>
<body>
    <form runat="server">
        <asp:label id="Label1" 
            runat="server">Principal ($):</asp:label>
        <asp:textbox id="TextBox1" runat="server">
        </asp:textbox>
        <br />
        <asp:label id="Label2" 
            runat="server">Interest Rate (%):</asp:label>
        <asp:textbox id="TextBox2" runat="server">
        </asp:textbox>
        <br />
        <asp:label id="Label3" runat="server">Years:</asp:label>
        <asp:textbox id="TextBox3" runat="server">
        </asp:textbox>
        <br />
        <asp:label id="Label4" 
            runat="server">Compounding Frequency:</asp:label>
        <asp:dropdownlist id="Dropdownlist1" runat="server">
            <asp:ListItem Value="1">Annually</asp:ListItem>
            <asp:ListItem Value="4">Quarterly</asp:ListItem>
            <asp:ListItem Value="12">Monthly</asp:ListItem>
            <asp:ListItem Value="365">Daily</asp:ListItem>
        </asp:dropdownlist>
        <br />
        <asp:label id="Label5" 
            runat="server">Ending Balance: </asp:label>
        <asp:label id="Label6" 
            visible="false" runat="server"></asp:label>
        <br />
        <asp:button id="Button1" 
            runat="server" text="Calculate" onclick="Button1_Click" />
    </form>
</body>
</html>

変更した Default.aspx は、デザイン ビューで表示すると図 2 のようになります。

Dd297731.codecompilation_fig02(ja-jp,MSDN.10).gif

図 2. デザイン ビューで表示した Default.aspx

1 点重要な注意事項があります。コンポーネント クラスを呼び出すコードを <script> ブロックに入力するときは、図 3 に示すようにコンポーネント クラスを含めて、常に IntelliSense により入力補完が行われます。Visual Studio .NET 2003 では、サーバー側の <script> ブロックでは IntelliSense が機能しませんでしたが、この点を大きく改善しました。

Dd297731.codecompilation_fig03(ja-jp,MSDN.10).gif

図 3. ソース ビューでの IntelliSense

Default.aspx をブラウザに出力すると、図 4 のように表示されます。元金、利率、年数の適当な値を入力して [Calculate] をクリックすると、図 5 のように表示されます。

Dd297731.codecompilation_fig04(ja-jp,MSDN.10).gif

図 4. Default.aspx の初期画面

Dd297731.codecompilation_fig05(ja-jp,MSDN.10).gif

図 5. 計算後の表示

リソース ファイル

Visual Studio .NET 2002 または 2003 で Web アプリケーションを開発した経験があれば、Web フォーム ページを新しく作成するごとに、.aspx ページ ファイル自体や分離コード ファイル (.vb または .cs) とは別に、対応する名前で .resx 拡張子が付いたファイル (つまり、WebForm1.aspx.resx) が作成されていることにお気付きに違いありません。 一般の Web 開発者には、何のために存在し、どのように使用すればよいのか直感的にはわかりづらいこれらのファイルは、これまでは無視されたり、削除されていました。 端的に答えれば .resx ファイルとは "リソース ファイル" であり、主な用途は、ローカライズ対象の各言語で記述したテキスト文字列など、さまざまなバージョンのリソースを保存することです。

Visual Studio .NET 2002 および 2003 では、リソース ファイルをプロジェクトをビルドする過程でプロジェクト アセンブリに追加する必要がありました。さらに、名前空間を 2 つインポートし、ResourceManager オブジェクトを作成し、GetString メソッドを呼び出すことで、初めてリソース文字列にアクセスできます。

Visual Studio 2005 では、\Code ディレクトリを導入したことで、リソースにアクセスする過程が大幅に簡素化されます。次の例で確認しましょう。

最初は、先ほどの例と同じプロジェクトを使用して、リソース ファイルを作成します。 まず、先ほど作成した Compilation Web サイトを右クリックし、[新しい項目の追加] をクリックします。 [新しい項目の追加] ダイアログ ボックスで [アセンブリ リソース ファイル] テンプレートをクリックし、名前を「strings.resx」と付けて [開く] をクリックします。 strings.resx の既定での表示は図 6 のようになります。

Dd297731.codecompilation_fig06(ja-jp,MSDN.10).gif

図 6. XML エディタを使用したリソース ファイルの編集

以下の項目をデータ テーブルに追加します (comment、type、および mimetype の各列は空白のままでかまいません)。

Name Value
txtColorPrompt Please choose a color:
txtColorResponseRed You chose Red!
txtColorResponseGreen You chose Green!
txtColorResponseBlue You chose Blue!

strings.en-GB.resx という新しいリソース ファイルを追加して同じ処理を繰り返します。今度は、データ テーブルに次の項目を追加してファイルを保存します (txtColorResponse* に対するエントリを追加していないので、どのクライアントに対しても strings.resx の項目の値が使用されます)。

Name Value
txtColorPrompt Please choose a color:

ここで、Code ディレクトリの特殊効果を使うために、2 つの .resx ファイルを Web サイトのルートから Code ディレクトリにドラッグする必要があります。 操作が終わった状態は、図 7 のようになります。

Dd297731.codecompilation_fig07(ja-jp,MSDN.10).gif

図 7. Code ディレクトリに格納した 2 つの .resx ファイル

作成したリソース ファイルがどの程度使用しやすくなったかを確認するために、プロジェクトに Web フォームを追加します。Web サイト ノードを右クリックして [新しい項目の追加] をクリックします。 [新しい項目の追加] ダイアログ ボックスで Web フォームを選択し、ページ名を「ColorPicker.aspx」と付けて [開く] をクリックします。 次のコード リストに従ってページを変更します。

ColorPicker.aspx:


<%@ page UICulture="en-GB" language="VB" %>

<script runat="server">

    
    Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
        Label1.Text = Resources.strings.txtColorPrompt
    End Sub
    
    Sub Submit_Click(ByVal sender As Object, _
        ByVal e As System.EventArgs)
        Label1.ForeColor = _
            System.Drawing.Color.FromName(Dropdownlist1.SelectedValue)
        Select Case Dropdownlist1.SelectedValue
            Case "Red"
                Label1.Text = Resources.strings.txtColorResponseRed
            Case "Green"
                Label1.Text = Resources.strings.txtColorResponseGreen
            Case "Blue"
                Label1.Text = Resources.strings.txtColorResponseBlue
        End Select
        Dropdownlist1.Visible = False
        Submit.Visible = False
    End Sub
</script>

<html>
<head runat="server">
    <title>Color Picker</title>
</head>
<body>
    <form runat="server">
        <asp:label id="Label1" runat="server">Label</asp:label>
        <asp:dropdownlist id="Dropdownlist1" runat="server">
            <asp:listitem value="Red">Red</asp:listitem>
            <asp:listitem value="Green">Green</asp:listitem>
            <asp:listitem value="Blue">Blue</asp:listitem>
        </asp:dropdownlist>
        <asp:button id="Submit" 
            text="Submit" runat="Server" onclick="Submit_Click" />
    </form>
</body>
</html>

ColorPicker.aspx をブラウザに出力すると、既定で図 8 のように表示されます。このページを、英国用に設定したシステムでブラウザに出力すると (ページの UICulture プロパティを "en-GB" に設定してページを保存すると、このシステム設定を再現できます)、図 9 のように表示されます ("colour" に u が追加されています)。

Dd297731.codecompilation_fig08(ja-jp,MSDN.10).gif

図 8. ColorPicker.aspx の既定の出力

Dd297731.codecompilation_fig09(ja-jp,MSDN.10).gif

図 9. 英国のシステム用の ColorPicker.aspx の出力

ASP.NET 2.0 でリソース ファイルにアクセスするには、コードが 1 行あれば十分です。 Code ディレクトリに保存したリソース ファイルは、自動的に埋め込みと参照が行われるので、名前空間やアセンブリを参照する必要が一切なく、リソース文字列にアクセスするためのオブジェクトを作成する必要もありません。 さらに、どのリソース ファイルを使用するかは、ユーザーのブラウザの設定に基づいて ASP.NET の側で判断するので、実行時にリソース ファイルを決定して、適切に応答する必要はありません。 そのままで正しく機能します。

プリコンパイルのサポート

ASP.NET Web フォームの利点の 1 つとして、(分離コードを使用していない場合に限り) コンパイルが動的に行われるので、.aspx ページを変更して保存すると、再コンパイルしなくてもページが更新されて簡単です。 ただし、すべてのアプリケーションで動的なコンパイルが適切というわけではありません。動的コンパイルを行うと、アプリケーションに最初にアクセスするときに初回のみパフォーマンスに影響がでます。 また、ソース コードを使用せずにアプリケーションを配置したいことも少なからずあるでしょう。

上記の状況に該当するユーザーは、ASP.NET 2.0 で Web サイトのプリコンパイルがサポートされると聞いて、リリースが待ち遠しくなることでしょう。 ASP.NET 2.0 では、インプレース プリコンパイルと、配置用プリコンパイルの 2 つのモードがサポートされます。

インプレース プリコンパイル

インプレース プリコンパイルは、Web サイトのすべてのページを手作業で一括コンパイルできるようにするモードです。 ユーザーがアプリケーション内の任意のページを最初に表示するときに、配置用プリコンパイルを行う場合を除き、必ず一括コンパイルが行われます。一括コンパイルが行われている間、ユーザーは待機することになります。

インプレース プリコンパイルを使用する主な理由は、次の 2 点です。 1 点目は、最初のページ要求のときに一括コンパイルによるパフォーマンスの影響がでないようにするため、2 点目は、コンパイル エラーをユーザーより早く検知するためです。

インプレース プリコンパイルは簡単です。次のように、Web サイトのルートに、特別なハンドラ名 precompile.axd を付けて参照するだけです (ASP.NET のトレース機能に詳しい方は、trace.axd ハンドラ名と似ていることにお気付きでしょう)。


https://localhost/mywebsitename/precompile.axd

mywebsitename はWeb サイト名です。 サイトをプリコンパイルした後で、サイト内のページを要求すると、コンパイルの待ち時間がなく、すぐに要求が実行されます。

配置用プリコンパイル

次に説明するプリコンパイル モードを使用すると、Web サイト全体の実行可能なバージョンを作成できます。このサイトは、HTML などの静的ファイルを含めたソース コードを使用せずに配置できます。 したがって、配置用プリコンパイルによって、コードの中の知的財産に容易にアクセスできなくなります。 プリコンパイルして生成されるアセンブリ ファイルとスタブ ファイルは、XCOPY、FTP、エクスプローラなどの手段で実稼動サーバーに配置できます。

ASP.NET 2.0 には、サイトを配置用プリコンパイルするための aspnet_compiler.exe というコマンドライン ユーティリティが用意されています。ASP.NET プリコンパイラをファイル システム Web サイト上で呼び出すには、コマンド ウィンドウを開き、.NET Framework のディレクトリに移動して (<windows>\Microsoft.NET\Framework\<version> にインストールされています)、次のコマンドを入力します。


aspnet_compiler /v /<websitename> -p <source> <destination>

<websitename> はブラウザで入力する Web サイトの名前です。<source> および <destination> はファイル システムのパスで、それぞれコンパイルするサイトの場所とコンパイルしたサイトを出力する場所を指定します。 例の Web サイトの場合、コマンドは次のようになります (このコマンドは 1 行のコマンドです)。


aspnet_compiler /v /Compilation -p c:\WebSites\Compilation c:\WebSites\Compilation_Compiled

ASP.NET プリコンパイラで利用できるオプションをすべて表示するには、次のようなコマンドを入力します。


aspnet_compiler /?

コマンドライン オプションの中には、Web サイトが、有効な Microsoft® インターネット インフォメーション サービス (IIS) アプリケーションでないと正しく機能しないものがあります。

Microsoft® エクスプローラでコンパイル先のディレクトリに移動します。そこでプリコンパイルで生成された Web サイトを確認すると、bin ディレクトリが作成され、中にアセンブリと記述ファイルが格納されています。また bin ディレクトリの他に、元のページと同じ名前が付いたスタブ ファイルが格納されていますが、スタブ ファイルからはコード (HTML および実行可能コード) が取り除かれています。 生成したサイトをブラウザに出力すると、元のサイトと同じように表示されます。 配置用プリコンパイルを実行したサイトは、プリコンパイルが完了していることは自明なので、そのようなサイトに対してはインプレース プリコンパイルを実行できません。

あらゆる場所で IntelliSense

Visual Studio .NET 2002 および 2003 について不満だったことの 1 つとして、IntelliSense などの生産性向上機能のサポートが不統一ということがあります (多くの開発者が同じ不満を抱えているはずです)。 ツールボックスから HTML ビューのページにコントロールをドラッグしようとしても、不可能です。 HTML ビューを表示しているときには、ツールボックスの Web フォーム パネルを利用できないのが現実です。 .aspx ページにコードを記述するのに、分離コードを使用するのではなくインラインで記述するのも無理ではないですが、IntelliSense、ドラッグ アンド ドロップをはじめとする多くの機能を犠牲にする必要があります。 最後になりますが、最近 MSDN ASP.NET Developer Center の記事 (英語) に執筆したように、Visual Studio .NET 2002 または 2003 でデザイン時にカスタム コントロールをサポートするには、あまり洗練されていない (けれども効率的な) XSL の解析を含めて、多数の指示に従う必要があります。

良いニュースがあります。ASP.NET 2.0 ではコンパイル モデルを統一することで、上記の問題がすべて解決されます。 Visual Studio 2005 では、インラインでコードを記述することも、新しい分離コード モデルを使用してコードを記述することもできます。いずれの場合も同様に、コントロールのドラッグが可能になり、IntelliSense による構文補完がサポートされるほか、コーディングの方法によっては使用したくても使用できなかった生産性向上のための機能がすべてサポートされます。 さらに、カスタム サーバー コントロールと Web コントロールの両方に対するデザイン時におけるサポートが向上し、たとえば、ソース ビュー (従来の HTML ビューと等価な Visual Studio 2005 でのビュー) でカスタム コントロールを表示したときにも IntelliSense による構文補完が行われます。

まとめ

ASP.NET 2.0 のコンパイル モデルが変更され、Visual Studio 2005 に付属する機能も改善されることは大きな飛躍であり、開発者が IDE で提供されている生産性向上のための機能をフル活用したまま、望んでいた柔軟性を手に入れられるようになります。 分離コード モデルが大幅に簡略化されることで、使用しやすく、扱いやすくなります。同時に、インライン コードが完全にサポートされるようになることで、すべてのコードを 1 つの .aspx ファイルに記述することを望んでいた開発者は満足するに違いありません。

\Code ディレクトリによって、変化が激しい中小プロジェクトの担当者はもちろんのこと、ビルド プロセスが複雑なために作業が難航しているユーザーの生産性は大幅に向上するでしょう。 また、ビジネス ロジック コンポーネント、リソース ファイル、WSDL ファイルなどのリソースにアクセスするために、リソースの代わりになるものを自動的にコンパイル、埋め込み、または作成したものを自動的に参照することで、これまでよりも直感的かつ簡単に、ごくわずかのコードだけでアクセスできるようになります。

開発者は、プリコンパイル機能を使用することで、ソース コードや HTML を使用しなくても十分に機能する Web アプリケーションを出荷して、サイト起動時のパフォーマンスの向上や、必要であれば貴重な知的財産の保護を図ることができます。

最後になりましたが、Visual Studio 2005 なら、これらの機能をすべて組み合わせることで、さまざまなことを実現するのに、任意のページをどのビューで表示してもインライン モデルと分離コード モデルの両方で IntelliSense が完全にサポートされるので、開発ツールによって 1 つの開発形態にしばられることがなくなります。

著者について

G. Andrew Duthie は Graymad Enterprises, Inc. Non-MS link の創業者かつ社長であり、Microsoft Web 開発テクノロジのトレーニングとコンサルタントを行っています。 Active Server Pages の登場以来、多層 Web アプリケーションの開発に従事してきました。 ASP.NET 関連の著書は『Microsoft ASP.NET Programming with Microsoft Visual Basic』、『Microsoft ASP.NET Programming with Microsoft Visual C#』、『ASP.NET in a Nutshell』 (第 2 版) など多数あります。 Software Development、Dev-Connections の各種カンファレンス、Microsoft Developer Days、VSLive をはじめとするイベントでの講演も多数経験しています。 また、International .NET Association (INETA) Non-MS link Speaker's Bureau のメンバとして .NET ユーザー グループでも講演活動を行っています。 詳しい活動の様子は、会社の Web サイト http://www.graymad.com/ Non-MS link (英語) をチェックしてください。