C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[9]: manifestのprocessorArchitecture

(過去ログ 80 を表示中)

[トピック内 12 記事 (1 - 12 表示)]　 << 0 >>

■47628 / inTopicNo.1)

　manifestのprocessorArchitecture

▼■

□投稿者/ 桂格子 (1回)-(2010/03/10(Wed) 07:50:58)

分類:[C/C++]　

OS：Windows XP Professional x64 Edition
開発環境：Visual Studio 2008
使用言語：C++

64ビットアプリケーションを開発しています。

ビルドは正常に終了しますが、起動すると

「アプリケーション構成が正しくないため、このアプリケーションの開始に失敗しました。マニフェストファイルを参照してエラーの原因を調べてください。」

とエラーになります。

exeファイルをIDE下で開いてRT_MANIFESTのフォルダに含まれるファイルの中身で

processorArchitecture="X86"

を毎回"X86"を"AMD64"に書き換えて実行しています。

ソリューションプラットフォーム：x64
プロパティのリンカの詳細の対象コンピュータ：MachineX64

を設定しており、"X86"でexeファイルが生成されることに少し腹立たしい思いです。

"AMD64"で生成されるために、他に設定すべきこと、または、X86となる設定があるので
削除すべきことなど、毎回、手で書き換えなくて済む解決法をご存知の方、お教えください。

引用返信 編集キー/

■47630 / inTopicNo.2)

　Re[1]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 中博俊 (1369回)-(2010/03/10(Wed) 10:09:15)

自動生成ではx86しか想定していないっていうことだと思うので、自分でつくってMTじゃだめなんですかねぇ。

引用返信 編集キー/

■47632 / inTopicNo.3)

　Re[2]: manifestのprocessorArchitecture

▲▼■

□投稿者/ とっちゃん (484回)-(2010/03/10(Wed) 10:45:56)

■No47630 (中博俊さん) に返信
> 自動生成ではx86しか想定していないっていうことだと思うので、自分でつくってMTじゃだめなんですかねぇ。
>
>
ん？自動生成していないだと思いますよ。
assemblyIdentity ですよね？

VS2002や2003のころならともかく、2005以降は、自分で manifest 書いたりしないのが通常です。
comctl32.dll も一度テンプレ変わりにMFCプロジェクトとか吐き出すと設定用のものを用意してくれます(UNICODEオンリー)。

というか。。。VS2005/2008は正しいマニフェストを入れてあげないとそもそもCRTをDLLで使えないので
手動なんてやってたら誰も使ってくれない。。。以前に、VC作ってるメンバーがキレますｗｗｗ

引用返信 編集キー/

■47641 / inTopicNo.4)

　Re[2]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 桂格子 (2回)-(2010/03/10(Wed) 13:32:17)

■No47630 (中博俊さん) に返信
> 自動生成ではx86しか想定していないっていうことだと思うので、自分でつくってMTじゃだめなんですかねぇ。
>

中博俊さん、ビルドの度に毎回手で入力するのを回避する方法を示していただきありがとうございます。

MT.exe で"AMD64"に書き換え後のexeファイルからmanifest部分を別ファイルに抜き出して、そのファイルをビルドの後、
MT.exe でexeファイルに戻すことで確かに毎回手で入力するのを回避できます。

M社の製品は不親切というか、気が利かないというか、という私の印象ですが、"AMD64"が自動生成されないほど、ボロクソ
ではないと思いますのでビルドだけで、"AMD64"が自動生成される解決法を待ってみたいと思います。

引用返信 編集キー/

■47642 / inTopicNo.5)

　Re[3]: manifestのprocessorArchitecture

▲▼■

□投稿者/ とっちゃん (485回)-(2010/03/10(Wed) 14:01:20)

■No47641 (桂格子さん) に返信

んと。。。VS2008で新規に作ったプロジェクトを利用しているのでしょうか？
プロジェクトの形式がわからないので、たまたま手元で動かしていた
x86用の使い捨てツールのプロジェクトにx64用も追加してビルドしてみましたが
なにも変更せずにビルドできましたよ？

なにか手順の問題か、別の理由でx64構成が正しく作れていないのではないでしょうか？

■No47632 でもそれとなく書いていますが、VS2005/2008 のCRT(MSVCR90.DLLやMSVCP90.DLLなど)は
Win32 Side by Side の仕組みにより、そのままではロードできないパス上に存在しています。

