互換性ない
一方はMFC4.dllで別のdllだからMFCオブジェクト渡すと危険
携帯なので以下略

VC6 と それ以降のバージョンへの過渡期によくある問題ですね。
手っ取り早いのは、過渡期を過ぎるまでVC6, VC9のどちらでもビルド可能な
ソースコードにしてしまうことです。

注意深くやれば、ほとんどのソースコードは共有可能です。
どうにも互換性のない部分だけ、以下の#ifで処理分けします。

#if _MSC_VER > 1200 // VC9
#else // VC6
#endif

DLL側がVC9に対応するまでは、VC6でビルドして、
DLL側がVC9に対応したら、VC9でビルドし直す。

私の場合、そんな方法で対処した記憶があります。

> 皆さんの言っていることと矛盾しているようですが、実際できています。
確かに bun さんがおっ社ているように拡張DLLだと DLL 側からAfxGetApp()で
アプリ側の CWinApp* が取れるようですね。
でもVC6とVC9ではCWinApp自身が同じではないので非常に危険です。
（と言うより、互換性がないのでやっちゃいけないのでは...）

つまりExe側でなんとか出来るような問題ではないでしょう。
> 一方はMFC4.dllで別のdllだからMFCオブジェクト渡すと危険
この一語に尽きる。

皆さん、ありがとうございます。

結局、そう簡単にはできないみたいですね。
簡単と言うより無理に等しいと判断した方がよさそうですね。

因みになんですが、maru様も試されたみたいですが、
拡張DLLでAfxGetApp()の使用は、どうなんでしょうか？
本来あってはならないもの、それとも結果OKのもの？？

今後、DLLを作成する場合のノウハウとして。

> 拡張DLLでAfxGetApp()の使用は、どうなんでしょうか？
> 本来あってはならないもの、それとも結果OKのもの？？

EXE と DLL の MFCのバージョンが同じなら当然あり。
違うなら当然あってはならない。

だと思う。

http://msdn.microsoft.com/ja-jp/library/h5f7ck28.aspx
より

クライアント アプリケーションおよび拡張 DLL の両方で、同じバージョンの
MFCx0.dll を使用する必要があります。

> 拡張DLLでAfxGetApp()の使用は、どうなんでしょうか？
> 本来あってはならないもの、それとも結果OKのもの？？
以下に全ての回答がありました。
http://msdn.microsoft.com/ja-jp/library/h5f7ck28(v=VS.80).aspx
「拡張 DLL では、CWinApp の派生クラスをインスタンス化はしないでください。その代
わりに、このオブジェクトの提供をクライアント アプリケーション (または DLL) に依
存します。」
つまり拡張DLLは正しい方法、それ以外ではNG。

また、MFCのバージョンの話も
「クライアント アプリケーションおよび拡張 DLL の両方で、同じバージョンの
MFCx0.dll を使用する必要があります。」
とあります。

ありゃ、かぶっちゃいましたね。

ちょっと修正。
> つまり拡張DLLは正しい方法、それ以外ではNG。
つまり拡張DLL「で」は正しい方法、それ以外ではNG。

> つまり拡張DLL「で」は正しい方法、それ以外ではNG

なるほど。わかりました。
ありがとうございます。

VCのバージョンアップの度にこのような問題がでてくるのであれば
拡張DLLを使用しない方がよさそうですね。
勉強になりました。

私の場合は、MFCの拡張DLLは、１つのソリューション(ワークスペース)にEXEとDLL
双方のプロジェクトを含める場合にだけ使うようにしています。

常に同時にビルドがかかる状態なら、バージョンの不一致問題は起きないわけで、
そうなるとデメリットよりメリットが勝るからです(^-^)