gtest/gmock1.6.0をmake installする

gtestとgmockが1.6.0からmake installできなくなってしまいました。今回は開発者からしたら不本意でしょうが、make installを有効化する方法を説明します。

その前に

とりあえず背景から。先日リリースされたgmockの1.6.0をインストールしようとしたところ、make installが失敗するという現象にぶち当たりました。READMEやその他にもインストール方法は一切記述されていません(リンク方法は書いてありますが、記述に問題があります)。気になって調べたところ、開発者が意図的にmake installを無効化したそうです。

無効化した理由も調べてみました。gtestはコンパイルオプション次第でABIが大きく変わります。gtest/gmockはC++で書かれているので、ヘッダにもコードが多く記述されています。そのため、gtestを使う側でも、gtestインストール時に設定した一部のコンパイルオプションを再度明示的に設定してコンパイルしなければ、libgtestとうまくリンクできなくなります。当然、gmockを使う場合も、gtestとコンパイルオプションを合わせないといけません。この辺をよくわかってない人達が、適当にインストールしたgtestをリンクしようとして問題を起こしまくっており、その問い合わせが結構来るようになったので問題視してmake installを無効化したようです。

make install方法

と言うわけで、事情を知った上で自己責任でmake installする分にはまったく問題がないでしょう。というかできないと不便なんですよ。確かに開発は普通にできますが面倒です。

まず(なぜかzipでしか配布されなくなってしまった)gtest1.6.0.zipを解凍します。その中にMakefile.amというのがあるのですが、そいつを編集します。編集する前に、Makefile.amに書き込み権限がないのでchmodしておきましょう。Makefile.amを開くと、下の方に

# Disables 'make install' as installing a compiled version of Google                                                                                                                       
# Test can lead to undefined behavior due to violation of the                                                                                                                              
# One-Definition Rule.                                                                                                                                                                     

install-exec-local:
        echo "'make install' is dangerous and not supported. Instead, see README for how to integrate Google Test into your build system."
        false

install-data-local:
        echo "'make install' is dangerous and not supported. Instead, see README for how to integrate Google Test into your build system."
        false

こんなのが書いてあります。これを全部消します。その次に、Makefile.amが置いてあるディレクトリでautoreconfを実行します。後は普通にconfigure、make、make installを実行するだけです。だいぶ大雑把な説明ですが、分からないところは適時ググってください。gmockも似たような手順でインストールできます。

念のため、このページの手順で問題が起こっても絶対にMLで問い合わせないでくださいねー。そういうのを防止するためにmake installが無効化されているので。自己責任です。

google-gtest: value parameterized testのCombineを使う

テスト用のフレームワークを使ってユニットテストより粒度の荒いテスト(コンポーネントテストなど)を書こうとすると、1つのテストケースが複数のパラメタに依存してきます。例えばDecoratorパターンで、DecoratorAとDecoratorBをつなげてテストすることを考えましょう。DecoratorAが3つオプションを持ち、DecoratorBが2つオプションを持つとすると、AとBをつなげた場合は合計6通りのオプションの組み合わせに対してテストを記述する必要が出てきます。このような場合は、考え得るすべての組み合わせをテストするのが理想的ですが、手でそれらをすべて書くのは困難です。

上記の問題に対処するために、gtestの機能の1つであるvalue parameterized testのCombineというジェネレータを使って、複数のパラメタの組み合わせに対するテストを効率的に記述する方法を紹介します。

ジェネレータ

まずvalue parameterized testのジェネレータについて説明します。ジェネレータとは名前の通りテストで使用する値を生成する「なにか」です。
INSTANTIATE_TEST_CASE_Pにこのジェネレータを渡すことで、複数の値に対するテストを効率的に記述できるのがvalue parameterized testの特徴です。Value parameterized testに関する詳細はドキュメントを見てください。しょぼくても日本語で読みたいなら何回か前にこのブログで紹介したものがあるので見てみてください。

Combineの説明に入る前に、簡単に既存のジェネレータを紹介しておきます。gtestでは以下のジェネレータを提供しています。

