VS2005 SP1のC++のランタイムライブラリについて

Question

初めまして。いつも参考にさせて頂いています。

 

VisualStudio2005を使用して、C++とVBのプログラムを作成しています。

環境は以下のようになっています。

開発PC：WindowsXP,VS2005

実行PC：WindowsServer2003,Framework2.0

 

先日、開発PCのVS2005にSP1を充てたところ、実行PCでC++のプログラムを実行すると、

「アプリケーションの構成が正しくありません・・・」といったエラーが発生するようになりました。

（実行PCにはDLLファイルのみ配置し、VBで作成した画面から実行しています）

 

このエラーについて調べてみたところ、VS2005SP1ではC++のランタイムが更新されているとのことで、

実行PCに.NET Framework2.0のSP1をインストールしました。

すると上記エラーは解消されたと思ったのですが、他のプログラムで再発してしまいました。

 

再度いろいろと調べてみたところ、「ランタイムのデバッグ版は再配布不可」という記述を見つけました。

エラーが再発したプログラムはDebugモードでビルドしており、

Releaseモードでリビルドし直すと、エラーは解消されました。

SP1を充てる前に、Debugモードでビルドしたプログラムは、実行PCでも正常に動きました。

 

ここまでのことから、以下のように整理しました。

・Framework2.0のSP1には、VS2005SP1のC++のデバッグランタイムは含まれていない

・Framework2.0には、VS2005のC++デバッグランタイムも含まれている

 

この認識に、間違いはありませんでしょうか？

この件についてご存知の方がいらっしゃれば、訂正や助言を頂ければと思います。

よろしくお願い致します。

Answer 1

KTR_66 さんからの引用

ここまでのことから、以下のように整理しました。 ・Framework2.0のSP1には、VS2005SP1のC++のデバッグランタイムは含まれていない ・Framework2.0には、VS2005のC++デバッグランタイムも含まれている   この認識に、間違いはありませんでしょうか？

Visual C++のランタイムは.NET Frameworkとは切り離して考えて下さい。

 

.NET Framework 2.0、.NET Framework 2.0 SP1にはVisual C++のデバッグランタイム、リリースランタイム共に含まれていないはずです。

（含まれているということであれば突っ込んで下さい）

 

 

ところで、実行PCにはSP1の当たっていないVisual Studio 2005が入っているのですか？

だとすれば試行結果に納得がいくのですが…。

Answer 2

Azuleanさん、ご返信ありがとうございます。

 

Azulean さんからの引用

ところで、実行PCにはSP1の当たっていないVisual Studio 2005が入っているのですか？ だとすれば試行結果に納得がいくのですが…。

 

実行PCには、VisualStudio2005は入っていません。

実行PCはサーバになる予定の端末で、開発環境は持たせていません。

（実行PCの環境として、VBで作成した画面を実行するためにIISが入っていますが、

今回はVBは関係ないと思いましたので、質問時には省略させて頂いています）

 

VisualStudioが入っていないPCで、VisualStudioで作成したプログラムを実行するために

必要なランタイムが、Frameworkに含まれているものとばかり思っていました。

 

そもそも根本的な思い違いでしょうか？

現在のところ、問題は解決したように思っていますが、

原因は何だったのかと、本当に問題は解決されたのかを、はっきりさせたいと思いまして…

 

引き続き、ご教授頂ければと思います。

よろしくお願い致します。

Answer 3

KTR_66 さんからの引用

VisualStudioが入っていないPCで、VisualStudioで作成したプログラムを実行するために 必要なランタイムが、Frameworkに含まれているものとばかり思っていました。

VBやC#で作ったアプリに対しては（大抵の場合は）.NET Frameworkだけで十分です。

VC++で作ったアプリ、DLLは必ずVisual C++のランタイムが必要です。（2005の場合、CLR pureでもマニフェストで要求している）

 

.NET FrameworkとVisual Studioが一体的に見えてしまいますが、両者は異なるものです。

.NET Frameworkを使ったアプリケーションをVisual Studioで作れるということであり、Visual Studioで作ったアプリ全てが.NET Frameworkを必要とするわけでもありませんし、.NET Frameworkだけで十分とは言えません。

 

KTR_66 さんからの引用

現在のところ、問題は解決したように思っていますが、 原因は何だったのかと、本当に問題は解決されたのかを、はっきりさせたいと思いまして…

プロジェクトの設定が何か違っていた、ソース管理に問題があった、ビルド手順を間違えていたとかですね。

現状では明確にこれだと絞りきれません。

Answer 4

Azulean さんからの引用

.NET Framework 2.0、.NET Framework 2.0 SP1にはVisual C++のデバッグランタイム、リリースランタイム共に含まれていないはずです。 （含まれているということであれば突っ込んで下さい）

 

真偽のほどは確認しておりませんが，リテール版の MSVCRT が含まれていた時期もあれば，そうでない時期もあるという話が載っていますね．

http://konuma.txt-nifty.com/blog/2006/02/msvcr80net_fram_e4c9.html

 

