そのDLLがMFCを使用していなければ問題ないような気がします。

MFC以外のランタイムライブラリもバージョンによって入れ替わりが
あったと思ったんですが、大丈夫でしょうか？
内部的な初期化なんかはそれぞれのライブラリ毎に行なうと思うので
それが問題になったりしませんかねぇ。

もし私なら全てを同じ環境で再ビルドして使うと思います。
ランタイム関係が一致していないと何か動作上の不具合があったときに
結局はそこを疑う事にもなりかねないので不安要素はなるべく避けますから。

どうしてもそれしか手が無いという話なら検討してみると思いますけれど。

回答ありがとうございます

＞+ さま
MFCを使っているモジュールもあります
MFCを使っているモジュールだけがあやしのであれば、MFCを使っているモジュールをビル
ドしなおすという判断もありますね

＞PATIOさま
すべてを再ビルドした場合には、すべてを評価しなおす必要があります
できれば、修正のないモジュールはビルドせずに、評価の必要はない
と、判断したいところなんです

ん～、すべてをビルドしなおしてテストもすべて行うしかないですかね
悩ましい・・・
このあたりの情報がマイクロソフトにないかを探しているのですが見当たりませんね

開発環境移行のときは大抵、問題になるんですが、
移行する以上はやるしかないのではと言うのが私の意見です。
そのための工数は正当であると言う話で。
会社として動作保障する以上はやらざる得ないですしね。

で、考え方としてはなるべくUNITテストなんかで単体テストを自動化しておいて
テストの工数を減らすとかするしかないかと思います。
結合テストに関しては結局の話、アプリケーション側のリビルドが入るわけだから
最低でも全ての結合テストから抜粋したテストはしなきゃならないだろうし、
理想を言えば、既に一回使った結合テスト手順書を再利用して全部テストする
と言う事になるかと思います。

状況を調べてみました
WinXPのsystem32ホルダにあるDLLを見るとVC++7.0でビルドされています
WinVistaのsystem32フォルダにあるDLLを見るとVC++8.0でビルドされています

これらのOSにマイクロソフト以外のソフトがどのバージョンでインストールされているか？
を調べてみたところ、7.0と8.0が混在しています

これは気にしなくていいてことなんですかね
それとも、VC6.0はまずいのかな

＞PATIOさま
最初からちゃんと構成管理ができていればいいのですが・・・もしかするとVC++6.0でビ
ルドされてソースコードが管理されておらず再ビルドできないものもあるかもしれません

MFC等のライブラリの利用がそれぞれのモジュールで完結していれば問題になる
ことは少ないと思います。
ただ、DLLで作ったMFCなクラスをEXEで使うとか、その逆などがある場合、ほぼ
確実にアウトですので、その場合開発環境を統一する必要があると思います。

いずれにしても、テストは必須でしょうけど。

オブジェクト、特にtemplateとか渡してるとまぁアウトでしょう。
そういう意味では、declspecとかも一般には無理っぽい。
そういうのを全部回避して、口を特定して…ともろもろ
「あらかじめ考慮されたDLLなら」いける目はあると思いますが…

リビルドしなくても結局結合で全部評価は必要、かなぁと。
それくらいなら統一した方が安全かもしれません。

> 現在、VC++6.0で作成してきたアプリケーションをVC++8.0に移行しようと思います
> ...
> 最初からちゃんと構成管理ができていればいいのですが・・・もしかするとVC++6.0で
ビ
> ルドされてソースコードが管理されておらず再ビルドできないものもあるかもしれま
せん

この部分が既に致命的なのでは？バージョン云々の前に。
ソースコードのない部分は作り直すしかないと思う。

仮にそのモジュールについて、リビルド無しでリンクテストを通ったとしても、
私は客先に納品したくない。実行時エラーが起きた時に原因も掴みにくいし、
変更もできないし。

私は探してませんが、バージョン間の動作についてマイクロソフトが
公式に保証するような情報はないと思う。
こういう場合に動作しないという情報が、マイクロソフトやユーザーから
山のように出るだけだと思うな。
その一部が、このスレで諸氏が指摘している点ね。

というわけで、あなたの作りたいものが製品ならば、
VC++8.0に統一して全モジュールのテスト。
社内や個人で使うだけで、動かなくなってもかまわないならば、
テスト無しで使い始めても良いと思う。

# わざわざ私に言われるまでもなく判ってるか。
# きっと納期や予算の都合で困ってるんだよね。
# 納品後のリスクを考えると、テストで手を抜かない方が良いよ。

みなさまご意見ありがとうございます

たいちうさまのおっしゃるとおり

>きっと納期や予算の都合で困ってるんだよね

です
製品の特性上、数百本程度の販売なので工数に見合う売り上げがあるかも判断しなければ
なりません
また、システム全体を考えると、ディスコンになったデバイスもあります
このデバイスに付属するDLLは当然VC++8.0ではビルドされていませんし、当社でビルドす
ることも不可能です

基本的に
「異なるバージョンのVCでビルドしたモジュールを組み合わせることにはリスクがある」
を前提に、構成管理を見直し、どこまでをリビルドするか（できるか）を考えてから、リ
ビルドし、基本的にテストは全範囲をおこないツールでメモリリーク等を調べて見ます

余計なお世話かもと思いますが、
VC++6.0でメンテし続けると言う選択肢もあるのではと思いました。
実際には古いシステムのメンテナンスのためにVC++6.0の環境を維持し続けている
会社も結構あるようですし、それもまた一つの回答かなと。
VC++2005にどうしても移行しなければならないわけがあるなら仕方ないと言えば、
仕方ないかもしれません。

ただ、かなりしんどい話になりそうですね。
うまく行く事を祈っています。

>VC++6.0でメンテし続けると言う選択肢

これについてはだいぶ議論しました
が、VC++6.0作成モジュールはVistaで動作保障がないということで今後もバージョンアッ
プがありそうなソフトはVC++8.0へ移行するという決定がなされました
開発者としてはこの決定はあまり幸せではないのですが、１つ幸せなこともありました
作成しているソフトのコアの演算部分のスピードアップがかねてからの過大だったのです
が、VC++8.0でビルドすることで3割ほど早くなります
これは大きな恩恵です

＞ただ、かなりしんどい話になりそうですね。
＞うまく行く事を祈っています。

ありがとうございます
やるべきことを整理してうまいこと乗り切りたいと思います