6

新しい開発マシンを入手し、Vista 64 Ultimate に移行して 8 GB RAM を活用しています。私たちのマネージャーは、すべての開発を 32 ビット仮想マシンで行って、コードを本番環境に移行する際に問題が発生しないようにすることを望んでいます。

結果のプログラムが 32 ビット OS で動作することを保証する方法はありますか? 仮想マシンの使用は気にしませんが、「シングル」モニター タイプ ビューに強制的に戻される方法は好きではありません。VS ツールバーを別のモニターに移動するのが好きです。

編集: Visual Studio 2005 および 2008、VB.NET および/または C# を使用しています。

編集:Harpreet's answerを使用して、これらは Visual Studio IDE を x86 / 32bit をコンパイルするように設定するために使用した手順です。

  1. [ビルド] をクリックして構成マネージャーを開きます
  2. アクティブなソリューション プラットフォームのドロップダウン リストを選択します
  3. リストにある場合は x86 を選択し、そうでない場合は手順 5 に進み<New...ます。
  4. [新しいソリューション プラットフォーム] ダイアログで、[x86] を選択して [OK] を押します。
  5. すべてのプロジェクトで選択したプラットフォームが x86 であることを確認します
  6. [閉じる] をクリックします。

楽しみ。

ありがとう、キース

4

7 に答える 7

9

私は 32 ビット Windows 用の 64 ビット マシンで開発を行っています。問題じゃない。保守的にするために、プロジェクトが x86 モードでコンパイルされるように設定されていることを確認する必要があります。ソリューション内の各プロジェクトを調べて、これを再確認する必要があります。AnyCPU 設定を使用することもできますが、開発マシンでは 32 ビット マシンとは異なる動作をするため、少し危険です。もちろん、64ビットモードは避けたいです。

私が遭遇した問題は、アプリが 64 ビット用にコンパイルされている場合 (明示的に 64 ビットまたは AnyCPU コンパイルされ、64 ビット Windows で実行されている場合) に動作しないドライバーです。これらの問題は、x86 コンパイルに固執することで完全に回避できます。これにより、開発マシンのすべての欠陥が明らかになるはずです。

理想的には、32 ビット マシンで頻繁に実行できるビルドおよびテスト環境をセットアップできます。これにより、管理者は安心し、VM をデスクトップとして使用することを避けることができます。

于 2008-08-27T17:02:45.580 に答える
4

実行可能ファイルを 32 ビットとしてコンパイルする限り、それらは 32 ビットと 64 Windows マシンの両方で実行されます (保証されています)。64 開発マシンを使用すると、64 ビット コンパイルでコードのテストを開始できるという利点があり (32 ビット整数にキャストされたポインターなどをチェックするため)、将来的に 64 ビットへの移行が容易になります (会社が選択する必要があります)。 64 ビット バージョンを実行する)。

于 2008-08-27T16:08:06.990 に答える
1

64 ビット OS 用のコンパイルは、コンパイラのオプションです。Vista 64 ビット内から 32 ビット exe に完全にコンパイルできます。アプリを実行すると、タスクマネージャーでプロセスの横に「* 32」があることがわかります...これは、32ビットであることを意味します;)

あなたのマネージャーは、64 ビット OS が実際に何を意味するのかについて、もう少し教育を受ける必要があると思います :)

于 2008-08-27T16:06:54.670 に答える
1

あなたの質問への答えではありませんが、おそらくあなたの問題の解決策です.VirtualBox（およびおそらく他のもの）は「シームレスな統合」モードをサポートしています。これにより、2番目のスタートバーが提供され、ウィンドウを自由にドラッグできます.

また、これはあなたの質問への回答です。コンパイルの設定によって異なります。さまざまな環境用にコンパイルでき、Visual Studio を使用して 64 ビット システムで 32 ビット プログラムを完全にコンパイルできます。方法はわかりませんが、Visual Studio の第一人者が助けてくれるはずです。

于 2008-08-27T16:09:40.763 に答える
1

VS 2005 (まもなく 2008) を使用して 32 ビット アプリケーションを開発し、XP Pro x64 または Vista Business 64 ビットを搭載した新しいマシンをいくつか購入したところです。商業的に必要になった場合は、64 ビット ポートを実行する可能性があります。開発環境などでいくつかのスクリプトを微調整する以外に、これを行うことに問題はありませんでした.

このアップグレード サイクルに含まれていない開発者は、まだ 32 ビット マシンを使用しているため、チェックイン前に当然のことながら単体テストとアプリケーション テスト スイートを実行すると、問題が発生するはずです。