• Range(begin, end[, step])
  • 特定の区間の値を生成(stepはデフォルトで1)
• Values(v1, v2, ..., vn)
  • 任意の個数の値を生成
• ValuesIn(container) or ValuesIn(begin, end)
  • STLコンテナや配列に入っている値を利用
• Bool
  • true,falseを生成
• Combine
  • 今回の目玉

例えば

Values("a", "b", "c")

とすると、テストケースに"a", "b", "c"がそれぞれ渡ってきます。

const set<string>& ValidNames() {
  static set<string> names;
  if (!names.empty()) return names;
  names.insert("Enoch");
  // 他の71通りの名前を追加
  return names;
}

ValuesIn(ValidNames())

このようにすると、72通りの呼び方すべてをテストすることが可能になります。

Combine

Combineは複数のジェネレータから得られた値の直積をテストの入力として使うためのジェネレータです。
Combineは以下のようにして使います。

testing::Combine(g1, g2. g3. ..., gn)

gにはジェネレータを渡します。Combineから得られる値は、std::tr1::tupleとして渡されます。なのでtupleが使えない環境では機能を利用することはできません。ちなみに、tupleはgcc4.1.2でも使えたのでCent君でも安心です。

話を戻します。ジェネレータの値は、テストコードからはGetParam関数経由で取得します。Combineを使った場合、GetParamはtupleを返すので、次のようにしてそれぞれのジェネレータの値を取得することができます。

std::tr1::get<0>(GetParam()); // ジェネレータ1の値
std::tr1::get<1>(GetParam()); // ジェネレータ2の値
...

Combineを使う例として、以下のAnd関数のテストを書いてみましょう。

bool And(bool a, bool b) { return !(!a || !b); }

引数のa,bに対して(true, true),(true, false),(false, true),(false, false)の4通りの組み合わせを入力してテストする必要があります。このテストはvalue parameterized testを使って以下のように記述できます。

typedef std::tr1::tuple<bool, bool> Parameters;
class AndTest : public testing::TestWithParam<Parameters> {
};

INSTANTIATE_TEST_CASE_P(AndTestInstance,
                        AndTest,
                        testing::Combine(testing::Bool(), testing::Bool()));

TEST_P(AndTest, test) {
  bool a = std::tr1::get<0>(GetParam());
  bool b = std::tr1::get<1>(GetParam());
  ASSERT_EQ(a && b, And(a, b));
}

このテストケースの場合、CombineのジェネレータとしてBoolを2つ渡しています。Boolは集合{true, false}を生成します。なのでBoolとBoolの直積を作ることで、必要な組み合わせをすべて生成することができました。

Combine Combine

Combine自体もジェネレータなので、CombineをCombineすることもできます。

bool AndOr(bool a, bool b, bool c) { return !(!a || !b) || c; }

typedef std::tr1::tuple<std::tr1::tuple<bool, bool>, bool> Parameters;
class AndOrTest : public testing::TestWithParam<Parameters> {
};

INSTANTIATE_TEST_CASE_P(AndOrTestInstance,
                        AndOrTest,
                        testing::Combine(testing::Combine(testing::Bool(), testing::Bool()),
                                         testing::Bool()));

TEST_P(AndOrTest, test) {
  bool a = std::tr1::get<0>(std::tr1::get<0>(GetParam()));
  bool b = std::tr1::get<1>(std::tr1::get<0>(GetParam()));
  bool c = std::tr1::get<1>(GetParam());
  ASSERT_EQ((a && b) || c, AndOr(a, b, c));
}

さっきのテストコードを変えてみました。Combineをネストすると、受け取る側のtupleもネストする感じになります。かなり見づらいですね。でも使いどころはありそうな感じです。楽しいです。

まとめ

今回はvalue parameterized testのCombineジェネレータの使い方を紹介しました。Combineを使うと、複数のオプションの組み合わせ全通りに対するテストを比較的簡単に記述することができます。

