ビルド後のイベントを使用したくないとおっしゃっていたのは知っていますが、なぜ私に興味をそそられなかったのかという理由があります。ビルド後のイベントで.dllの名前をハードコーディングしているようです。それは簡単に回避できます。
xcopy "$(TargetDir)*" "c:\common\" /Y
これ*
により、bin /Debug/フォルダー内のすべてが共通フォルダーにコピーされます。必要に応じて、dllをコピーすることもできます。または、を使用する場合$(TargetPath)
は、プロジェクトの結果である1つのdllのみをコピーし、他の関連する依存関係はコピーしません。
アップデート
これを行う方法は、各プロジェクトでbinフォルダー全体がサブフォルダーにコピーされることです。2つのプロジェクトがWebUtil
ありHtmlParser
、WebUtilがHtmlParserに依存しているとします。両方のプロジェクトで、を使用しますxcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y
。これにより、c:\ common \ WebUtil \とc:\ common\HtmlParserが作成されます。WebUtilで、c:\ common \ HtmlParser\HtmlParser.dllへの参照を追加します。これで、c:\commonにHtmlParser.dllのコピーが2つあります。
c:\ common \ HtmlParser \HtmlParser.dll//最新のビルド。c:\ common \ WebUtil \ HtmlParser// WebUtilがビルドされたときの最新のビルドは何でしたか
これにはあらゆる種類の利点があります。HtmlParserのAPIを変更した場合、WebUtilを再構築しようとするまで古いHtmlParser.dllが存在するため、WebUtilは引き続き機能します(その時点で、APIが変更されたためにビルドエラーが発生します)。
ここで、WebUtilに依存する3番目のプロジェクトが混在していて、HtmlParserでクラスを公開するWebUtilの一部を使用している場合は、新しいプロジェクトから両方のプロジェクトへの参照を追加する必要があります。HtmlParser.dllへの参照を追加するときは、c:\ common\WebUtilにあるものを使用してください。これを行うのは、WebUtilの必要な要件としてのみ含めるためです。これで、WebUtil.dllの現在のバージョンと一致するバージョンのHtmlParser.dllが常に作成されます。
それが理にかなっていることを願っています。管理するのは間違いなく難しいことです。svn:externals=Pを使用してすべての依存関係のプルダウンを開始する必要があるまで待つだけです