稿
目
次
稿
目
次
対象者のレベル
ヘッダとソースの違いがわかる。
Visual Studio でヘッダとソースを用いたクラスを作成できる。
Visual Studio で CLI プログラムが作成できる（gcnew を使用できる）。
DLL 開発
まず、事前に空のソリューションを作っておいてください。そのソリューションへプロジェクトを追加します。「新しいプロジェクトの追加」ダイアログでは、「プロジェクトの種類」で「Visual C++」を選択し、「テンプレート」から「空の CLR プロジェクト」を選び、適当なプロジェクト名を付けてプロジェクトを作成.してください。ここでは「CliDllSample」という名前のプロジェクトを作成しました。
プロジェクトを作成したらプロジェクトのプロパティページを開きます。プロパティページでは左上の「構成」を「すべての構成」に変更し、左側ツリーの「構成プロパティ」から「全般」を選択し、右側の「構成の種類」を「ダイナミック ライブラリ（dll）」を選択、「共通言語ランタイム サポート」を「安全な MSIL 共通言語ランタイム サポート（/clr:safe）」を選択.して「OK」ボタンを押します。
続いて DLL をテストするための CLI プロジェクトを作成します。通常の CLI プログラムを作成する手順でプロジェクトを追加してください。ここでは「Test」という名前のテスト用プロジェクトを作成しました。
また、実行時にテストプログラムが起動するように設定します。ソリューションエクスプローラからテストプログラムのプロジェクトを右クリックし、ポップアップメニューから「スタートアップ プロジェクトに設定」を選択.してくださ。プロジェクト名が太字になって、プログラム実行時に優先してこのプロジェクトのプログラムが動作するようになります。
さらに、テストプロジェクトは DLL プロジェクトに依存するため（DLL プロジェクトで作成された DLL を使用（テスト）するため）依存関係を設定して DLL プロジェクトが先にビルドされるよう設定します。ソリューションエクスプローラでテストプロジェクトを右クリックし、ポップアップメニューから「プロジェクト依存関係」を選択.し、「プロジェクトの依存関係」ダイアログを開いて、「依存先」からテストプロジェクトが依存するプロジェクトを選択してチェックボックスをチェック.し、「OK」ボタンを押します。これで、依存先のプロジェクトが優先的にビルドされるようになります。
一通りの設定が終わったら、ソースコードを記述します。ソースコードレベルでは、クラスの作成方法は基本的に非 CLI プログラムと同じです。ここでは「CliClass」というクラスを作成します。クラスの宣言をヘッダ「CliClass.h」に、クラスメソッドの定義をソースファイル「CliClass.cpp」に記述します。それぞれ..のように記述してください。
#ifndef __CLICLASS_H_
#define __CLICLASS_H_
namespace Parof {
public ref class CliClass {
public:
void ShowMessage();
};
}
#endif
#include "CliClass.h"
using namespace Parof;
using namespace System;
void CliClass::ShowMessage()
{
Console::WriteLine("Hello, World.");
}
ここで、クラス名の最初に付いている「public」は DLL の外に公開する（つまり DLL を使用するプログラムから見えることを意味し、「ref」はこのクラスが CLI に準拠していることを意味します。
クラスを作り終わったら、テスト用のプログラムを作成します。ここでは「Test.cpp」としました。ソースコードは.に示すとおりです。
#ifdef _DEBUG
#using "../Debug/CliDllSample.dll"
#else
#using "../Release/CliDllSample.dll"
#endif
using namespace Parof;
using namespace System;
int main()
{
CliClass ^cc = gcnew CliClass();
cc->ShowMessage();
Console::WriteLine("プログラムが終了しました。何かキーを押してください。");
Console::ReadKey(true);
return 0;
}
「#using」で使用する DLL を指定します。標準ライブラリはパスが通っているので
#using <System.dll>
のようにギュメカッコを使用するのですが、今回は自作のライブラリを使用するので、ダブルクウォーテーションで DLL のあるパスを記述します。ただし、プログラムの実行時にはここで書いたパスとは無関係に、実行ファイルのあるフォルダと同じフォルダに DLL を置きます。
さて、DLL はソリューションフォルダの下にある Debug フォルダ（デバッグビルド時）に作成されます。しかし、ソースコードの記述はプロジェクトのあるフォルダを起点として行われます。したがって DLL のパスはプロジェクトフォルダからひとつ上がったソリューションフォルダの下の Debug フォルダになります。なお、DLL のファイル名は「プロジェクト名.dll」になります。
また、リリースビルド時にはソリューションフォルダの下の Release フォルダに DLL や実行プログラムが作成されるので、
#ifdef _DEBUG
で制御します。「_DEBUG」はデバッグビルド時には自動で設定されるフラグです。ここで特徴的なのは、ヘッダのインクルードもライブラリへのリンク設定も、あるいは DLL のロードを行うコードの記述も無いという点でしょう。「#using」で DLL を指定するだけ、あたかもプロジェクト内にそれらのクラスが存在するかのように DLL 内のクラスを使用することができるのです。
一通りの設定とソースコードの記述が終わったら、ソリューションをビルドして実行してみてください。最後に、ソリューションの構成を.に示しておきます。
実験
さて、本当に DLL だけでヘッダのインクルードもライブラリへのリンクも DLL のロードも不要なのでしょうか？ここでもうひとつ、完全に独立したソリューションを作成して実験してみたいと思います。
新しいソリューション（ここでは「CliDllTest」）を作成し、通常の CLI プログラムを作る手順で CLI プロジェクト（ここでは「CliDllTest」）を作成し、ソースファイル（ここでは「CliDllTest.cpp」）を作成します。
DLL は実行プログラムと同じ場所に置くことになりますが、まだビルドしていないため「Debug」フォルダがありません。そこで、ソリューションフォルダの下に「Debug」フォルダを作成し、そこへ DLL をコピーしてきます.。コピーしてくる DLL はそれだけで完全に独立していますから、デバッグバージョンの DLL でもリリースバージョンの DLL でも、どちらでも構いません。必要に応じてリリースビルド用にも同様のことを行ってください。
CliDllTest.cpp のソースコードは先ほどの Test.cpp と同じでよいでしょう。
ソースコードを記述しているときに気付いたかもしれませんが「#using」しただけでキチンとインテリセンスも機能します.。テストコードを記述できたら、ビルドして実行してみましょう。確かにプログラムが動作するはずです。
いかがですか？簡単でしょう？クラスライブラリの作成が楽しいものに思えてくるのではないでしょうか。
