第2章 Visual Basic .NET の利点

1. Visual Basic .NETの利点

  • エラーの少ない、よりよいコードが書ける
  • オブジェクト指向のサポート
  • .NET Frameworkへのフルアクセス

Visual Basic .NETの利点を紹介します。

より堅牢なアプリケーションの構築が可能に

エラーが少なく、生産性の高い、よりよいコードが書けるようになります。Visual Basic .NETでは、従来よりも厳密なタイプチェックが行なわれるようになります。これにより、バグの入り込みにくい安定したコードを記述できます。

オブジェクト指向の、より完全なサポート

オブジェクト指向が、より完全にサポートされたことで、オブジェクト指向に基づいて設計されたシステムの実装が容易になります。

.NET Frameworkへのフルアクセス

さらに、Visual Basic .NETは.NET Frameworkへのフルアクセスが可能です。これにより、Windowsフォーム、ASP.NET(Webフォーム、XML Webサービス)、ADO.NETなどの新しい機能を利用することができます。今まではWindows APIを利用しなければ解決できなかったような場面でも、.NET Frameworkが提供する機能を利用できます。これで、Visual Basicユーザーが手を焼いていたWindows APIの呼び出しの時の苦労が軽減されます。

.NET言語による共通技術の利用

設計、開発、実行すべての段階において、Visual Studioで共通のフレームワークを使います。つまり、言語は違っても、C#、 C++などと共通の技術(共通のランタイム=共通言語ランタイム、クラスライブラリ、ツールなど)が利用できることになります。また、共通のデータ型のセット(共通型システム)を利用します。これにより、言語間の相互利用における型の問題がなくなります。

例外処理

例外処理が利用できるようになります。 これは、従来のエラー処理に比べてより詳細な対処が可能で、かつ、低コストであることが特徴です(第4章の「エラー処理(例外処理)」を参照)。

その他

そのほかの利点として、レジストリ登録が不要、簡単なファイルコピーによる配置、DLL Hellの排除などをあげることができます。これらに関する詳細は、この章の後半で紹介しています。
また、今まではVisual Basicで作成できなかった、マルチスレッドのアプリケーションやWindowsサービス(常駐プログラム)なども作成できるようになっています。

2. Visual Basic .NETの開発環境の変更

  • 開発環境の改良
    • タスクリスト
    • ダイナミックヘルプ

Visual Basic .NETの開発環境の改良も見逃せません。改良された開発環境の一例を紹介します。

タスクリスト

Visual Basic 6.0と同様に、コーディング中に自動構文チェッカーがミスをチェックしています。さらにVisual Basic .NETでは、構文ミスがあると、エディタ中に波線が表示され、それと同時にこのタスクリストにリアルタイムで表示されます。さらに、ビルドエラーや、TODOコメントなども表示されます。「表示」メニューの[タスクの表示]にある[すべて]をチェックをすると、すべての情報が表示されます。またはフィルタをかけて必要な情報のみを表示することもできます。
TODOコメントを利用すると、保留にしている作業を忘れずにすむため便利です。

' TODO: 条件判定の式を追加する。

とコード中に記述しておくと、図1のように一覧で表示されます。タスクリスト上をダブルクリックすると、その行にジャンプして編集することができます。

図1:タスクリスト

ダイナミックヘルプ

名前の通り動的なヘルプで、たとえば、コーディング中にはテキストカーソルの位置にあるコードに関するヘルプが、また、フォームのデザイン中であれば今アクティブになっているオブジェクトに関するヘルプへのリンクが一覧で表示されます。図2は、エディタで「Sub」とコーディングしたとき(Subのコードの付近にカーソルがある状態の時)の様子です。

図2:ダイナミックヘルプ

このように、生産性を上げるためのさまざまな新機能を利用できることも、Visual Basic .NETの利点といえます。

3. Windowsアプリケーションの利点

  • Visual Basic .NETでWindowsアプリケーションを作成する利点
    • Windowsフォーム(リッチなGUIをもつアプリケーションを簡単に開発)
    • 生産性をUpする開発環境

Visual Basic .NETでは、Windowsフォームを利用して、リッチなユーザーインターフェイス機能を持つアプリケーションを作成できます。
Windowsフォームから、XML Webサービスへアクセスしたり、ADO.NETで取得したデータをコントロールにバインドして利用したりすることができます。また、.NET Frameworkの提供する、より高度な描画機能(GDI+)や、今まで苦労してきたWindows APIの代わりとなる機能を簡単に利用することができます。
Visual Basic .NETになっても、クリックやドラッグ&ドロップ操作などを中心とした、従来どおりの開発のしやすさは変わりません。
また、Windowsアプリケーション開発の生産性をさらにUpするいくつかの機能が追加されています。

インプレースメニュー編集

