none
マニフェストファイルの手動生成方法について RRS feed

  • 質問

  • 開発環境:Windows XP (SP3) / Visual C++ 2005 Professional

    現在、Windowsアプリケーションを作成しています。

    マニフェストファイルを以下の手順で作成し、埋め込みマニフェストとしてビルド実行していますが、
    ビルド時の動作が不安定となっています。

    (ビルド実行した際に、マニフェストファイルを埋め込んでくれるときと、埋め込んでくれないときがあります。
    Release、Debugどちらも)

    正しいマニフェストファイルの手動作成方法をご存じのかたがいらっしゃいましたら、ご教示いただきたく
    お願い申し上げます。


    <<現在のマニフェストファイル手動作成手順>> 
    ※ 仮にプロジェクト名"ABC"として記載します

    01) まず、既定のマニフェストファイル自動生成にて、Releaseビルドを実行
    02) ABC\ABC\Releaseディレクトリに生成されたマニフェストファイルをコピー
    03) ABC\ABCディレクトリにペースト
    04) ペーストしたマニフェストファイルを、テキストエディタで開いて編集(バージョンなど変更し、Unicode(UTF-8)にて上書き保存)
    05) 04)にて編集したマニフェストファイル名を、"ABC.exe.manifest"に変更
    06) [プロジェクトのプロパティ]-[構成プロパティ]-[リンカ]-[マニフェストファイル]-[マニフェストの生成]項目を"いいえ"に変更
    07) [プロジェクトのプロパティ]-[構成プロパティ]-[マニフェストツール]-[入力と出力]-[追加のマニフェスト ファイル]項目を
          "$(ProjectDir)$(TargetFileName).manifest"に変更
    08) [プロジェクトのプロパティ]-[構成プロパティ]-[マニフェストツール]-[入力と出力]-[埋め込みマニフェスト]項目を"いいえ"に変更
    09) Releaseビルドを実行
    10) ビルド正常完了後、ABC\Releaseディレクトリに作成されたマニフェストファイルをテキストエディタで開いて、編集内容が
          反映されていることを確認
    11) 10)にて確認したマニフェストファイルを一旦削除
    12) [プロジェクトのプロパティ]-[構成プロパティ]-[マニフェストツール]-[入力と出力]-[埋め込みマニフェスト]項目を"はい"に変更
    13) Releaseビルドを実行
    14) ビルド正常完了
    15) 作成したモジュール正常起動確認

    2009年9月19日 14:56

回答

  • マクロでリンクするDLLバージョンを切り替えるのはVisual Studio 2005からの機能なんですけどね。こっちかな、_USE_RTM_VERSION
    Visual Studio 2008でマクロ名が変更されて細かく指定できるようになっていますが、本質的には変わりないかと。
    とはいえ2005と2008とでデフォルトが逆なのかぁ…。

    あと、この問題なのか、全く別の問題なのかは分かりませんね。
    • 回答としてマーク nawaji 2009年10月5日 3:09
    2009年9月20日 0:11
  • マクロでリンクするDLLバージョンを切り替えるのはVisual Studio 2005からの機能なんですけどね。こっちかな、_USE_RTM_VERSION

    なるほど、別名のマクロであったのですね。
    確認不十分な状態で「ありませんでした」と断言して申し訳ありません。

    とはいえ2005と2008とでデフォルトが逆なのかぁ…。

    個人的には、「古いバージョンでも良い」とする挙動は危ういと思っています。
    知らずに SP で加えられた新しい機能に依存したコードを書いていたり、SP で不具合が修正された状態を前提にしたコードを書いていたりすると、なぜかユーザ環境ではエラーが出るといったこともあり得ますので…。
    他にも、Visual C++ 2008 SP1 の MFC Feature Pack を利用しているアプリケーションで マクロ を定義しなかった場合、「関数が見つからない」といった実行時エラーになりますが、まだ、「構成が正しくない」というサイドバイサイドのエラーになった方がましではないかと思えます。(どちらもユーザから見ると分かりづらい点は変わらないかもしれません)


    これらの古いバージョンでも良いとするのは、開発者が十分に検討した上で設定するべきであって、デフォルト動作は混乱を招くだけのような気もするなぁ。


    解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。
    • 回答としてマーク nawaji 2009年10月5日 3:09
    2009年9月20日 8:22
    モデレータ

