混在した.NET開発環境のアンマネージドx64アセンブリ

Question

64ビットマシンで作業する開発者と32ビットマシンで作業する開発者がいるが、半分のチームでx86にする必要があるアンマネージドアセンブリを参照する必要がある場合もう半分はx64ですか？ 64ビットリグの誰かが最新のものになるたびに手動で参照を更新する以外に解決策がありますか？

Answer 1

あなたはビルドの一環としてこれをやりたいですか？

参照元のDLLをソースツリーの永続的な位置からローカルプロジェクトにコピーするためのビルド前のステップを作成します。 $（ConfigurationName）または$（PlatformName）マクロを使用して、実際にコピーされるアンマネージDLLのバージョンを選択します。 DLLは、構成名またはプラットフォーム名と同じ名前の別々のフォルダに保持されます。

Answer 2

x64マシンの開発者が64ビット版をうまく実行するのはむしろ奇妙です。 Visual Studioではx64モードでの編集+続行はサポートされていませんが、それはかなり損失です。回避策は簡単ですが、Platform Targetをx86に設定してください。あなたのアンマネージドDLLの問題も自動的に解決します。

Answer 3

コードを少し編集する別の解決策があります。答えはMilan Gardianからthis questionに記載されています。

基本的には、アセンブリの両方の（32ビットと64ビット）バージョンにアクセスできる場合は、実行時にロードするアセンブリを決定する独自のアセンブリ参照ハンドラを作成する必要があります。私はちょうどこのソリューションを自分自身で実装しましたが、それは魅力的に機能します。

私の状況は次のとおりです。
Windows 7 64ビット版の「Any CPU」を対象とした.NETプログラムを開発しています。私は32ビットのアセンブリ参照を追加し、Copy Localをfalseに設定しました。ビルド後のイベントを使用して32ビットと64ビットのアセンブリを出力フォルダにコピーし、32ビットアセンブリに参照と異なる名前を付けるようにします。これは、.NETのデフォルトのアセンブリリゾルバで参照を解決できないため、カスタムアセンブリリゾルバを強制的に起動してその処理を実行したいからです。実行時に正しいアセンブリがロードされ、コンパイル時にエラーは発生しません。私は実際にこれが現在32ビットOSで動作していることを実際に確認する時間がなかったことに注意してください。ただし、動作しない理由は何もありません。