インプレースメニューを利用すると、Visual Basic 6.0のときよりも、直感的にメニューを作成することができます(図3)。

図3:メニューの作成がカンタンに

アンカリング

アンカリングの機能を利用すると、ウィンドウの大きさにかかわらず、常に右上からの位置を一定に保つことができるボタンをコーディングなしで簡単に実現できます(図4)。

図4:上からの位置と右からの位置を固定すると

タブオーダー

タブオーダーも、フォーカスを移動させたい順にコントロールをクリックしていくだけで簡単に設定できます(図5)。

図5:タブオーダーもクリックするだけ

4. Webアプリケーションの利点

  • Visual Basic .NETでWebアプリケーションを作成する利点
    • .NET Frameworkの利用
    • Windowsアプリケーションのように簡単に開発

Visual Basic 6.0だけでは、Webアプリケーションを作成することが困難なため、多くの開発者はVisual Basic 6.0でCOMコンポーネントを作成し、それをASP(Active Server Pages)から利用するというプログラムを書いていました。あるいは、すべてASPだけでWebアプリケーションを構築してしまっていた方もいるかもしれません。ASPは非常に簡単にサーバーサイドのプログラミングを実現できる反面、次のような欠点がありました。

  • レイアウトとコードが混沌としている
    GUI構成部分とコードがすべてASPファイルに含まれているため、作成、保守、デバッグが困難。
  • コードの構造化や機能のカプセル化が困難
    コードの構造化や機能のカプセル化が難しく、そのためコードがわかりにくくなりがち。いわゆる「スパゲティプログラム」になりやすい。
  • ASPはインタープリタ型
    スクリプトなので、大きなプログラムではそのパフォーマンスが問題。
  • 貧弱なGUI
    VBのフォームのようなリッチなGUIを、開発環境のサポートなしにHTMLを書くことだけで実現するのはとても困難。
  • 複数のブラウザに場合分けのコードで対応
    多様化するブラウザ事情に、すべて個別のページで対応するのが困難。
  • 開発環境の非力さ
    Microsoftが提供する、最もすぐれたWeb開発環境のVisual InterDevでさえも、Visual Basicユーザーにとっては満足できるものではなかった。

これまでの、Webアプリケーション開発におけるグチをつらつらと書きましたが、.NET Framework+Visual Basic .NETはこれらをすべて解消します。

  • レイアウトとコードが分離できる
    ASP.NETは、レイアウトとコードを分離してページを作成する機能を持っている。
  • コードの構造化や機能のカプセル化が可能
    ASP.NETは、Visual Basicと同様の構造でコーディングできる。
  • ASP.NETは非インタープリタ型
    MSILという中間コードにコンパイルされた後、実行時にその環境に最適なコードに変換されて実行される。そのため、今まで以上の実行速度が期待できる。このコードはキャッシュされるので、2回目以降はさらに実行速度が高くなる。
  • リッチなGUI
    Webフォームと豊富なコントロールを利用し、複雑なGUIを簡単に作成できる(Webフォームやコントロールについては第3章の「Webアプリケーション」を参照)。
  • 複数のブラウザに場合分けのコードで対応
    これらのコントロールはブラウザによって異なるインターフェイスを自動で振り分けて提供する機能がある。
  • Visual Basic 6.0の、さらに上をいく開発環境
    これからは、Visual Basicの「Windowsアプリケーションを作成する快適さ」でWebアプリケーションを開発することができる。

5. .NET Framework

  • 開発と実行の新しいプラットフォーム
    • .NET言語と共通言語仕様(CLS)
    • .NET Frameworkクラスライブラリ
    • 共通言語ランタイム(CLR)

Windows上の分散システムをデザインするためのWindows DNAはあまりにも有名です。しかし、このWindows DNAは、プレゼンテーション、ビジネス、データの各層をデザインするための技術がそれぞれ別々に存在していました。つまり、Windows DNAアーキテクチャを利用した分散アプリケーションを作成するには、各層の技術に関して高度な、しかも別々の知識/技術が必要でした。
一方、.NET Frameworkは、これら、すべての層をカバーする開発と実行のプラットフォームを提供します(図6)。
具体的には、

・.NET言語と共通言語仕様(CLS:Common Language Specification)
・.NET Frameworkクラスライブラリ
・共通言語ランタイム(CLR:Common Language Runtime)

が存在します。

図6:.NET Framework主要コンポーネント

.NET言語と共通言語仕様(CLS:Common Language Specification)

共通言語仕様とは、.NET言語が共通で利用する言語機能のサブセットです。このサブセットに準拠する言語(ここでは.NET言語と呼んでいます)では、言語間の相互利用が容易です。また、.NET Framework対応のアプリケーションは、複数の.NET言語による開発が可能です。

