4

私は完全に理解していないことをしようとしているので、ここでいくつかの心を読む必要があります.

外部アクセス用の COM API を提供する 32 ビット アプリケーション (CQG と呼ばれる電子取引アプリケーション) があります。Excel、.NET (C++、VB、C#)、およびシェル VBScript からこの API にアクセスするサンプル プログラムとスクリプトがあります。これらの .NET アプリケーションは、ソース コードとコンパイル済みの実行可能ファイル (32 ビット、Windows XP でコンパイル) として持っています。

現在、Windows Vista Home 64 ビットを使用しているため、頭が回転します。Excel の例は問題なく動作します (Excel 2003)。コンパイルされた .NET サンプル実行可能ファイルも同様に機能します。

しかし、Visual Studio C# 式に変換してコンパイルした .NET C# サンプルを実行しようとしたり、VBScript スクリプトを実行しようとすると、オブジェクトを作成しようとするとエラー 80004005 が発生します。最初は .NET アプリケーションでも 80040154 が返されましたが、64 ビットではなく 32 ビット コードを生成する方法を見つけたので、C# アプリケーションと VBScript アプリケーションのエラーは同じになりました。それが今のところ私が得たすべての進歩です。

はい、VBS の SysWOW64 フォルダーから 32 ビット バージョンの cscript.exe/WScript を実行しようとしましたが、結果は同じです (80004005)。

この問題を解決するには?私はそれが事実上不可能であると信じる準備がほとんどできていますが、Excel VBA が動作し、Windows XP でコンパイルされた .NET 実行可能ファイルが正常に動作するという事実は、私を怒らせるだけです. これを打ち負かす方法があるはずです (おそらく Windows Vista の開発者だけが知っている秘密です)。どんな助けにも感謝します!

PS: コード サンプルはここではあまり意味がないと思いますが、失敗する VBScript の行は次のとおりです。

Set CEL = WScript.CreateObject("CQG.CQGCEL.4.0", "CEL_")

そして、これはC#です:

CQGCEL CEL = new CQGCEL();

更新:もちろん、 UACがオフになっていることを忘れていました。そして、私は管理者権限を持つアカウントから作業しています。

また、Process Monitor を使用してどのレジストリ キーが読み取られるかを監視しようとしましたが、このオブジェクトの GUID についてはすべて問題ないように見えます。他のいくつかの GUID を認識できなかったので、それらが重要かどうかはわかりません。

この COM オブジェクトが Internet Explorer を使用し、間違ったもの (Internet Explorer 6 エンジンの代わりに Internet Explorer 7 など) を取得する可能性はありますか?

4

3 に答える 3

2

64 ビット マシンについて覚えておく必要があることがいくつかあります。これらは、過去に私を捕まえたいくつかのことです。

  1. .NETで任意の CPU 用に構築するということは、64 ビット マシン上で 64 ビットとして実行されることを意味します。
  2. 多くの COM コンポーネントは 32 ビットのみのようです (これが一般化されていることはわかっていますが、多くの場合そうです)。それらを使用するには、アプリケーションを 32 ビット (x86) としてビルドする必要があります。
  3. 64 ビット Windows には、異なる 32 ビットと 64 ビットのレジストリ ノードがあります。たとえば、regedit を 64 ビットとして実行すると、HKLM\Software\Wow6432Node と HKCU\Software\Wow6432Node が表示されます。これには、32 ビット アプリケーションのすべての情報が含まれています。

私の提案は、32 ビット アプリケーションとしてビルドし、何が起こるかを確認することです。

于 2008-12-29T07:12:43.013 に答える
1

問題はおそらく DEP です。

私はあなたとまったく同じ問題を抱えていて、CQG の技術サポートから助けを得ました。データ実行防止は、Windows Vista および Windows 7 でデフォルトで有効になっています。コマンドプロンプトで管理者権限を使用してオフにすることができます

bcdedit.exe /set {current} nx AlwaysOff

必要に応じて、後でオンに戻すことができます

bcdedit.exe /set {current} nx AlwaysOn

再起動は求められませんが、必要です。を使用してDEPポリシーを確認できます

wmic OS Get DataExecutionPrevention_SupportPolicy

ここで、 0is Always off1is Always On2is Opt in(およびデフォルト値)、および3isOpt Outです。

Always Off に変更して再起動した後、80004005 エラーをスローすることなくコンパイルできました。

于 2010-08-20T02:14:14.123 に答える
0

あなたが試すことができるいくつかの便利なこと:

  1. 失敗したプロセスにフィルターされた出力でプロセスモニターを実行します。奇妙なエラーが報告されているかどうかを確認します。

  2. 同様に、アンマネージデバッガーで実行して、他のファーストチャンス例外がスローされるかどうかを確認してください。これにより、inprocCOMdllがプロセスにロードされているかどうかを確認することもできます。

  3. UACをオフにして、何が起こるかを確認してみてください。

于 2008-12-29T02:21:58.017 に答える