そのため、これを利用できるようにするため、正しいマニフェスト設定を行わなければならないのは
コンパイラにとっては絶対に避けられない課題の一つです。

ですので、自動で設定できないとするのであれば、その設定手順のどこかに自動設定するなにかを
阻害するものがあると思われます。

どこに問題があるのかはわかりませんが、同じプロジェクト形式(テンプレートのままでいい)で
新規に作成してみて、構成マネージャからx64を追加したらどうなるか？を確認してみてください。

引用返信 編集キー/

■47659 / inTopicNo.6)

　Re[4]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 桂格子 (3回)-(2010/03/10(Wed) 18:52:28)

■No47642 (とっちゃんさん) に返信

新規にMFC、CLRでプロジェクトを作成し、ソリューションプラットフォームをWin32からx64に変更してビルドした結果、exe内部に含まれる
manifestのprocessorArchitecture(以下、PAと省略)が"AMD64"で生成されました。

そこで問題のmanifestの全体をじっくり眺めてみると

アプリケーションのexeに対するPAは、"X86"
"Microsoft.Windows.Common-Controls"に対するPAは、"X86"
"Microsoft.VC90.DebugCRT"に対するPAは、"AMD64"
"Microsoft.VC90.DebugMFC"に対するPAは、"AMD64"

となっており、"Microsoft.Windows.Common-Controls"に対して、PA、version、publicKeyTokenをAMD64のデータに正しく設定しても次回の
ビルドでX86に戻っており、アプリケーションのexeもこれに連動したものではないかと私としてはM社のバグを疑います。

M社に問い合わせるのも面倒ですし、プロパティ→構成プロパティ→ビルドイベント→ビルド後のイベントのコマンドラインにMT.exe　で
正しいmanifestをexeファイルに書き込めば、操作としてはビルドを走らせれば何もしないで起動をかけることができますので少し不本意ですが
「解決済み」にしたいと思います。

中博俊さん、とっちゃんさん、アドバイスどうもありがとうございました。

解決済み

引用返信 編集キー/

■47674 / inTopicNo.7)

　Re[5]: manifestのprocessorArchitecture

▲▼■

□投稿者/ Azulean (536回)-(2010/03/11(Thu) 00:20:13)

2010/03/11(Thu) 00:28:57 編集(投稿者)

■No47659 (桂格子さん) に返信
> となっており、"Microsoft.Windows.Common-Controls"に対して、PA、version、publicKeyTokenをAMD64のデータに正しく設定しても次回の
> ビルドでX86に戻っており、アプリケーションのexeもこれに連動したものではないかと私としてはM社のバグを疑います。

「バグを疑う」と終わらせず、もう少し情報を公開して頂けると、他の人も助かると思います。
このため、少し確認観点を書かせてください。

どこかに x86 限定の下記のような記述があるというオチはないですよね？（stdafx.h など）

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")

新規に作成されたプロジェクトで確認していただけると分かると思いますが、_M_IX86 やら、_M_IA64 やら、_M_X64 で分岐するようになっています。
これは想定通りに、amd64 の行がコンパイルされるようになっていますか？

また、exe 自体の PA と称されている assemblyIdentity はどのように設定しているのでしょうか？
再現試験をするために教えてください。

試しに、[構成プロパティ] - [マニフェストツール] - [全般] の [アセンブリ ID] に「TestApp, processorArchitecture=x86」と入れると、CRT の PA が amd64 でも、exe の PA は x86 になりましたが、これではないのですよね？
http://msdn.microsoft.com/ja-jp/library/ms173400.aspx

引用返信 編集キー/

■47675 / inTopicNo.8)

　Re[6]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 桂格子 (4回)-(2010/03/11(Thu) 08:26:18)

■No47674 (Azulean さん) に返信

プロジェクトのフォルダを検索対象の範囲として、*.h、*.cppに対して"Common-Controls"を検索しました。

stdafx.h だけでヒットし、内容は以下のとおりでした。

#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_IA64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='ia64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endif

明示的に
#define _UNICODE

は行っていません。プロジェクトの文字セットは「マルチバイト文字セットを使用する」を選択しています。

よって上記部分は実行されないと判断して上記部分全体を削除してビルドしたところ、現象は変わらず、
exeファイル内部のmanifestには
アプリケーションのPA：X86
Common-ControlsのPA：X86
で自動生成されます。

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")

だけを復活させてビルドしても現象は変わりませんでした。

