問題タブ [64-bit]

Visual Studio 2005/2008 で、32 ビット GAC ではなく 64 ビット GAC でアセンブリを参照するにはどうすればよいですか? ターゲット プラットフォームを x64 に設定していますが、コンパイラは次のエラーをスローしています。

エラー 2 エラーとしての警告: アセンブリの生成 -- 参照されたアセンブリ 'System.Data.dll' は別のプロセッサをターゲットにしています

エラー 3 エラーとして警告: アセンブリの生成 -- 参照されたアセンブリ 'mscorlib.dll' は別のプロセッサをターゲットにしています

エラー 4 アセンブリの署名に失敗しました。出力が署名されていない可能性があります -- システムは指定されたファイルを見つけることができません。一般

2008 年 12 月 29 日更新

64 ビット アセンブリを分離された場所 (例: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\GAC_64) に配置するという Aaron Stebner の提案を試し、HKLM\SOFTWARE\Microsoft.NETFramework などのレジストリに追加のエントリを作成しています。 \AssemblyFolders\GAC_64 または HKLM\SOFTWARE\Microsoft.NETFramework\v2.0.50727\AssemblyFoldersEx\GAC_64 しかし、Visual Studio 2005 はまだそれを取得していません....

最近、ac＃Windowsサービスを64ビットの.netプロセスとして実行するようにアップグレードしました。通常、これは簡単なことですが、システムはC++で記述された32ビットDLLを使用します。このDLLを64ビットに変換するオプションはないため、DLLを別の32ビット.netプロセスでラップし、リモート処理を介して.netインターフェイスを公開しました。

これは非常に信頼できるソリューションですが、システムを単一のプロセスとして実行することをお勧めします。32ビットDLLを64ビットプロセスにロードして直接アクセスする方法はありますか（おそらく、ある種のサンクレイヤーを介して）？

既存の Windows ベースの C++ アプリケーションを 64 ビット環境に移植していますが、これは奇妙なエラーの 1 つです。私が使用しているコード スニペットでは、以前のセットアップで問題なく動作していましたが、64 ビット環境では 1 つのレコードopenforwardonlyセットしか取得できないという問題が発生します。または、ADOの問題である可能性があります。MoveNext();

それを回避するために を使用し始めadOpenStatic、しばらくの間は問題なく機能しましたが、後でパフォーマンスに影響があり、値を取得/反復するのに永遠に時間がかかっていることに気付きました。両方のフラグでこのコードを試して、私が見ている動作を検証するよう誰かに依頼します。

ado フラグに関する情報: http://www.w3schools.com/ADO/met_rs_open.asp

別の EE トピック http://www.experts-exchange.com/Programming/Languages/Visual_Basic/VB_DB/Q_11520558.html

MS のサポート ケースを見た覚えがありますが、今は入手できません。

助けや提案をいただければ幸いです。古いテクノロジーを使用していることは承知していますが、コードをあまり変更せずに追加機能に移行したいと考えています。

JVM は 32 ビット プロセッサ上で 64 ビットのプリミティブな "long" をどのように処理しますか?

マルチコア 32 ビット マシンで、複数のコアを並行して利用できますか?
32 ビット マシンでの 64 ビット操作はどれくらい遅くなりますか?

64ビット環境でのコードカバレッジに何を使用することをお勧めしますか。NCoverはエンタープライズバージョンでのみ64ビットをサポートしているようですが、これはかなり高価なようです。それともそうではありませんか？.NETコードカバレッジのために64ビットシステムで何を使用していますか？

編集：私はCorFlagの回避策を知っています。他の人が何をしているのか、何を使っているのか知りたいのですが。他のものを使用していますか、それともCorFlagトリックでNCover（無料版）を使用していますか？

誰もがすぐに x64 オペレーティング システムにアップグレードできるわけではない場合、.NET チームがアセンブリ参照パスをどのように処理しているかを知りたいです。現在の重要な問題は、Windows の x64 バージョンが、通常の C:\Program Files ではなく、C:\Program Files (x86)\ に 32 ビット インストールを植えることです。これは、サードパーティ製の多くの余分なコンポーネントとフレームワークが C:\Program Files (x86) に保存されることを意味します。

そのため、x86 ワークステーションで作成/変更されたソース プロジェクトを x64 ワークステーションにダウンロードする場合、正しい参照パスを取得するためにいくつかの変更作業が必要になります。通常、x64 ユーザーは変更を保存し、自分の「設定」をバージョン管理リポジトリにコミットして、x86 ユーザーのリズムを壊します。

多様なチームで調和を維持するための良いアプローチは何ですか?

Windows 2008 64ビットにTeam Foundationをインストールできないというのは認定された回答ですか?

アップデート

Windows 2003 または 2008 にインストールしたほうがよいのでしょうか?

私が言おうとしていることのいずれかが意味をなさないか、明らかなことを見落としている場合はお詫び申し上げます.CLRの内部に関する私の知識はむらがあります.

私が正しく理解していれば、VS2K5 で 'AnyCPU' のソリューションをビルドする (または、これらの設定でその .sln ファイルに MSBuild を指定する) と、バイナリは MSIL までしかコンパイルされません。その後、32 ビット プラットフォームで実行された場合は 32 ビットに JIT され、x64 で実行された場合は 64 ビット コードになります。

DLL は Web アプリに使用され、W3WP.exe プロセスでホストされます。Process Explorer は、W3WP が 64 ビット プロセスであることを示しています。

しかし、Process Explorer を使用して DLL ビューでこれらの DLL の 1 つのプロパティを確認すると、「Image: 32-bit」と表示されます。何を与える？

問題の dll に対して corflags を実行すると、次のように表示されます: ILONLY 1 , 32BIT 0 but PE PE32 。私の理解では、これははい、IL までしかコンパイルされていません。いいえ、32 ビットまたは 64 ビットに限定されていませんが、完全には明確ではありません。PE32 フラグは、上記のように 32 ビットとして表示されることと関係がありますか?

私は、COMがx64マシンでどのように動作するかに関して決定的な答えを得ようとしています。Windowsは、x64マシン上のCOMインターフェイスに呼び出しをディスパッチするときに通常のx64呼び出し規約を使用しますか（COM実装が64ビットであると想定）？具体的には、実行時に動的にロードされるアセンブリのチャンクを指すように、vtblエントリを動的に生成します。このアセンブリは、呼び出し元のユーザーからパラメータを正しく取得する方法を知っている必要があります。したがって、COMが標準のx64呼び出し規約（ほとんど高速呼び出し）を使用してアセンブリへの呼び出しを設定するかどうかを知りたいです。

文字列として 64 ビット整数を含むファイルがあります。C++ でこの数値文字列を unsigned 64 ビット整数型に scanf() またはその他の方法で解析するにはどうすればよいでしょうか?

%lld などのようなことは認識していますが、この解析を行う多くの方法は、異なるコンパイラや stdlib でコンパイルを中断するようです。コードは gcc および Microsoft C++ コンパイラでコンパイルする必要があります (もちろん、標準に完全に準拠していることが望ましいです)。