.NET Frameworkクラスライブラリ

.NET Frameworkが提供するクラスライブラリは、ユーザーやプログラムのインターフェイスを提供するライブラリ、データアクセスのためのライブラリ、標準的な機能を提供するライブラリに分けることができます。
インターフェイスの提供は、Windowsアプリケーションだけでなく、Webアプリケーションを利用したユーザーインターフェイスや、XML WebサービスといったプログラミングインターフェイスをVisual Basic .NETで提供できることを意味しています。
また、データアクセスのためのADOやXMLなど、従来COMコンポーネントとして追加提供されていた機能が、.NET Frameworkに組み込まれていることを確認することができます。
標準的なシステムレベルの機能を提供するライブラリは特に基本クラスライブラリと呼ばれます。

共通言語ランタイム(CLR:Common Language Runtime)

共通言語ランタイムは、その名の通り、.NET言語共通のランタイム(実行エンジン)です。メモリ管理やガベージコレクションなど、.NET Frameworkの土台となる変更要素を含んでいます。この利点として、

・多くをランタイムが提供してくれるため、開発者が多くのコーディングをしなくてもよい
・下部のアーキテクチャが隠蔽されることにより、その処理を考えなくてよい

をあげることができます。しかし、もともとVisual Basic自身がこのような設計思想に基づいて作られていたため、私たちにとっては、大きなニュースではありません(多分この恩恵は、Visual Basicと同じランタイムを利用することになったVisual Basic .NET以外の.NET言語が受けた恩恵でしょう)。
これ以外の利点として、DLL Hellの終焉(「DLL Hellの終焉」参照)や、容易なデプロイメント(配置:「容易なデプロイメント」参照)をあげることができます。

● Plus One

ガベージコレクションとVisual Basic

ガベージコレクションは、実はVisual Basic開発者にとっては、必ずしもうれしい追加機能とはいえません。なぜなら、Visual Basicはもともと、オブジェクトを参照している変数がスコープを抜けるなどして参照から外れると、自動的にオブジェクトが破棄されていました。つまり、自動メモリ解放機能であるガベージコレクションのような機能は、備わっていたといえます。
そして、.NET Frameworkの「ガベージコレクション」は、Visual Basicの「ガベージコレクションのような機能」と違う点があります。それは、オブジェクトが破棄されるタイミングです。共通言語ランタイムでは、メモリが必要だと判断したときに、ガベージコレクションを行ないます。言い換えると、必要でなければいつまでたってもガベージコレクションが行なわれないわけです。たとえば、後処理(Visual Basic .NETではClass_Terminateイベントの代わりにFinalizeメソッドを利用します)を記述していたとしても、忘れたころに、それが実行されるかもしれないのです。つまり、Visual Basic開発者が期待する、

「参照している変数がスコープを抜けた」→「オブジェクト破棄」→「後処理」

という一連の流れは、期待通りのタイミングで行なわれるとは限らないということを覚えておかなくてはいけません。

6. DLL Hellの終焉

  • DLL Hellとは
  • DLL Hellの原因
  • そして、DLL Hellの終焉

DLL Hellとは

簡単に言うと、DLL Hell(地獄)とは、DLLのバージョンアップによって、前のバージョンを利用していたアプリケーションが動かなくなってしまうことや、それを避けるためにバージョンごとに別々のDLLファイルを作成した結果、システムディレクトリに同じようなDLLがあふれかえってしまう状況を指します。

DLL Hellの原因

もともと、DLL(Dynamic Link Library)は多くのシステムで利用されている、ディスクやメモリの節約を可能にするコンパイル済みのライブラリを提供するための技術です。
このDLLを使用することで起きるDLL Hellは、COMで解決される予定でした。
COMのインターフェイスの決まりに則って正しくCOMを作成し、インストーラを使って正しくインストールしていれば、こういった問題は解決されたはずです。しかし、実際にはこの問題は根絶することはできませんでした。
原因として考えられることは、本来守るべきルール(「COMではインターフェイスを変えてはいけない」「下位互換性を保たなければいけない」など)を守らなかった設計者やプログラマのミスをあげることができます。
もっと基礎的な問題として、きちんとDLLをインストールせずに、ファイルを単純に上書きしてしまったというような原因もあるかもしれません。そこまでひどくないにしても、インストーラがきちんとバージョンをチェックせずにDLLをコピーしたときにも同様の状態になります。

そして、DLL Hellの終焉