ソフトウェアの規模が大きくなると、手で書いたテストの信頼性も徐々に落ちていくし、メンテナンスも大変になります。gtestの便利な機能を使いこなして華麗にテストを記述しましょう。正直gflagsやglogは使って後悔している面も多いのですが(Google社内で使う分には非常に便利なんだろうと思います)、gtestはまだまだ付き合って行きたい感じです。C++でテストを書くならこれですね。

へーgtest 2年くらい前に流行ったよねー2年前から使ってるわー。

MessagePack(-RPC) for Luaをちょろちょろ改造中

スローペースで開発してます。サーセン。今週は折角の休暇だったので仕事コードにはあえて一切触れず趣味プロに走りました。あんまりプログラミングの時間をとれませんでしたが、癒されました。

MessagePack for Lua (mplua) 0.2.0

http://github.com/nobu-k/mplua

print(msgpack.unpack(msgpack.pack('hoge')))

みたいなのができるようになりました。中国の方からの要望で作成。Packer, Unpackerは従来通り使えます。

ほかはMessagePack-RPC for Luaのためのリファクタリングがメインになりました。あと$(libdir)/libmsgpack-lua.soというのも作るようになりました(lua/.../msgpack.soは今バージョンからただのシンボリックリンクになりました)。

あとは今後の予定です。

まずクリティカルなものとして、luaL_error絡みの問題があります。Luaの例外処理はlongjmpで行われます。それ自体は問題ないのですが、スタックを辿りながらローカル変数のデストラクタを呼んだりはしてくれないので、C++と相性が良くありません。簡単な対処として、lua自体のコンパイルオプションで、longjmpを例外に置き換えることもできるようです。なんですが、まあ、対応しておくに越したことはないですね・・・。仕事でもちょっと使ってみたいので対応します。

次にPackerですが、今後Stream Serializationチックな何かに対応する予定です。

p = msgpack.Packer(ここに関数を追加)
p:pack(...)
p:pack(...)
p:flush()

のような感じになりそうです。一定のサイズがたまったら関数が呼び出される感じになるはずです。なんかグラフのシリアライズとかをされてる方がいたので、これがあると意外と便利そうです。packの度にデータくっつけたり自分でファイルに書いたりするの面倒ですしね。

クラスのシリアライゼーションはインターフェイスが難しいので悩み中。Luaから見たら全部テーブルなんですよ。ええ。

Unpackerもfeederに対応する予定です。

u = msgpack.Unpacker(ここに関数を追加)
for v in u ...(文法忘れた)

普通はfeedでデシリアライズするデータを与えますが、データが足りなくなったらコンストラクタに渡した関数が呼ばれてそこから補充されます。

MessagePack-RPC for Lua(まだ危険な状態)

https://github.com/nobu-k/mprpclua

とりあえずクライアントは普通に使えるようになり、非同期呼び出しもできるようになりました。が、まだ検証不十分です。簡単なドキュメントを書きながらテストしてみます。

クライアントは後はコネクションプーリングと複数サーバへの非同期呼び出し、futureへのコールバック設定に対応できればたぶんRuby版と同じ機能がそろうのかなーと思います。

サーバはまだ設計段階です。なやましい。

終わりに

長いこと作業できてなかったんですが、その間に何件か海外の人から反応を頂きました。ありがたいです。海外というのが良いですね。MessagePackがもっと世界に広がるように頑張りたいと思います。

あと、ここ数ヶ月仕事も私生活もドタバタしてましたが、いろいろ落ち着いてきたので今後はちょこちょこ手を加えて行けると思います。別のライブラリも作ったりするよ〜。

googlegtestのType Parameterized Testsも便利すぎる件

前回のValue Parameterized Testsに続き、今回はType Parameterized Testsというのを紹介したいと思います。コードがコンパイルできなかったらタイポしてるので本家の方を見てね。

Type Parameterized Testsとは

Type Parameterized Tests(勝手にTPTと略します)とは、複数の型に対するテストコードを生成するための機能です。Value Parameterized Testsの型バージョンと思えばOKです。

