共通/ユーティリティ ライブラリの操作

Question

私が働いている会社には、私たちが構築するほぼすべてのアプリケーションによって参照される「ユーティリティ」プロジェクトがあります。NullHelpers、ConfigSettingHelpers、Common ExtensionMethods など、たくさんのものがあります。

新しいプロジェクトを作成する場合、ソース管理からプロジェクトの最新バージョンを取得してソリューションに追加し、ソリューションに追加される新しいプロジェクトからプロジェクトを参照するという方法で作業します。

これは問題なく機能しましたが、人々が共通プロジェクトに「重大な変更」を加え、その人にとっては機能しても、他の人にとっては機能しないという事例がいくつかありました。

共通ライブラリをプロジェクト参照として追加するのではなく、スタンドアロン DLL として共通ライブラリの開発を開始し、さまざまなバージョンを公開し、特定のプロジェクトの特定のバージョンをターゲットにして、リスクなく変更できるようにする必要があるのではないかと考えています。共通ライブラリを使用して他のプロジェクトに送信します。

そうは言っても、他の人が共通ライブラリをどのように参照または使用するかを見ることに興味があります。

Answer 1

まさにそれが私たちがやっていることです。プロジェクト固有ではない便利な機能がいくつかあるユーティリティ プロジェクトがあります。バージョンを手動で (マイナーに) 上げ、リリース バージョンでプロジェクトをビルドし、署名して共有場所に置きます。

その後、ユーザーは特定のバージョンの 図書館.

いくつかの有用なメソッドが特定のプロジェクトに実装されており、それがメインのユーティリティ プロジェクトに組み込まれる可能性がある場合、プロジェクト内の特別なヘルパー クラスにメソッドを配置し、それらをユーティリティの候補 (単純な //TODO) としてマークします。プロジェクトの最後に候補を検討し、定着した場合はメインに移動します。 図書館.

破壊的な変更は禁止されており、必要に応じてメソッドとクラスを [廃止] としてマークします。

ただし、公開するたびにバージョンを上げていくので、それはあまり問題ではありません。

お役に立てれば。

Answer 2

ソース管理では分岐を使用します。リリースするまでは全員が head ブランチを使用します。リリースを分岐すると、共通ユーティリティ プロジェクトも分岐します。

さらに、私たちのユーティリティ プロジェクトには独自の単体テストがあります。そうすることで、他のチームは他のチームのビルドを壊すかどうかを知ることができます。

もちろん、時々おっしゃるような問題はまだあります。しかし、あるチームが別のチームのビルドを壊す変更をチェックインした場合、それは通常、そのメソッド/オブジェクトのコントラクトがどこかで壊れたことを意味します。私たちはこれらを、公共事業プロジェクトの設計を改善する機会として捉えています...または、少なくともさらに単体テストを作成するには:/

Answer 3

私は持っていました ちょうど 同じ問題です！

以前はプロジェクト参照を使用していましたが、おっしゃるように、多くのプロジェクトがそれを参照していると、すべてがうまくいかないようです。

ここで、DLL にコンパイルし、最初のビルド後に DLL 参照の CopyLocal プロパティを false に設定します (そうしないと、サブプロジェクトがオーバーライドされて混乱する可能性があることがわかります)。

理論的にはおそらく GAC で処理する必要があると思いますが、(私の場合のように) 大きく変化している問題の場合、これは問題になる可能性があります。