（はじめに：「再頒布」の読み方は「さいはんぷ」。だよん）
WindowsアプリケーションをC++で作るとき、ユーザーインタフェースのところをMFCで作るべきか.NETで行くべきかと今更のように毎回悩んでしまう輩も多いのではないだろうか。今回一仕事を終えたタイミングであえてここのところの自分としての認識をメモしておきたい。
苦労して作ったアプリケーションがマシン環境の違い故に顧客のところで動かない。あなたの作ったプログラムを動かすためだけに.NET Frameworkの最新版をインストールするなんて他のインストールされてるソフトとの兼ね合いもあるしいやだ、なんとかして欲しい、何だ.NET Frameworkって、どんだけ時間かかんだ、どんだけ容量食うのと、あろうことか当の顧客に渋られた場合の不毛さ絶望感はどうだ。開発の何倍もの苦労と時間をかけても報われないリスクがそこには潜んでいるのである。
そんな状況ならMFCにしておけ。Qtのように商用目的か非商用かで悩んだりする必要のないMFCにしておけ。VC++2008から10年ぶりに改善が組み込まれ、TR1なんかもサポートされ始めた、堂々NativeなMFCにしておけ。Qtのシグナルスロットや.NETのイベント・デリゲートなんてないけど、同等のしくみなんてhogeクラスのstaticメンバ使っていくらでも自作できるから、いくらでもイベントドリブンなオブザーバーパターンが全然Qtや.NETと同じく作れてしまうMFCにしておけ。
「.NET Frameworkなんかよりも、マシン環境変更に与えるリスクのぐっと少ないMicrosoft Visual C++ 2008 SP1 再頒布可能パッケージをまずネットからダウンロードしてインストールしておいて下さい、一瞬で終わりますから」とお願いしさえすれば、あなたのマシンでVC2008SP1を使ってビルドしたMFCの.exeだけ渡せば、それがもう顧客のマシンで動いてしまうのですよ。MFC80何とか.dllや、msvcr80何とか.dll も要らない、マニフェストファイルに苦しめられることもないのであります。
このように、開発したアプリケーションを最終的にどう配布展開していくのか、とくにインフラが統一されていない、例えば自分とこの会社とはインフラもマシンの機種も違う、よその会社さんに一発もののアプリを手軽に配布したい、といったような状況では、ほとんどMFCしか選択肢はないのではないかと思ってしまう今日この頃であるが、いかがだろうか。
ただ、注意すべき点が一つある。「再頒布」の読み方がわからないという点だ！うっかり顧客に電話などしようものなら、読み方がわからないことをさらけ出してしまうことになるぞ。つまらないことで顧客の信頼を失いたくなければ、連絡は必ずメールですることだ。気をつけろ！
後日記：「再頒布」は「さいはんぷ」と読みますねー。（「再頒布 読み方」のG様検索結果で本日記がいつのまにか結構上位どころかトップに出てくるようになっちゃったのに気付き責任を感じた次第。）
あと、MFCスタティックリンクしちゃうという手もあるけどね。それでいける場合は限られるかもしんないけどそれでいけちゃえばOKだし。