例えばstd::vectorのユニットテストを考えます。

TEST(VectorTest, push_test)
{
  vector<int> v;
  vにいろいろ
}

このとき、vectorにはいろいろな型を入れてテストをしてみたいですね。そうなると今までは

TEST(VectorTest, int_push_test)
{
  vector<int> v;
  vにいろいろ
}

TEST(VectorTest, float_push_test)
{
  vector<float> v;
  同じようなチェック
}

... 他の型についても ...

みたいな感じでやる必要がありました。これは面倒ですね。TPTを使うとこのようなテストコードを簡単に書くことができます。

TPTの使い方

コードの構成は次のようになります。

template<typename T>
class HogeTest : public testing::Test {
};

TYPED_TEST_CASE_P(HogeTest);

TYPED_TEST_P(HogeTest, test_1)
{
  テストコード
}

TYPED_TEST_P(HogeTest, test_2)
{
  テストコード
}

...

TYPED_TEST_P(HogeTest, test_n)
{
  テストコード
}

REGISTER_TYPED_TEST_CASE_P(HogeTest,
  test_1, test_2, ..., test_n);

typedef testing::Types<型1, 型2, ..., 型n> HogeTypes;
INSTANTIATE_TYPED_TEST_CASE_P(Hoge, HogeTest, HogeTypes);

上から順に説明していきます。基本はTEST_Fを使うときと同じですが、TEST_Fで使っていたfixtureがテンプレートクラスになります。次に、TYPED_TEST_CASE_Pに定義したfixtureを渡します。その後、TYPED_TEST_Pで各テストを定義します。定義したテストはREGISTER_TYPED_TEST_CASE_Pに登録します。最後にINSTANTIATE_TYPED_TEST_CASE_Pにテストしたい型のリストを登録します。型のリストはtesting::Typesを使って指定します。テストしたい型が1つだけの場合は、その型を直接INSTANTIATE_TYPED_TEST_CASE_Pに渡せばOKです。

INSTANTIATE_TYPED_TEST_CASE_Pの最初の引数はテストのインスタンス名で、これは他のインスタンス名とかぶらないように適当に付ければOKです。

HogeTypesに渡した型は、TypeParamという名前で参照できます。

TYPED_TEST_P(HogeTest, test)
{
  TypeParam value;
}

こうすることで、HogeTypesで指定した型すべてに対してテストが実行されます。ちなみに、REGISTER_TYPED_TEST_CASE_Pにテストを登録し忘れると、実行時に忘れていることを教えてくれます。

さっきのvectorのテストをTPTで書き直す

includeなどは省略してます。

template<typename T>
class VectorTest : public testing::Test {
};

TYPED_TEST_CASE_P(VectorTest);

TYPED_TEST_P(VectorTest, push_test)
{
  vector<TypeParam> v;
  テストコード
}

REGISTER_TYPED_TEST_CASE_P(VectorTest, push_test);
typedef testing::Types<int, string, double, ...> TestTypes;
INSTANTIATE_TYPED_TEST_CASE_P(VT, VectorTest, TestTypes);

見た目はこんな感じになりますね。テストコードはどう書けば良いんでしょうか。vectorに具体的な値を入れないとテストになりません。かといって、intにstringを代入したりすることはできないので、型毎に値を用意する手段が必要になります。

型毎に処理を変えるテクニック

恐らく慣れている人なら自然とこうするだろうという感じですが、

template<typename T>
struct Traits {};

template<>
struct Traits<型> {
  型 value_type;
  その他の補助情報  
}

// 補助関数
template<typename T>
typename Traits<T>::value_type RandomValue();

// 特殊化
template<>
Traits<型>::value_type RandomValue() { ... }

こんな感じで型毎に特殊化したテンプレート補助関数を用意しておくと、テストコードを書きやすくなります。TにはもちろんTypeParamを渡します。例えばさっきのVectorTestでは、型毎に挿入する値を返す関数を用意しなければならないのですが、このようなテンプレートの補助関数を用意しておくことですべての型に対して同じテストコードを書くことができます。

