より明確にするために、お客様の正しい条件をお聞きしたいと思います。
プロジェクトまたはソリューションVisual Studioでビルドする代わりに再ビルドしますか?
言い換えると、なぜ MS は Visual Studio で "Re-build ALL" オプションを作成する必要があったのですか? 彼らがそうする主な動機は何でしたか?
ありがとう!
より明確にするために、お客様の正しい条件をお聞きしたいと思います。
プロジェクトまたはソリューションVisual Studioでビルドする代わりに再ビルドしますか?
言い換えると、なぜ MS は Visual Studio で "Re-build ALL" オプションを作成する必要があったのですか? 彼らがそうする主な動機は何でしたか?
ありがとう!
DRY:Rebuild = Clean + Build foreachprojects。
ビルドは、以前のビルド出力を削除しません。再ビルドはそれらを削除して再ビルドします(ソリューションを使用している場合は、一度に1つのプロジェクト:proj1 \ bin \ Debugを削除し、proj1をビルドし、proj2 \ bin \ Debugを削除します...)。
再構築(またはクリーンビルド)を行う主なケースは、ソリューションの3番目の依存関係を更新する必要がある場合です。次のフォルダツリーを見てみましょう。
解決 |__依存関係 | __PROJ_1 | __bin | __obj | __(コード) | __PROJ_2 | __bin | __obj | __(コード)
依存関係でdllを変更し、再構築を行わない場合、依存関係のルックアップ順序(http://www.beefycode.com/post/Resolving-Binary-References-in-MSBuild.aspxを参照してください):
{CandidateAssemblyFiles}
$(ReferencePath)
.USER
-ファイル から取得される参照パスプロパティ。{HintPathFromItem}
。binフォルダーのdllは最初のルックアップの場合になり、Dependenciesフォルダーのdllは2番目のケースになります...
そのような場合、私はクリーン(デバッグ)、クリーン(リリース)、そしてビルドを実行して、binフォルダー内の以前のすべてのバージョンを根絶します。私は多分少しやり過ぎで、再構築で十分かもしれませんが、dllがデバッグフォルダとリリースフォルダにあるのでわかりません...
場合によっては、うまくいかず、ビルドが機能しないことがあります。
これは、依存ライブラリを正しく更新せず、ビルドの bin パスに正しくコピーされない場合などに発生します。他にも思いつかない例があります。
そんな時はrebuildを使います。