DLL の闇 (4)
折角なので，先ほどの The Old New Thing に記事について少し触れておきましょう．人ごとではないことが分かるかと思います．
- Don't name your DLL "Security.dll"
- http://blogs.msdn.com/oldnewthing/archive/2004/07/02/171769.aspx
事件は，ASP.NET 開発で，Security というプロジェクトを作ってしまったところから始まります．デフォルトのままであれば，生成される .NET アセンブリの名前は Security.dll になるでしょう．不幸だったのは，システムディレクトリにもまったく同名の DLL が存在したこと，そしてこの DLL が実際に裏で使われていたということでした．その結果，database との接続がうまくいかなくなった，というわけです．
.NET では，.NET 内で閉じる限り，アンマネージドコードな DLL に比べ比較的一貫したモジュール探索や同一性検査が行われます．しかし，拡張子 DLL を使用している以上，今回のように Win32 DLL としての側面が，アンマネージドコードな世界で問題を引き起こすことがあります．
例として，Managed DirectX でありそうなシナリオを示します．
まず，Sample Browser から，Tutorial 1: Create a Device をコピーしてきます．これはまあ問題なく動くとしましょう．
次に，Direct3D 絡みの処理をまとめるために，D3D9 というクラス ライブラリ プロジェクトを作成します．
- D3D9 というクラス ライブラリ プロジェクトを作成
さらに，元々のプロジェクトの参照設定で，この D3D9 プロジェクトを追加します．
- D3D9 プロジェクトを参照設定に追加
この段階で，Crtl+F9 または「デバッグ」→「デバッグなしで開始」を選択し，プロセスを起動してみるとどうなるでしょうか？
- 起動
とまあこうなるわけです．
結論としては，.NET 開発においても，アセンブリ名には十分注意する必要があります．システムディレクトリに存在する DLL 名は，極力避けた方が賢明でしょう．同名の DLL を使用するアンマネージドコードがあった場合，問題になり得ます．あるいは，競合しそうな短い名前の DLL は，exe ファイルと同じディレクトリに配置しないようにするべきです．
参考までに，Vista build 5456 の system32 以下の DLL 一覧を置いておきます．
http://www.dwahan.net/nyaruru/hatena/vista-5456-system32-dll.txt
例えば P2P という名前のプロジェクトを作っていて，生成アセンブリ名が P2P.dll というのに心当たりがある方，気をつけた方がいいかもしれませんよ．