私は既存の32ビットアプリケーションを64ビットにコンバージョンするのを担当していますのでコードの隅々まで頭に入っていません。
よってプロジェクトのフォルダを検索対象の範囲として、*.h、*.cppに対してキーワード検索を行うことしか思い付きません。その範囲で
調べて、Common-ControlsのPA：X86とする原因を見つけることはできませんでしたが、どこかに残骸＝原因があるのでしょう。

エラーチェックをどこまでやるか、きりがないと思いますが
ソリューションプラットフォーム：x64
とか
DebugCRTのPA：amd64、またはユーザーが書き換えたCommon-ControlsのPA：amd64

とか、あるのに対して、Common-ControlsのPA：X86と判断するのであれば、他の設定と矛盾するので何でCommon-ControlsのPA：X86と
判断するのかシステムメッセージを出力してほしいと思います。

引用返信 編集キー/

■47678 / inTopicNo.9)

　Re[7]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 桂格子 (5回)-(2010/03/11(Thu) 09:24:00)

■No47675 (桂格子さん) に返信

■No47675に追加です。

> #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
>
> だけを復活させてビルドしても現象は変わりませんでした。

上記は間違いで、よく見ると、Common-Controlsに関して、"X86"と"amd64"に関してそれぞれ<dependency>記述が生成されていました。

引用返信 編集キー/

■47686 / inTopicNo.10)

　Re[7]: manifestのprocessorArchitecture

▲▼■

□投稿者/ とっちゃん (486回)-(2010/03/11(Thu) 11:14:54)

■No47675 (桂格子さん) に返信

> 私は既存の32ビットアプリケーションを64ビットにコンバージョンするのを担当していますのでコードの隅々まで頭に入っていません。
> よってプロジェクトのフォルダを検索対象の範囲として、*.h、*.cppに対してキーワード検索を行うことしか思い付きません。その範囲で
> 調べて、Common-ControlsのPA：X86とする原因を見つけることはできませんでしたが、どこかに残骸＝原因があるのでしょう。
>
> エラーチェックをどこまでやるか、きりがないと思いますが
> ソリューションプラットフォーム：x64
> とか
> DebugCRTのPA：amd64、またはユーザーが書き換えたCommon-ControlsのPA：amd64
>
> とか、あるのに対して、Common-ControlsのPA：X86と判断するのであれば、他の設定と矛盾するので何でCommon-ControlsのPA：X86と
> 判断するのかシステムメッセージを出力してほしいと思います。

とりあえず。。。検索範囲ですが、そのプロジェクトが依存するシステムヘッダーおよび、社内モジュール類の
ヘッダーは確認しましたか？

それと、x86が含まれてしまうというモジュールの.rcおよび.rc2も。
VS2003までは、VC++においては、MTによる結合というのは非常に特殊だったため、通常のプロジェクト作成においては
リソースに直接マニフェストファイルを埋め込む形で用意されていました。

Vistaになって、manifest が拡張された際に、リソース直ではセットアップできなくなり(当時のリンカが対応していない)
以後 mt.exe を使って埋め込む形に切り替わっています。
実際、VCのビルド情報をすべて詳細に確認するとそのあたりがよくわかります(mtを呼び出しています)。

今回、おもに影響している部分が ComCtrl のマニフェストのようです。
ここが影響しているとすると、たいていの場合、もともとRT_MANIFESTに入れていたなどが原因ですが
ごくまれに、別のライブラリのヘッダーに固定で埋め込まれているなどがあります。

調査するのもお仕事だと思いますので、ポイントだけに絞り込んでますが。。。ある程度はキーワード入れたつもりなので
ちょっと気合入れて検索してみるとよいかと。。。

一応まとめておきますね。
もっとも引っかかりそうな影響部分としての検索範囲は。。。
1.NGモジュールのリソースに直接埋め込む形になっていないか？
2.VS提供のヘッダー以外で参照しているヘッダー(社内のライブラリや、サードパーティ製のものなど)に固定で入っていないか？
というあたりになるかと。

引用返信 編集キー/

■47696 / inTopicNo.11)

　Re[8]: manifestのprocessorArchitecture

▲▼■

□投稿者/ 桂格子 (6回)-(2010/03/11(Thu) 14:56:09)

■No47686 (とっちゃんさん) に返信

解決法が見つかりました。少しくどくなりますが順に書きます。

(1) すぐにmanifestを確認できるように「マニフェストツール」の「埋め込みマニフェスト」を「いいえ」に変更する。