上だとTraitsみたいなのを挟んでますが、そうすると言語上は同じだけど、ロジック上は異なる型のテストなどが書きづらいです。例えば個人的な話ですが、int64_tと日時型(内部的にはint64_t相当)によって処理を変えたかったのですが、testing::Typesに両方の型を渡しても、両方とも言語上は同じ型なのでほとんど意味がありませんでした。

そこで

struct Int64Type { ... };
struct DatetimeType { ... };

typedef testing::Types<Int64Type, DatetimeType> ...;

のような感じで型に相当する構造体を作り、補助テンプレート関数もInt64Type, DatetimeTypeなどに対して特殊化するという方法を採用しました。その結果かなり良い感じでテストを書くことができたので満足です。他にも熱いテクは沢山あると思うので、是非紹介してください。

fixtureを使う

TPTのドキュメントにはfixtureの使い方があまり書いてありません。テスト間の共通処理・リソースを一箇所に書けないとあまりありがたみがないのでなんとかしたいところです。なので調べてみました。幸いソースコードに結構コメントが書いてあったので何とかなりました。

コードで書いた方がわかりやすいので、下にfixtureのメンバにアクセスするためのコードを書いておきます。

template<typename T>
class HogeFixture : public testing::Test {
protected:
  int normal_member;
  static int static_member;
  typedef int TypeDef;
};

TYPED_TEST_CASE_P(...省略...)
{
  // normal_memberを参照するにはthis->が必要
  this->normal_member;

  // static_member
  this->static_member;
  TestFixture::static_member;

  // typedef
  typedef typename TestFixture::TypeDef YATypeDef;
}

(static)メンバにはthis経由、typedefなどにはTestFixture経由でアクセスします。typedefを使用する場合はtypenameも必要です。

メンバにアクセスするためにthisが必要なのは、TYPED_TEST_CASE_Pで生成されるテンプレートクラスが、次のようにさらにテンプレートクラスを継承しているためです。

template<typename T>
class C {
...
};

template<typename T>
class D : public C<T> {
...
};

C++の仕様上、class Dからclass Cのメンバにアクセスするためには明示的な修飾が必要になります。

おわり

無事fixtureの使い方がわかったので、後はどうにでもなりますね。MPLを駆使すればValue parameterized testのValues風のことをTPTでもできそうで夢が広がります。メタメタな感じで良いですね。テストだからコピペして良い、メンテしづらくても良いというのはもはや時代遅れです。テストのメンテナンスコストなめんな！

つーかValue Parameterized Testsと組み合わせて使いたくなりますね。できるのかな。

google-gtestのValue-Parameterized Testsが便利過ぎる件

google-gtestにいつの間にかValue-Parameterized Tests(VPTと勝手に略します)という機能が追加されていました。

以前のgtestでは、実行される度に特定の値を変更しながらテストすることが面倒でした。例えば、boolのフラグを持っており、それがtrueかfalseかで挙動が変わるようなケースです。そのようなテストケースを書きたかったら、次のようにヘルパ関数を用意するか、テストをコピペして値を変更するなどの処理を書く必要がありました。

TEST(HogeTest, hogehoge) {
  hogeHelper(true); // trueでテスト
  hogeHelper(false); // falseでテスト
}

前者では問題が発生した時に異なるテストが同じ行番号を出力するため、問題の把握がしづらくなります。また、TESTがたくさんあった場合、それぞれにヘルパ関数を用意する必要があり、非常に面倒です。後者は言うまでもなくメンテナンスが大変です。

そこで登場するのがVPTです。この機能を使うにはTEST_Fするときと同じような感じでクラスを用意します。TEST_Fのときにはtesting::Testを継承しますが、VPTの場合はtesting::TestWithParam<型>を継承します。型にはパラメタの型を指定します。

class HogeTest : public testing::TestWithParam<bool> {
  // testing::Testを継承したときと同じような感じ
};

