3

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

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

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

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

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

4

3 に答える 3

5

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

その後、ユーザーは特定のバージョンのライブラリを使用します。

いくつかの便利なメソッドがいくつかの特定のプロジェクトで実装されており、それがメインのユーティリティ プロジェクトに組み込まれている場合、そのメソッドをプロジェクト内の特別なヘルパー クラスに配置し、それらを可能なユーティリティ候補 (単純な //TODO) としてマークします。プロジェクトの最後に候補を確認し、気に入った場合はメインライブラリに移動します。

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

ただし、パブリッシュごとにバージョンを増やしているため、それほど重要ではありません。

お役に立てれば。

于 2008-09-03T10:23:51.660 に答える
3

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

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

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

于 2008-09-03T12:39:44.067 に答える
1

私はまったく同じ問題を抱えていました！

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

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

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

于 2008-09-03T10:47:47.423 に答える