私がC++/CLIを嫌う理由
以前ちょろっと触れたC++/CLIは避けて通りたいという話ですが、そう思うようになった経験談を書いてみます。
はじめてだらけの.NET開発がはじまる
やばい
- このままでは仕事にならないということでソリューションを複数に分割し、作業ソリューションを分割する方向で実験開始。
- プロジェクト参照をdllファイル参照に変更してソリューションを分割する方法も考えたが、C#プロジェクトがdllファイル参照ではビルドフォルダ(bin/$(Configuration))へdllをコピーしてくれない。
このときアプリはこのソリューションだけではなく、同じプロジェクト群を参照するアプリがdllをコピーされる前提ですでにビルド環境が構築されてしまっていた。
これをすべて変更するのは面倒だ…うぬぬ…。 - C#プロジェクト自体をソリューションからはずしてビルドしてみた。なんとビルドが通る！
どうやらC#プロジェクトは.csprojの内容から参照を解決してくれるらしい。これは良いとばかりに200あったプロジェクトを20〜30プロジェクト単位のソリューションに分離。ほとんどのソリューションはうまいことビルドが通った。
…が、しかし！
実はC++/CLIプロジェクトはこの方法が使えない。
しかも、
- Ａ）C++/CLIプロジェクトを参照している場合はそのプロジェクトをソリューションに含めなくてはいけない
- Ｂ）C++/CLIプロジェクトをビルドするにはManaged/Unmanage問わすにソリューションに含めなくてはいけない
と芋づる式に分割できないグループが…
その後さらに実験した結果、Ａ）が実はビルドしなければ良いということに気づく。
構成マネージャでビルドチェックをはずしてC++/CLIプロジェクトをソリューションに追加、そこから依存してるものはソリューションには含めない。これでC++ライブラリもすべてのソリューションに含めなくてはいけない状況も免れた。
だけどビルドしないプロジェクトがソリューションに入ってるのはカッコ悪い。
そこで行き着いたのがC++/CLIプロジェクトをC#で一回ラップする方法。
これだとC#プロジェクトなのでソリューションに含める必要は無くなりますし、プロジェクト参照なのでdllも集められます。
最終的には作業グループのソリューションだけでデバッグできるようになった。グループ外のソースはソリューションエクスプローラには表示されないけど、.pdbがあればステップはできるので問題無し。しかしコンパイルはできないのでコンパイル用のソリューションを複数立ち上げて作業するハメになる。
