私はC＃で構成されているDLLライブラリを作成しました当社の製品を通信および操作するためのAPI。 .NET環境でテストツールを構築するために、チームのQA担当者が使用することを望んでいます。カプセル化の原則とは反対に（提案するかもしれませんが...）、QAの担当者がDLL内のAPIメソッドの実際の実装を確認できるようにしたいと思います（たとえば、[定義に移動]をクリックしたとき）。 Visual Studio）メタデータからの宣言/注釈を表示するだけでなく、
実際のDLLを変更できるようにしたくないし、新しいプロジェクトをビルドするたびにDLLをビルドしたくないので、ライブラリプロジェクトをVSソリューションに単純に追加することはできません。
私の頭に浮かんだ理論的な方法の1つは、ライブラリプロジェクトを各VSソリューションに読み取り専用として追加し（可能な場合）、ビルドしないように指示する（独自の新しいプロジェクトのみをビルドする）か、ビルドをロックする（可能であれば）こともできます。問題は、理想的には、VSソリューション内のライブラリプロジェクトを、バージョン管理システム（Tortoise SVNを使用）からの最新のリビジョンに、更新されたボタンを1つ押すだけで更新できるようにすることです。 （ビルド済み）DLLファイル（DLLファイルをソリューションフォルダーに更新するのは簡単で、単純なバッチファイルでも実行できますが、プロジェクトファイル自体を更新する方法がわかりません...）。
もちろん、新しいQAツールを開発するための準備が迅速かつ簡単になるように、上記のすべてをある種のテンプレートに入れたいと思います。
この問題を定式化するのは難しいと思いました（私は十分に明確でした）が、これはチームで作業するときに非常に一般的な問題であると確信しています（私は慣れていません）。誰かがこの問題を処理する正しい方法を理解するのを手伝ってもらえますか？
回答：
回答№1は0これはの仕事のようです ソースサーバー。どうやら（私は個人的なものはありませんが私自身の経験）破壊に対抗するためのツールはすでに存在しています。これは、ソースファイルのコピー（読み取り専用のものも含む）をすべて保持するよりも優れたオプションのようです。
注を追加：上記のリンクは、SubversionではなくPERFORCEを使用したソースサーバーの作成者の実装について説明していますが、他のリンクを見つけることができるはずです（ これです、そしておそらくより良いもの）特に破壊について議論します。