実験で確かめる場合は，インストール時期にも注意という感じでしょうか．

Answer 5

NyaRuRu さんからの引用

真偽のほどは確認しておりませんが，リテール版の MSVCRT が含まれていた時期もあれば，そうでない時期もあるという話が載っていますね． http://konuma.txt-nifty.com/blog/2006/02/msvcr80net_fram_e4c9.html

情報ありがとうございます。

これが真実だとすれば、Releaseでビルドしていれば問題なく動く理由に見えます。

 

あとは、以前のSP当てる前とSP当てた後のビルド方法・設定に差異があるかどうかかな…。

前と後の両方のバイナリが手元にあるのであれば、Depedency Walkerで見てみると、msvcm80.dll、msvcr80.dll、msvcp80.dllあたりに依存しているかどうかで見ることもできるかと思います。

（リソースを開いて、マニフェストファイルを見るというのも手です）

 

両方とも依存しているのであれば、SP当てる前のはたまたまランタイムが入っていて問題がなかったということになるかと思います。

逆にSP当てた後のビルドのみ依存しているのであれば、プロジェクトのプロパティがそのときと変化している可能性も残ります。

Answer 6

NyaRuRuさん、ご返信ありがとうございます。

 

NyaRuRu さんからの引用

真偽のほどは確認しておりませんが，リテール版の MSVCRT が含まれていた時期もあれば，そうでない時期もあるという話が載っていますね． http://konuma.txt-nifty.com/blog/2006/02/msvcr80net_fram_e4c9.html   実験で確かめる場合は，インストール時期にも注意という感じでしょうか．

 

実行PCに.NET Framework2.0をインストールしたのは私ではないのですが、

少なくとも今年に入ってからのことです。

紹介して頂いたページを見ると、2007年の記事のようなので、

実行PCにインストールされているFramework2.0は、既にC++ランタイムは含まれてないものと考えられるでしょうか？

 

ただ、.NET Framework2.0は、いつ頃入手したものかは把握していません。

これが、.NET Framework2.0にC++のランタイムが同梱されていた時期のものを使用していた場合、

Visual C++ 2005の頒布可能可能パッケージをインストールしていなくても、

開発PCにSP1を充てる前のプログラムが、実行PCで動いているという理由になるのでしょうか。

 

インストールに使用した.NET Framework Version 2.0のパッケージが

どこから入手したものなのか、すごく気になってきました・・・

もしかすると、昔DLされたものを社内で共有的に保存してあり、それを利用しているのかもしれません。

 

明日、確認してみて、ご報告致します。

Answer 7

Azuleanさん、ご返信ありがとうございます。

 

Azulean さんからの引用

.NET FrameworkとVisual Studioが一体的に見えてしまいますが、両者は異なるものです。 .NET Frameworkを使ったアプリケーションをVisual Studioで作れるということであり、Visual Studioで作ったアプリ全てが.NET Frameworkを必要とするわけでもありませんし、.NET Frameworkだけで十分とは言えません。

 

なるほど・・・！　C++のランタイムが、どういう位置付けにいるのか理解できました。

.NET Frameworkについての基礎知識が浅かったようで、大変お恥ずかしいです。

 

Azulean さんからの引用

あとは、以前のSP当てる前とSP当てた後のビルド方法・設定に差異があるかどうかかな…。 前と後の両方のバイナリが手元にあるのであれば、Depedency Walkerで見てみると、msvcm80.dll、msvcr80.dll、msvcp80.dllあたりに依存しているかどうかで見ることもできるかと思います。

 

バイナリファイルを比較する、という方法は知らなかったので試していませんが、

SPを充てる前と後の.vcprojファイルを比較してみたところ、全く同じものでした。

.vcprojを比較するだけでは、ビルド方法・設定の差異は確認できないのでしょうか？

 

それらの設定が同じだったとして、

実行PCにはVisual C++ 2005 SP1 再頒布可能パッケージ はインストールしていません。

.NET Framework2.0のSP1をインストールしたのも最近のことなので、

NyaRuRu さんがおっしゃっている、MSVCRT が含まれているパッケージだということも考えにくいとなると、

実行PCの中で何が起こっているのか、気になって連休どころじゃありませんでした・・・

 

明日、実行PCの環境を再度確認してみます。

バイナリファイルを比較する、という方法も試してみたいと思います。

Answer 8

KTR_66 さんからの引用

バイナリファイルを比較する、という方法は知らなかったので試していませんが、 SPを充てる前と後の.vcprojファイルを比較してみたところ、全く同じものでした。 .vcprojを比較するだけでは、ビルド方法・設定の差異は確認できないのでしょうか？

いえ、それで十分そうです。

 

KTR_66 さんからの引用

明日、実行PCの環境を再度確認してみます。 バイナリファイルを比較する、という方法も試してみたいと思います。

プログラムの追加と削除で入れた覚えのないランタイムが入っているとか、C:\Windows\WinSxSフォルダに下記のフォルダがあるようであれば、どのタイミングかは分かりませんが、インストールされていることになります。

 

x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700