(2) ファイル検索で本日に作成されたマニュフェストを確認する。
　　manifestとintermediate.manifestの２つあり、intermediate.manifestにはアプリケーションのexeとCommon-Controlsは含まれていない。
　　ビルドログのメッセージ出力の順序からコンパイル時にintermediate.manifestが作成され、リンク時にアプリケーションのexeとCommon-Controlsが
　　追加されたものと推測する。

(3) *.h、*.cpp、*.rc、*.rc2は見たので残るは*.sln、*.vcprojと考え、中身を見る。

(4) *.vcprojに次の怪しいコードを発見する。

<Tool
Name="VCManifestTool"
AdditionalManifestFiles="$(ProjectDir)\res\$(TargetFileName).manifest"
/>

(5) (4)のmanifestの中身を見るとアプリケーションのexeとCommon-Controlsがあり、"X86"であったので"amd64"に書き換える。

(6) ビルド後、起動すると正常に起動され、manifestの中身のprocessorArchitectureもすべて"amd64"になっていることを確認する。

*.vcprojの中身にはPlatform Name="x64"もあり、32ビットから64ビットにPlatformを変えたとき、願わくは、AdditionalManifestFilesを
自動的にシステムで書き換えてくれればと思いますが？

とにかく、MT.exeによる仮対策ではなく、本体策の方法が見つかりましたので「解決済み」としたいと思います。

皆様、いろいろとアドバイスをいただきましてありがとうございました。

解決済み

引用返信 編集キー/

■47712 / inTopicNo.12)

　Re[9]: manifestのprocessorArchitecture

▲▼■

□投稿者/ とっちゃん (487回)-(2010/03/11(Thu) 19:59:29)

2010/03/11(Thu) 20:10:24 編集(投稿者)
2010/03/11(Thu) 20:02:16 編集(投稿者)

■No47696 (桂格子さん) に返信

もう見てないかな？

状況が把握できるレベルまで情報が出てきたのでようやく状態が想像できるようになったところですが。。。
＃同時にあるべき解決策も見えました

> (1) すぐにmanifestを確認できるように「マニフェストツール」の「埋め込みマニフェスト」を「いいえ」に変更する。
>
この設定のあるページの一番上にある「追加のマニフェストファイル」が
> <Tool
> Name="VCManifestTool"
> AdditionalManifestFiles="$(ProjectDir)\res\$(TargetFileName).manifest"
> />
>
の項目になります。もう古いプロジェクトの設定情報は残っていないかもしれませんが、
可能であれば一度確認してみるとよいと思います。

さて本題。

この追加のマニフェストですが、これはデフォルトではセットされないはずです。
いくつかVS2008で新規作成したプロジェクトをもっていますがいずれもセットされていません。

ですので該当プロジェクトは古いVSからコンバートしてきたのではないか？と想定されます。
それがどのバージョンなのかかまではわかりませんが。。。

> *.vcprojの中身にはPlatform Name="x64"もあり、32ビットから64ビットにPlatformを変えたとき、願わくは、AdditionalManifestFilesを
> 自動的にシステムで書き換えてくれればと思いますが？
>
抜本的な対策方法ですが
1.追加のマニフェストに何が書かれているかをきちんと吟味する。
2.コンパイルすることで自動的に設定できる(あるいは、ソース上で指定できる)モノについてはそれを利用するように修正する
3.それでも残るものについてのみ、追加のマニフェストに記述する。
という形をとることになると思います。

もしかしたら、バッサリ消しちゃっても問題ないかもしれませんが
書かれているものがわかっても、消していいかどうかは正直わかりません。

マニフェスト設定は、Isolated Applications(Side by Side アセンブリ)の根幹をなす部分であり
(概念モデルは、.NET アセンブリと同じです。なにせあっちがパクッてるんでねｗ)
設定の有無をもってだけではないさまざまな要素が絡み合っています(この辺りは.NETのそれとは異なる)。

Win32 Assembly、Win32 Side by Side は、単純なものではないため、マニフェストにアセンブリ情報があるというだけでは成立しません。

基本的には、この情報があることで Isolated Application になることを可能とするという段階であり、
この後、インストール先とシステムに設定する部分を行って初めて Isolated Application になります。
単に動けばいいという次元とは全く違うところに答えがありますので、慎重を期する部分でもあることを覚えておいてください。＞ALL

実際はEXEをIsolatedにすることはほとんどないので、単にアセンブリ情報があるだけということのほうが多いですけどね。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -