none
VS.NET2003で作成したATLプロジェクトの64bit環境動作について RRS feed

  • 質問

  • KEROBOTと申します。

     

    Visual Studio .NET 2003 Professional のVisual C++プロジェクトからATLプロジェクトを選択し、ファイルのプロパティの概要を設定、取得するプログラムを作成しました。

    開発環境となるWindows XP Professional SP2 32bit 環境 および、テスト環境となるWindows 2003 Server Standard Edition SP1 32bit 環境(実機+VirtualPC2004)では、以下の利用方法で、正常に動作することを確認しました。

    • C#によるWindowsアプリケーションからのプライマリ相互運用機能アセンブリによる利用。(WinApp-Interop-COM)

    正常動作

    • C#によるASP.NETアプリケーションからのプライマリ相互運用機能アセンブリによる利用。(WebApp-Interop-COM)

    正常動作

    • VBScriptからのCreateObjectによる利用

    正常動作

    開発環境とテスト環境での動作を確認した後に、運用環境である、Windows 2003 Server Standard Edition SP1 64bit 環境(Intel3.2GHz×4CPU+MEM4GB)に配置(Regsvr32)を行い、以下の利用方法で確認を行ったところ、不可解な現象が発生いたしました。

    • C#によるWindowsアプリケーションからのプライマリ相互運用機能アセンブリによる利用。(WinApp-Interop-COM)

    正常動作

    • C#によるASP.NETアプリケーションからのプライマリ相互運用機能アセンブリによる利用。(WebApp-Interop-COM)

    エラー発生。クラスが見つかりません。

    • VBScriptからのCreateObjectによる利用

    エラー発生。クラスが見つかりません。

     

    64bit環境では、完全に動かないというのであれば、原因がつかみやすいのですが、C#によるWIndowsアプリケーションからは、正常に利用できるということと、VBScriptからでさえも動作しないこの状況がまったくわからない状態です。

    このような経験をお持ちの方、または調査方法などわかりましたら、教えてください。

    2006年4月2日 14:52

回答

  • 実際に運用を行うユーザー環境で調査を行いましたので、結果を報告いたします。

    以前ご連絡いたしましたが、C#によるWindowsアプリケーションおよびCOMコンポーネントは、VisualStudio2003でビルドしたものをそのまま動作させていたため、32ビットで動作していました。

    (タスクマネージャで*32が付いていました。)

    また、C#によるWebアプリケーションは、運用環境で/platformを指定しないでCSC.exeを実行していたため、64ビットで動作しておりました。

    (ASP.NETが64ビット.NET Frameworkで動作していました。)

    そのため、64ビット動作のWebアプリケーションから32ビット動作のCOMコンポーネントを利用できずにクラスが見つからない旨のエラーが発生しておりました。

    対応方法としては、ASP.NETを32ビットで動作させる方法も検討しましたが、今後の保守性を考慮して64ビットで動作させることとし、

    Windowsアプリ+COMコンポーネントはそのまま(32ビット)として、Webアプリ+COMコンポーネントのCOMの機能をWebアプリ側で新規に作成することで、Webアプリからは、COMコンポーネントを利用しないように対応いたしました。

     

    2006年5月1日 9:00

すべての返信

  •  KEROBOT さんからの引用

    C#によるWIndowsアプリケーションからは、正常に利用できるということと、

    (理由は分かりませんが)その C# アプリは 32bit ランタイムで動作してませんか?

    2006年4月2日 17:45
  • ご返信ありがとうございます。

    ご指摘で気がついたのですが、C#で作成したWindowsアプリケーションが、32bitランタイムで動いている可能性が大きいです。

    Windowsアプリケーションに関しては、VisualStudio.NETでビルドしてセットアップを作成したものをインストールしているのですが、

    ASP.NETアプリケーションに関しては、設置場所のWindowsXP Pro Sp2 32bit上で.NET SDK 2.0のcsc.exeを利用してビルドしたものを、Windows 2003 Server 64bit上に配置しています。

    その際に、オプションとして/platformを指定していないため、環境が規定のanycpuとなってしまっていると思われますので、/platform x86を指定し、強制的に32bitアプリケーションとすれば、32bitのCOMコンポーネントの呼び出しが成功するのではないかと思います。

    すぐには試せませんが、次回の作業ではこの方法を試してみます。

    また、いまさらの確認となりますが、32bitのCOMコンポーネントは、64bitアプリケーションから利用することはできないのでしょうか。

    それとも、環境に合わせて?Interopを生成すれば、利用可能なのでしょうか。

    64bit環境でのVBScriptからの利用も踏まえ、この点に関しての資料などがありましたら教えていただければ幸いです。

    以上、よろしくお願いいたします。

    2006年4月3日 0:33
  • .NET 1.x(VS2002, 2003)はx64にWOWで対応しています。

    要するに32bitで動くと言うことです。

    VBSなどは64bitで動いているはずなので、そのままでは動かないでしょう。

    1つの解決策はVisual Studio 2005に移行してしまうということです。これでネイティブx64になりえます。

    もう1つはC:\WINDOWS\SysWOW64\cscript.exeを直接コールするかではないでしょうか。

    2006年4月3日 1:20
  •  64bitコードから32bitコードを呼び出すことはできません。

     また、作ったアプリ(foo.exeとします)が32bitか64bitのどちらで動いているか確認するには、タスクマネージャの「プロセス」タブで見てください。32bitのプログラムだったら

     foo.exe*32

      という感じで後ろに「*32」とつきます。

    2006年4月3日 1:32
  • 中博俊さん、KKamegawaさん返信ありがとうございます。

    .NET1.xおよび.NET2.0のアプリケーションは、32bitアプリケーションも含め、64bit環境上で動作しておりますが、今後の対応では、開発環境も含め.NET2.0の環境に全面的に移行していく予定ですので、既存の開発物(COM等)も含め、影響範囲を確認しつつ対応していこうと思います。

    C:\WINDOWS\SysWOW64\cscript.exeによる32bit動作や、タスクマネージャの表示に関しては、まったく知りませんでした。

    次回調査の際に有効に活用させていただきます。

    ありがとうございました。

     

    2006年4月3日 2:21
  • 実際に運用を行うユーザー環境で調査を行いましたので、結果を報告いたします。

    以前ご連絡いたしましたが、C#によるWindowsアプリケーションおよびCOMコンポーネントは、VisualStudio2003でビルドしたものをそのまま動作させていたため、32ビットで動作していました。

    (タスクマネージャで*32が付いていました。)

    また、C#によるWebアプリケーションは、運用環境で/platformを指定しないでCSC.exeを実行していたため、64ビットで動作しておりました。

    (ASP.NETが64ビット.NET Frameworkで動作していました。)

    そのため、64ビット動作のWebアプリケーションから32ビット動作のCOMコンポーネントを利用できずにクラスが見つからない旨のエラーが発生しておりました。

    対応方法としては、ASP.NETを32ビットで動作させる方法も検討しましたが、今後の保守性を考慮して64ビットで動作させることとし、

    Windowsアプリ+COMコンポーネントはそのまま(32ビット)として、Webアプリ+COMコンポーネントのCOMの機能をWebアプリ側で新規に作成することで、Webアプリからは、COMコンポーネントを利用しないように対応いたしました。

     

    2006年5月1日 9:00