testing::TestWithParamはtesting::Testの派生クラスであるため、HogeTestではSetUp/TearDown/SetUpTestCase/TearDownTestCaseなど、TEST_Fで使用できる関数を同じように利用できます。

次にテストケースの書き方ですが、VPTの場合はTEST_Pを使用します。TestWithParamで指定したパラメタはGetParam()で取得することができます。

TEST_P(HogeTest, hogehoge)
{
  GetParam()でboolの値が帰ってくるので、hogeHelperの中身をここに書くことができる
}

GetParamで与える値は、INSTANTIATE_TEST_CASE_Pを使って指定します。

INSTANTIATE_TEST_CASE_P(HogeTestHogeInstance,
                        HogeTest,
                        testing::Values(true, false));

このようにすると、定義したすべてのTEST_Pに対してtrue,false両方の値でテストが実行されます。

値の部分にはRange, Values, ValuesIn, Combineなどを指定できるらしいです。詳しくはドキュメントを参照してください。例えばValuesInにはSTLのコンテナが渡せるので、

set<string> Parameters();
INSTANTIATE_TEST_CASE_P(AbabababaInstance,
                        AbabababaTest,
                        testing::ValuesIn(Parameters()));

のようなこともできます。手動で値を列挙するのが大変そうな場合に便利です。今回は4つの要素を持つ集合のべき集合-空集合なものに対してそれぞれテストを実行したかったので、かなり助かりました。ソースを読んでないので使い方は良く分かりませんが、Combineを使うと集合の直積を作ってくれるらしいので、それだけでもかなりいろいろなことができるんじゃないでしょうか。

ちなみに、Valuesなどに渡す値はSetUpTestCaseよりも前に評価されてしまうので、少し複雑な値を用意したいときなどは上記のようにグローバル/ファイルスコープな関数を一個はさんであげるとよさそうです。その場合、SetUpTestCaseが呼ばれる前に何度かその関数が呼び出されるようなので、値の生成に時間がかかるような場合はstatic boolなローカル変数を用意して、一度だけ値の生成を行うような実装にしておくといいかもしれません。SetUpTestCase以降は余分な呼び出しは起こりませんでした。

Ubuntu 10.04 で Xinerama を有効にした状態でデュアルディスプレイにする際の注意点

最近Ubuntuをアップグレードするたびにこの手のエントリを書き続けている気がする・・・！

Ubuntu 10.04 で Xinerama 周りにバグが入ったようです。症状としては、画面をまたいでマウスを移動するといきなりピクピク分身し出して、その後もしつこくマウスを動かしたり何かウィンドウを出したりするとXが落ちてログイン画面に戻ります。かなり致命的。

バグが発生する条件はもう判明しています。ScreenのIDが、(Screenの位置的に)左から右、上から下にかけて昇順に並んでいないと画面をまたいでマウスを移動させる際にバグります。例えば、Screen 1がScreen 0の左側にあるとバグります。自分の場合は、メインのスクリーンを右側に横置き、サブスクリーンを左側に縦置きという感じで使っていたので見事にこのバグを踏んでしまいました。

解決策

この問題はxorg.confのScreenのIDを手動で再割り当てすることで解決します。2つしか画面がなかったらScreenのIDっぽいのの0と1を全部入れ替えればOK。

縦置きしているディスプレイがプライマリになっちゃうのが嫌

上記の解決策は根本的な解決にはなっていません。今回のケースだと、縦置きの方がプライマリになってしまうので、メニューやタスクバー的なものが全部そっちに表示されてしまいます。縦置きの上の方にメニューがあると首が疲れるので勘弁して欲しいです。

これを直そうと頑張ってみたのですが、なかなかうまくいかず。ScreenのOptionのmetamodesに書いてあるDFP-0、DFP-1の0,1を入れ替えると、プライマリとサブが入れ替わるんですが、回転する方も逆になってしまいます。これはDeviceのRotate CCWを、もう片方のDeviceの方へカットすれば行けそうかと思ったんですが、そうすると今度は画面が崩れます・・・。xorg.confの細かい部分が分からないので、今回はもうこれで妥協してしまいましたが、もうちょっと調べれば行けそうな感じではあります。