この問題を解決するため、“プライベートDLL”という考え方があります。これはアプリケーションが利用するDLLを各々のフォルダなどに配置するというものです。これをSide-By-Side配置と呼びます。これにより、たとえば同じDLLが別のフォルダに配置され、しかも、それらを利用するアプリケーションが起動しているとき、同じ名前の異なるバージョンのDLLがシステム上で同時に実行されることが可能になります。
.NET Frameworkでは、このプライベートDLLの考え方を拡張して、DLL Hellに終わりを告げます。
まず、共通言語ランタイムは、同じDLLの異なるバージョンを管理することができ、それらが同時に実行されることもできるようになっています。
そして、DLLを利用する側でも、コンパイル時に、必要なライブラリのバージョンの情報がコンパイルしたモジュールに含められます。これにより、必ず正しいDLLが利用されることになります。さらに、バージョンポリシーを利用して、そのDLLの最新のバージョンを利用するように指定したり、ある特定のバージョンを指定したりすることもできます。
また、Visual Studio .NETには適切なデプロイメント(配置)を簡単に行なえるインストーラも存在しますので、これを利用することができます。

まとめ

Visual Basic 6.0で正しくCOMコンポーネントを作成し、ディストリビューションウィザードを使ってきちんと配布していた場合、DLL Hellは終わっていたのかもしれません。そのような方にとっては、.NET FrameworkはCOMの代わりにより、確実な新しい方法で、DLL Hellを解消することにしたと捉えることができます。

7. 容易なデプロイメント

  • XCOPYで完了するデプロイメント
  • 推奨:適切なツールによるインストール(推奨)

Visual Basic 6.0で作成したアプリケーションを配布するときは、多くの場合ディストリビューションウィザードや市販のインストーラ作成ツールを利用してインストーラを作成していました。なぜなら、アプリケーションのデプロイ ofメント(配置)のためにしなくてはならないことがたくさんあったからです。
.NET Frameworkの目標のひとつは、このデプロイメントを単純化することです。そのために、「副作用なしのインストール」と「XCOPYによるデプロイメント」を導入しています。

副作用なしのインストール

.NET Frameworkにおける配置の単位は、「アセンブリ」です。アセンブリは自己記述的な性質(自分自身を説明する能力)を持っています。アセンブリには、そのアセンブリ自身の名前やバージョン情報、提供するクラス/メソッド/プロパティ、そのアセンブリが利用するアセンブリのバージョン情報、などが含まれます。この性質のために、レジストリに必要な情報を登録する必要がなくなり、その結果として別のアプリケーションに影響を与えることがなくなります。
また、Side-By-Sideの導入により、そのアプリケーションが利用するアセンブリを同じディレクトリに含めることができるため、アプリケーションのインストールによって他のアプリケーションに影響を与えることもなくなります。これにより、DLL Hellを回避します。

XCOPYによるデプロイメント

レジストリに依存していないため、デプロイメントの究極の方法として、アセンブリをDOSコマンドのXCOPYでコピーする方法を選択することもできます。
ただ、実際にはユーザーにファイルコピーを強いるのではなく、セットアップツールを利用したグラフィカルなユーザーインターフェイスの提供を推奨します。

Visual Studio .NETによるデプロイメント

Visual Studio .NETには、いくつかのデプロイメント用のプロジェクトテンプレートが用意されています。これらのテンプレートは、「新しいプロジェクト」ダイアログボックスの[セットアップ/デプロイメントプロジェクト]ノードで確認できます(図7)。

  • セットアッププロジェクト── Windowsインストーラ(.msiファイル)を作成します。自動修復機能や、オンラインデマンドインストールなど、高度なインストールおよびアプリケーションの維持を行なうことができます。
  • Webセットアッププロジェクト── Web アプリケーションのインストーラ(.msiファイル)を作成します。セットアッププロジェクトとの違いは、ファイルの配置される場所です。セットアッププロジェクトは、ファイルをターゲットコンピュータのファイルシステムにインストールし、Webセットアッププロジェクトは、ファイルをWebサーバーの仮想ディレクトリにインストールします。
  • マージモジュールプロジェクト── コンポーネントをパッケージ化したモジュール(.msmファイル)を作成します。これを、Windowsインストーラに含めて、インストールすることができます。これにより、複数のWindowsインストーラで共有利用できます。
  • CABプロジェクト── WebブラウザにActiveXコントロールなどをダウンロードするキャビネットファイル(.cab)を作成します。
  • セットアップウィザード

以上のいずれかのデプロイメントプロジェクトを対話式に作成するためのウィザードです。
これらの、Visual Studio .NETによるインストール以外にも、すでに紹介したXCOPYや、Webアプリケーションの配置のために[プロジェクト]-[プロジェクトのコピー]を利用することもできます。ただし、これらは単純にファイルがコピーされるだけであるため、たとえばIISのディレクトリ設定などを別途手動で行なわなくてはいけません。
できるだけ、「コピー」ではなく、Windowsインストーラなどによる「デプロイメント」を行ないましょう。

図7:デプロイメント用のプロジェクトテンプレート