すべての返信

  • マニフェストファイルを以下の手順で作成し、埋め込みマニフェストとしてビルド実行していますが、
    ビルド時の動作が不安定となっています。

    (ビルド実行した際に、マニフェストファイルを埋め込んでくれるときと、埋め込んでくれないときがあります。
    Release、Debugどちらも)
    「埋め込んでくれるとき」と「埋め込んでくれないとき」の差は何か分かる範囲で何かあるのでしょうか?あるいはどこまで確かめてあるのでしょうか?
    Debug/Releaseの構成の設定を見比べて問題がなかったとか、ある操作手順を踏むと起きる・起きないが変化するとか、プロジェクトファイルによって起きる・起きないの差があるとか。

    「不安定」という言葉で片付けず、何か材料がないかを探ってみて下さい。
    解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。
    2009年9月19日 16:01
    モデレータ
  • 「埋め込んでくれるとき」と「埋め込んでくれないとき」の差は何か分かる範囲で何かあるのでしょうか?あるいはどこまで確かめてあるのでしょうか?
    Debug/Releaseの構成の設定を見比べて問題がなかったとか、ある操作手順を踏むと起きる・起きないが変化するとか、プロジェクトファイルによって起きる・起きないの差があるとか。

    Azulean 様

    ご連絡ありがとうございます。
    「埋め込まれたとき」と「埋め込まれていないとき」の差は、以下のように確認しています。

    「埋め込まれたとき」
    1) ビルド実行(Release、Debugともに)
    2) 「ビルド正常完了」のメッセージを確認
    3) ビルドログを確認し、「マニフェストを埋め込んでいます...」または、「マニフェストを作成しています...」というメッセージが
      記載されていることを確認
    4) 作成したモジュールを実行して正常に起動することを確認

    「埋め込まれていないとき」
    1) ビルド実行(Release、Debugともに)
    2) 「ビルド正常完了」のメッセージを確認
    3) ビルドログを確認し、「マニフェストを埋め込んでいます...」または、「マニフェストを作成しています...」というメッセージが
      記載されていないことを確認
    4) 作成したモジュールを実行して起動に失敗することを確認
    5) モジュールと同じフォルダに、マニフェストファイルを配置(コピペ)してみる
    6)  作成したモジュールを実行して起動することを確認


    また、「埋め込まれていないとき」のような状態になった際、以下の手順を行うことにより再度マニフェストファイルを埋め込むことが
    できます。

    1) [プロジェクトのプロパティ]-[構成プロパティ]-[リンカ]-[マニフェストファイル]-[マニフェストの生成]項目を"はい"から"いいえ"に変更
    2) [適用]ボタンを押す
    3) [プロジェクトのプロパティ]-[構成プロパティ]-[リンカ]-[マニフェストファイル]-[マニフェストの生成]項目を"いいえ"から"はい"に変更


    ただ、他のプロジェクトでテストを行っていませんでしたので、実施してみて結果を書き込みさせていただきます。
    2009年9月19日 16:33
  • Azuleanさんもコメントしていますが、確認が足りていません。
    出力ウィンドウとBuildLog.htmに実行したコマンドは全て書かれています。各コマンドが期待する引数で呼ばれているか、ログを見れば分かる話です。

    質問に対する回答ですが、
    07)の「追加の マニフェスト ファイル」というところからも分かると思いますが、複数のマニフェストファイルをマージしてから埋め込むことができます。
    06)の「マニフェストの生成」「いいえ」は不要かと。
    深く考えずにのコメントですが、ビルドの設定を変にいじるから途中で依存関係が狂ってマニフェストを更新しなくなったりするのでは?
    2009年9月19日 16:41
  • 06)の「マニフェストの生成」「いいえ」は不要かと。
    深く考えずにのコメントですが、ビルドの設定を変にいじるから途中で依存関係が狂ってマニフェストを更新しなくなったりするのでは?

    佐祐理 様
    ご連絡ありがとうございます。

    「マニフェストの生成」を"はい"および、追加のマニフェストを指定してビルドすると、どちらも(自動で生成されるマニフェストファイルと、
    追加のマニフェストファイル)埋め込んでしまうようでしたので、"いいえ"にしておりました。

    今回は、マニフェスト内に指定しなければならないファイルのバージョンを、自動生成されるものとは別のバージョンに指定したかったため、
    手動生成したものに置き換えるという手段を試みました。
    2009年9月19日 17:13
  • 今回は、マニフェスト内に指定しなければならないファイルのバージョンを、自動生成されるものとは別のバージョンに指定したかったため、
    手動生成したものに置き換えるという手段を試みました。
    時間の都合でもう1件の投稿については見れていませんが、こちらの部分だけ取り急ぎで書きます。

    「自動生成されるものとは別のバージョンに指定」とありますが、これはどのような理由からでしょうか?
    また、「指定しなければならないファイルのバージョン」とは、Microsoft.VC80.CRT, Microsoft.VC80.MFC, Microsoft.VC80.ATL のことでしょうか?
    解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。
    2009年9月19日 23:01
    モデレータ
  • 最初から触れられていた「バージョン書き換え」ってその可能性がありますね。

    AuleanさんがあげられているようなDLLをリンクする際に特定のバージョンを指定するためには、アプリケーションの再配布と特定のライブラリへのバインド を使います。
    これはマニフェスト全般の話題ではなくなります。
    2009年9月19日 23:42
  • AuleanさんがあげられているようなDLLをリンクする際に特定のバージョンを指定するためには、アプリケーションの再配布と特定のライブラリへのバインド を使います。
    これはマニフェスト全般の話題ではなくなります。
    これは Visual C++ 2008 での機能です。
    Visual C++ 2005 にはありませんでした。

    解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。
    2009年9月20日 0:02
    モデレータ
  • マクロでリンクするDLLバージョンを切り替えるのはVisual Studio 2005からの機能なんですけどね。こっちかな、_USE_RTM_VERSION
    Visual Studio 2008でマクロ名が変更されて細かく指定できるようになっていますが、本質的には変わりないかと。
    とはいえ2005と2008とでデフォルトが逆なのかぁ…。

    あと、この問題なのか、全く別の問題なのかは分かりませんね。
    • 回答としてマーク nawaji 2009年10月5日 3:09
    2009年9月20日 0:11
  • マクロでリンクするDLLバージョンを切り替えるのはVisual Studio 2005からの機能なんですけどね。こっちかな、_USE_RTM_VERSION

    なるほど、別名のマクロであったのですね。
    確認不十分な状態で「ありませんでした」と断言して申し訳ありません。

    とはいえ2005と2008とでデフォルトが逆なのかぁ…。

    個人的には、「古いバージョンでも良い」とする挙動は危ういと思っています。
    知らずに SP で加えられた新しい機能に依存したコードを書いていたり、SP で不具合が修正された状態を前提にしたコードを書いていたりすると、なぜかユーザ環境ではエラーが出るといったこともあり得ますので…。
    他にも、Visual C++ 2008 SP1 の MFC Feature Pack を利用しているアプリケーションで マクロ を定義しなかった場合、「関数が見つからない」といった実行時エラーになりますが、まだ、「構成が正しくない」というサイドバイサイドのエラーになった方がましではないかと思えます。(どちらもユーザから見ると分かりづらい点は変わらないかもしれません)


    これらの古いバージョンでも良いとするのは、開発者が十分に検討した上で設定するべきであって、デフォルト動作は混乱を招くだけのような気もするなぁ。


    解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。
    • 回答としてマーク nawaji 2009年10月5日 3:09
    2009年9月20日 8:22
    モデレータ
  • 佐祐理 様
    ご連絡ありがとうございます。

    _USE_RTM_VERSION の指定方法に関しまして、MSDN記事を拝見させていただきました。

    Visual Studio 2005(SP1)の環境が手元になかったため、テスト実施できておりませんでしたが、
    これから、テストを実施する予定です。

    貴重な、情報をありがとうございました。
    2009年10月5日 3:15
  • Azulean様

    ご連絡ありがとうございます。

    貴重なご意見を、ありがとうございます。

    今回、古いバージョンのDLLファイル(自動生成されるものとは別のバージョン)を使用するように指定する理由は、
    Visual Studio 2005 (SP1)にて開発されたアプリケーションを、開発環境の無いクライアント上へ配置(コピペ)
    して実行させようとした際、実行エラーとなったからです。

    クライアントには、必要な「Visual C++ 2005 SP1 再頒布可能パッケージ」や「.NET Framework 2.0」以上は
    既にインストールしてある状態です。(Webサイトからダウンロードしたもの)

    実行エラーについて調べてみたところ、推測ですが「Visual C++ 2005 SP1 再頒布可能パッケージ」をインストー
    ルした際に作成されるDLLファイルと、開発環境で使用しているDLLファイルのバージョンが違うことが関係している
    のではないかと考えました。

    _USE_RTM_VERSION 指定について、これからテスト実施する予定です。

    2009年10月5日 10:44