38

アセンブリの命名とバージョン管理に関するいくつかの優れたプラクティスを探しています。メジャー バージョンまたはマイナー バージョンをどのくらいの頻度でインクリメントしますか?

場合によっては、リリースがバージョン 1.0 から 3.0 に直行するのを見てきました。それ以外の場合は、バージョン 1.0.2.xxxx のままになっているようです。

これは、会社全体の複数のプロジェクトで使用される共有アセンブリ用です。良いインプットを期待しています。

4

4 に答える 4

24

MSDN の Suzanne Cook のブログ (投稿 2003-05-30) のこの記事からのいくつかの良い情報:

ファイル/アセンブリのバージョンをいつ変更するか

まず、ファイルのバージョンとアセンブリのバージョンが一致している必要はありません。ビルドごとにファイルのバージョンを変更することをお勧めします。ただし、同じファイルの 2 つのバージョンの違いを見分けるためだけに、ビルドごとにアセンブリ バージョンを変更しないでください。そのためにファイルバージョンを使用します。アセンブリ バージョンをいつ変更するかを決定するには、考慮すべきビルドの種類 (出荷と非出荷) について議論する必要があります。

非出荷ビルド
一般に、出荷ビルド間で非出荷アセンブリ バージョンを同じに保つことをお勧めします。これにより、バージョンの不一致による厳密な名前のアセンブリの読み込みの問題が回避されます。発行者ポリシーを使用して、ビルドごとに新しいアセンブリ バージョンをリダイレクトすることを好む人もいます。ただし、非出荷ビルドの場合はお勧めしません。すべての読み込みの問題を回避できるわけではありません。たとえば、パートナーがアプリを x-copy する場合、パートナーはパブリッシャー ポリシーをインストールすることを知らない可能性があります。そうすると、マシン上で問題なく動作していても、アプリが壊れてしまいます。

ただし、同じマシン上の異なるアプリケーションがアセンブリの異なるバージョンにバインドする必要がある場合は、それらのビルドに異なるアセンブリ バージョンを与えることをお勧めします。これにより、LoadFrom/etc を使用せずに各アプリの正しいバージョンを使用できるようになります。

出荷ビルド 出荷ビルド
のためにそのバージョンを変更するのが良い考えかどうかは、バインディングをエンド ユーザーにどのように機能させたいかによって異なります。これらのビルドを並べて配置しますか、それとも同じ場所に配置しますか? 2 つのビルドの間に多くの変更点がありますか? 彼らは何人かの顧客を壊すつもりですか？それらが壊れてもかまいませんか (または、ユーザーに重要な更新を強制的に使用させたいですか)? はいの場合は、アセンブリ バージョンをインクリメントすることを検討する必要があります。ただし、繰り返しになりますが、これを何度も行うと、ユーザーのディスクが古いアセンブリで散らかる可能性があることを考慮してください。

アセンブリのバージョン
を変更する場合 ハードコードされたバージョンを新しいバージョンに変更するには、ヘッダー ファイル内のバージョンに変数を設定し、ソース内のハードコーディングを変数に置き換えることをお勧めします。次に、ビルド中にプリプロセッサを実行して、正しいバージョンを配置します。バージョンの変更は、出荷前ではなく、出荷直後に行うことをお勧めします。これにより、変更によるバグを発見する時間が長くなります。

于 2008-10-17T17:03:37.367 に答える
21

バージョニングを定義する 1 つの方法は、各部分にセマンティックな意味を与えることです。

  • 新しいリリースとの互換性が失われると、Nx から N+1.0 に移行します
  • 互換性を損なわない新機能が追加されると、NM から N.M+1 に移行します。
  • バグ修正が追加されると、NMX から NMX+1 に移行します

上記は単なる例です。自分にとって意味のあるルールを定義する必要があります。しかし、バージョンを見るだけで非互換性が予想されるかどうかをユーザーがすぐに判断できるのは非常に便利です。

ああ、思いついたルールを公開することを忘れないでください。

于 2008-10-14T02:36:32.910 に答える
9

セマンティック バージョニングには、これを適用する方法 (およびタイミング) に関する一連のガイドラインと規則があります。従うのは非常に簡単で、それだけで機能します。

http://semver.org/

于 2010-08-18T22:35:16.353 に答える
6

最初にお勧めするのは、Assembly バージョンと File バージョンの違いに慣れることです。残念ながら、.NET は、AssemblyInfo ファイルに関しては、これらを同じものとして扱う傾向があり、通常は AssemblyVersion のみを配置し、FileVersion をデフォルトで同じ値にすることができます。

これは共有アセンブリであると言ったので、バイナリ レベルで共有されていることを意味していると思います (さまざまなソリューションにプロジェクトを含めることによってではありません)。その場合は、.NET がアセンブリに厳密な名前を付けるために使用し (GAC に配置できるようにするため)、アセンブリのバージョンを変更することについて慎重に検討する必要があります。また、「アセンブリの完全な名前」も構成します。アセンブリのバージョンが変更されると、app.config ファイルにアセンブリ リダイレクト エントリを追加しなくても、それを使用するアプリケーションに重大な変更が加えられる可能性があります。

命名に関しては、会社の命名規則 (もしあれば) とライブラリの目的に依存すると思います。たとえば、このライブラリが特定の製品や事業部門に固有ではない「コア」(またはシステム レベル) 機能を提供する場合、次のように名前を付けることができます。

CompanyName.Framework.Core

それがより大きなライブラリの一部である場合、または単に

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

バージョン番号をインクリメントするタイミングに関しては、依然としてかなり主観的であり、ビルド番号の各部分が何を表していると考えるかによって異なります。デフォルトの Microsoft スキームは Major.Minor.Build.Revision ですが、独自の定義を作成できないわけではありません。最も重要なことは、戦略に一貫性を持たせ、定義とルールがすべての製品で意味をなすようにすることです。

私が見たほぼすべてのバージョン スキームで、最初の 2 つの部分は Major.Minor です。メジャー バージョン番号は通常、大きな変更や重大な変更がある場合に増加しますが、マイナー バージョン番号は通常、変更が重大な変更ではなかったことを示すために増加します。他の 2 つの数値はかなり主観的なものであり、「ビルド」(多くの場合、シリアルの日付値または毎日変化する順次更新される数値) と「リビジョン」またはパッチ番号である可能性があります。また、それらが逆になっているのも見ました (Major.Minor.Revision.Build を与える)。ここで、build は自動ビルド システムから順次インクリメントされる番号です。

アセンブリのエクスポート時に、アセンブリのメジャー バージョンとマイナー バージョンがタイプ ライブラリのバージョン番号として使用されることに注意してください。

最後に、詳細については、これらのリソースのいくつかをご覧ください。

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx

于 2008-10-14T02:42:18.793 に答える