2011-02-09 10 views
2

私は、いくつかの開発者がx86環境(まだWinXP)で作業していて、他の開発者が64ビット環境で作業している環境で作業していますサーバー2008 R2)。このソリューションには、Program FilesにあるDLLへの参照が多数あります。 32ビットのenvではこれは問題ありませんが、64ビットに移行すると、これらの参照は "c:¥Program Files(x86)"を指すはずですので失敗します。 - ソリューションがチェックインされ、別の環境で再度開くたびに、参照を更新する必要があります。両方の環境をサポートする良い方法があるのですか、それとも、それぞれのアーキテクチャーごとに異なる参照を持つ別々のソリューション/プロジェクトファイルを持つ必要があるのでしょうか?x86とx64 OS上の同じ.Netソリューションで開発 - プログラムファイルへの参照

更新:謝罪、私は間違っていたようです。このソリューションは、最初は32ビットで作成されました。私が64ビットでそれを開いたとき、リファレンスが異なるバージョンのdllを打つという問題があったので、私はリファレンスを更新しました(64ビットで)。変更をチェックインしてから32ビットで再オープンしたときに、(x86)フォルダが存在しないという問題が発生したため、参照が見つかりませんでした。一度私は32ビットで参照の場所(およびバージョン)を修正し、それをチェックインし、最新のものを入手し、64ビットでそれを開いた、すべてが良かった。御時間ありがとうございます。

+0

Visual Studioは32ビットプログラムです。コンパイラもそうです。 c:\ program filesからファイルを取得するかどうかを尋ねられたら、Windowsは(x86)に自動的に再マップされます –

+0

あなたはどの言語を使用していますか? –

+0

@ハンス:「C:\ Program Files」の中にあるアセンブリへのハード・リファレンスがあると思うので、x64システムでは.csprojファイルのパスが正しくありません。 (しかし、それは*非常に*私は完全に質問を誤解している可能性があります...) –

答えて

1

"Program Files"からローカルの "Dependencies"フォルダに参照をコピーすることをお勧めします。そこから参照を追加できます。参照は常に相対パスを使用します。これらの参照はGACにはインストールされていないため(これは別の問題ではありません)、これにより、設定を絶えず変更する必要がなくなります。

0

x86から​​通常のプログラムファイルにコピーするビルド後の手順はどうですか?私たちは同様の問題を抱えています。これはちょっと考えただけの解決策です。

1

「プログラムファイル(x86)」が単に「プログラムファイル」を指すように32ビットマシン上にNT再解析ポイントを作成する方法があります。これが私たちの行うことです。

SysInternalsジャンクションユーティリティを使用して再解析ポイントを作成することができます。また、後でOSを使用する場合はmksymlinkを作成することもできます。

関連する問題