問題タブ [anycpu]

私のC＃プログラムはAnyCPUオプションでコンパイルされており、P/Invokeを使用してネイティブAPIを次のように呼び出しています。

私のゲストは、私のc＃プログラムはanycpuでコンパイルされているので、32ビットプロセスと64ビットプロセスの両方から読み取りおよび書き込みを行うことができますか？または問題がありますか？私は32ビットOSしかないので、テストできないので、これを求めています。どうも

作業中のプロジェクトのマージモジュールを作成しています。

2つのマージモジュールを作成します。1つは32ビット用、もう1つは64ビット用です。それらをWiXインストーラーに含めたいのですが、できません：エラーLGHT0345：'installer \ bin \ x64 \ Release \ en-us \ myproject.msm'は64ビットのマージモジュールですが、それを消費する製品です32ビットです。32ビット製品は32ビットマージモジュールのみを消費できます。

両方を含めることができるようにデュアルCPUプロジェクトを作成する方法はありますか？

WiXのバージョンは3.6です。

このスクリーン ショットが示すように、Windows Phone 7 アプリには x86、x64、anycpu を選択できます。しかし、wp7 アプリに違いはありますか?

ありがとう

グラフィックを多用するビジュアルコントロールを含むサードパーティの.Net2アセンブリを参照する.Net4WinFormsアプリがあります。誤ってAnyCpuからx86コンパイルモードに切り替えたときに、アプリの視覚的パフォーマンスが大幅に向上することに気づきました。私の開発リグはx64Windows7です。コントロールがグラフィカル要素をレンダリングしている場合、改善は少なくとも2倍になります。

これは既知の事実ですか、それとも私は何か間違ったことをしていますか？

問題

アセンブリは開発時に問題なくロードされますが、本番環境ではロードできません。

詳細

アセンブリquickfix_net.dllとquickfix_net_messages.dll（Quickfix.NET API）が本番システムにロードできず、次の例外が発生します。

System.Windows.Threading.Dispatcher：System.IO.FileNotFoundException：ファイルまたはアセンブリ'quickfix_net.dll'またはその依存関係の1つを読み込めませんでした。指定されたモジュールが見つかりませんでした。ファイル名：'quickfix_net.dll'

私の修正の試み

• アプリケーションEXEの横にアセンブリが存在することを確認しました。
• ターゲットCPUをAnyCPUからx86に変更しました。
• を使用してx86として署名されたQuickfixアセンブリCorflags.exe
• 依存関係の欠落もないことを確認しました。

質問

開発システムと本番システムの主な違いは、最初に完全にロードされたアセンブリの問題を引き起こす可能性がありますが、後のシステムではロードされない可能性がありますか？

最初に、 Mass Transitをサービス バスとして使用してコンソール アプリケーションを作成しました。最近、コンソール アプリケーションを作成する必要がなく、代わりにクラス ライブラリを作成する必要があるNServiceBusに切り替えました。プロジェクトのプロパティで、コンソールアプリからライブラリに変更する設定に切り替えただけですが、x86でしかビルドできないという制約はそのままです。

ビルド タイプを任意の CPU に変更することはできません。これはコンソール アプリケーションであり、現在は有効になっているはずです。build Any CPU オプションを実行できるように、アプリケーションをクラス ライブラリに完全に変更する方法はありますか? 新しいプロジェクトを作成し、そこにファイルをコピーして、そのまま続行する必要がありますか? それとも、プロジェクト (.proj) ファイル内の何かを変更するのと同じくらい簡単ですか?

スタック オーバーフローの質問Missing Debug|Any CPU build configuration for projects and defaulting to Debug|x86 on Windows x64は、コンソール アプリケーションのみの x86 のこの問題に関する詳細なコンテキストを提供します。

私は、公開したい商用の .NET 開発者ライブラリに取り組んでおり、エンド ユーザー (開発者) にすぐに提供できる .DLL のバージョンを知りたいと考えています。

.DLL は、私が予測できないさまざまな環境で実行される可能性があります。

私の現在の計画は、次のものを提供することです。

• .NET3.5 と .NET4 の両方のコンパイル済みバージョン
• 各バージョンの署名なし
• 1 つはコンパイル済み 32 ビット、もう 1 つはコンパイル済み 64 ビット

全部で 8 つの異なるエディション。

問題は、これが良い戦略かどうかです。

32 ビット環境と 64 ビット環境の両方で DLL を実行することを好む人のために、「AnyCPU」コンパイル バージョンも作成する必要がありますか?

自動化されたビルド/パッケージングで簡単に実行できるため、これらすべてのエディションを実行する余分な作業は気にしません。

メモリ内で .NET アセンブリを実行するためにAssembly.Load()、次に使用しています。EntryPoint.Invoke(null, null)ホスト プロセスが x86 で、実行されたアセンブリが AnyCPU でない限り、これは機能します。この場合、実行されたアセンブリは x86 コンテキストで実行されるため、誤動作します。

ホスト プロセスが x86 であっても、AnyCPU コンテキストで Assemly オブジェクトを実行する方法はありますか?

シンプルなコードに小さな問題があります。このコードは「x86」モードでは正しく動作しますが、「任意の CPU」モードでは機能しません。あるクラスを「x86」で実行し、別のクラスを「任意の CPU」モードで実行することは可能でしょうか? コード：

MSBuild から x86 と「任意の cpu」プロジェクトを含むソリューションのすべてのプロジェクトをビルドすることは可能ですか?

プロジェクトに複数のプラットフォームがあるかどうかに関係なく機能するソリューションが理想的です構築中です。