また、チェックインのセットをビルドおよびテストする「典型的な」構成 (XP/Vista、2/4/8 コアなど) で構成される「テスト ビルド」マシンのセットがあることを確認することも行っています。 - 安定性、パフォーマンスなどのさまざまなテスト スイートがあります。 - それらが適切な統合領域に追加される前。繰り返しますが、これらは 64 ビット OS 上に構築された 32 ビット アプリケーションの実行に関する問題を検出していません。

とにかく、他の人がすでに言ったように、コンパイラが実際に実行されているOSに関係なく、ターゲットOSに適切なコードを生成するのはコンパイラであるため、問題になるとは思いません。

于 2008-08-27T17:24:43.797 に答える
0

ええ、アダムが言っていたように。MSIL (デフォルト)、x64、および x86 の 3 つのオプションがあります。x64 をターゲットにすると、64 ビット システム専用の dll が生成されます。または、32 ビットと 64 ビットで実行される x86 を実行できますが、64 ビット システムでは 32 ビットと同じ制限があります。

MSIL は基本的に、JITer がプラットフォーム固有の命令を発行できるようにします (ネイティブ イメージと比較してわずかにパフォーマンスが低下します)。

EDIT : 言語がないので、vb.net や c# などの .net フレームワーク言語について話しています。c++ はまったく別の動物です。

于 2008-08-27T16:14:44.977 に答える
0

今日これを見つけました：

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

.NET を使用した x64 開発

今年の初めに、私は 64 ビット オペレーティング システム (正確には Vista Ultimate x64) に切り替えました。ほとんどの場合、このプロセスは比較的簡単でしたが、途中でいくつか問題が発生しました (主に x64 互換ドライバーですが、それはこの議論のポイントではありません)。

x64 開発の世界では、ここで概説したいいくつかの苦労した点がありました。このリストは増える可能性が高いので、この件に関する今後の投稿を期待してください。

.NET 開発の素晴らしい世界では、さまざまなプラットフォームを対象とするようにアプリケーションとアセンブリをコンパイルできます。既定では、アプリケーションとアセンブリは、Visual Studio で任意の CPU としてコンパイルされます。このシナリオでは、CLR は、アセンブリが実行されているコンピューターの既定のターゲットが何であれ、アセンブリを読み込みます。たとえば、x64 マシンで実行可能ファイルを実行すると、64 ビット プロセスとして実行されます。

Visual Studio は、x86、x64、および Itanium (IA-64) の 3 つの特定のプラットフォーム ターゲットも提供します。実行可能ファイルを特定のターゲットとしてビルドすると、そのタイプのプロセスとしてロードされます。たとえば、x64 マシンで実行される x86 をターゲットとする実行可能ファイルは、32 ビット CLR および WOW64 レイヤーを使用して 32 ビット プロセスとして実行されます。実行時にアセンブリが読み込まれる場合、ターゲットがホスティング プロセスのターゲットと一致する場合、または任意の CPU としてコンパイルされている場合にのみ、プロセスによってアセンブリを読み込むことができます。たとえば、x64 がアセンブリのターゲットとして設定されている場合、x64 プロセスによってのみ読み込むことができます。

これは、私にとっていくつかのシナリオで効果を発揮しました。

  • XNA - XNA は、32 ビット アセンブリのセットとしてのみ使用できます。したがって、XNA アセンブリを参照する場合、それらを使用する実行可能ファイル/アセンブリは x86 プラットフォームをターゲットにする必要があります。x64 (または任意の CPU として 64 ビット マシンで実行) としてターゲットにされている場合、XNA アセンブリを読み込もうとするとエラーがスローされます。

  • Microsoft Robotics Studio - XInputGamepadService は、内部で XNA を使用して Xbox 360 コントローラーと通信します。上記を参照。

  • マネージド DirectX - これは既に非推奨であり、XNA に置き換えられていますが、まだ使用されています。アセンブリは特定のターゲット用にマークされていませんが、メモリ例外、特に Microsoft.DirectX.AudioVideoPlayback アセンブリで問題が発生しました。

  • Phidg​​ets - どのライブラリをいつダウンロードするかによって、32 ビットのみとしてマークされる場合とされない場合があります。現在のバージョン (2007 年 11 月 8 日) はそのようにマークされているため、ホストするには 32 ビット プロセスが必要です。実行可能ファイルまたはアセンブリが特定のプラットフォームを対象としているかどうかを判断する最も簡単な方法は、corflags アプリケーションを使用することです。これを使用するには、[スタート] メニューから Visual Studio コマンド プロンプトを開き、チェックするアセンブリに対して実行します。

実行可能ファイルまたはアセンブリが特定のプラットフォームを対象としているかどうかを判断する最も簡単な方法は、corflags アプリケーションを使用することです。これを使用するには、[スタート] メニューから Visual Studio コマンド プロンプトを開き、チェックするアセンブリに対して実行します。

于 2008-11-07T17:44:36.283 に答える