ハイパー妥協策

縦置きと横置きの位置を入れ替えちゃいなよ。という冗談はともかく、今はスペースの関係で縦置きが左側になってますが、今後は右側に置くようにしよう・・・。

まあ五月病で疲れたので今回はこの辺で・・・。気力が戻ってきたら改めて挑戦してみるかも。

追記：情報源書き忘れ

• http://ubuntuforums.org/showthread.php?t=1465950
• https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/563100

64bit Windows7 上の Visual Studio 2008 で BandObjects2.0 をビルドする

BandObjects とは IE のツールバーを簡単に開発するためのなにかです。

ぐぐるといろいろと情報が出てきますが、古い情報が多すぎます。しかし、これは古い情報が悪いんじゃなくて、MS製品の仕様変更が激しすぎるのが原因なので、情報を提供してくれている人を叩いてはいけません。このエントリも数ヶ月後にはゴミになってる可能性があります。悲しい。

入手

http://www.codeproject.com/KB/cs/BandObjects20.aspx

とりあえずここからソースを落としてきます。ユーザ登録が必要です。

多くの記事では Extending Explorer with Band Objects using .NET and Windows Forms - CodeProject を紹介していますが、情報が古すぎました。しかも、http://www.codeproject.com/csharp/dotnetbandobjects.asp こっちのアドレス404なんですけど。とりあえず古いBandObjectsを最近のVisual Studioで使うにはいろいろ改修が必要らしいし、Visual Studioの意味不明な仕様を勉強しても不毛なので、上のBandObjects2.0を落としてくると楽です。

ダウンロードしたzipファイルを解凍してソリューションを開くと、VS2005からVS2008への自動変換が行われます。VMなどを使っている場合は、Windowsのコマンドプロンプトが共有ディスクにアクセスできないため、ローカルディスクへ保存しておくと後々楽です。

問題1: gacutil がない

ビルドを実行すると、.dll自体はできあがるのですが、ビルド後に問題が発生します。まず、gacutil.exeというファイルが見つかりません。これは、ビルド後に実行されるビルドイベントのところで

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil" /if BandObjectsExample.dll

としているためです。Visual Studio 2008 を使っているので、パスを変更する必要があります。しかし、64bit Windows7 だからなのか、VS2008 だからなのかわかりませんが、Visual Studio のディレクトリに gacutil が見あたりません。

このページによると、

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil"

Windows Server 2008 & Visual Studio 2008 ではここにあるそうです。64bit Windows7 でもここにありました。パスがわかったので、ビルド後のイベントを次のように書き換えます。

cd $(ProjectDir)bin\Release

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil" /if BandObjectsLib.dll
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil" /if Interop.SHDocVw.dll

cd している部分も Debug になってるので、 Release でビルドしたい場合は書き換えておきましょう(なんか環境変数っぽいのなかったっけこれ)。補足ですが、ビルドイベントは、プロジェクトのプロパティから設定可能です。

問題2: キャッシュにアセンブリを追加しているときにエラーが発生しました

パスの設定を変更すると

キャッシュにアセンブリを追加しているときにエラーが発生しました: アクセスが拒否されました。このタスクを実行するために必要な管理者の資格情報をもっていない可能性があります。

こういうエラーが起こります。簡単に解決するには、Visual Studioを右クリックし、管理者権限で実行するという方法が有効です。

これは、ここによると、gacutilを実行する際に管理者権限が必要だからだそうです。管理者でログインしていても、管理者権限付きで実行する必要があります。しかし、Windowsにはsudo的なコマンドがなさそうなので、gacutilを実行する Visual Studio を管理者権限で起動する必要がある、という感じです。

ビルドできた

上の問題2個を直したらとりあえずビルドはできました。ただ疲れたので実際にBandObjectsを使ってツールバーは作ってないです。なので、もしかしたら、他にもなんかしないとBandObjectsを利用できないかもしれないです。また問題が発生したら報告しようと思います。