アセンブリの命名とバージョン管理のベストプラクティスは？
アセンブリに名前を付けてバージョン管理するためのいくつかの優れた方法を探しています。メジャーバージョンまたはマイナーバージョンをどのくらいの頻度でインクリメントしますか？
場合によっては、リリースがバージョン1.0から3.0に直接移行するのを見てきました。それ以外の場合は、バージョン1.0.2.xxxxでスタックしているようです。
これは、会社全体の複数のプロジェクトで使用される共有アセンブリ用です。いくつかの良い入力を楽しみにしています。
MSDNのSuzanneCookのブログ（2003-05-30に投稿）の この記事 からのいくつかの良い情報：
ファイル/アセンブリのバージョンを変更するタイミング
まず第一に、ファイルバージョンとアセンブリバージョンは互いに一致する必要はありません。ビルドごとにファイルバージョンを変更することをお勧めします。ただし、同じファイルの2つのバージョンの違いがわかるように、ビルドごとにアセンブリのバージョンを変更しないでください。そのためのファイルバージョンを使用してください。アセンブリのバージョンをいつ変更するかを決定するには、考慮すべきビルドのタイプ（出荷と非出荷）についていくつかの議論が必要です。
出荷されていないビルド
一般に、出荷されていないアセンブリバージョンを出荷ビルド間で同じに保つことをお勧めします。これにより、バージョンの不一致による厳密な名前のアセンブリ読み込みの問題が回避されます。パブリッシャーポリシーを使用して、ビルドごとに新しいアセンブリバージョンをリダイレクトすることを好む人もいます。ただし、出荷されていないビルドの場合はお勧めしません。すべての読み込みの問題を回避できるわけではありません。たとえば、パートナーがアプリをxコピーした場合、パートナーはパブリッシャーポリシーをインストールすることを知らない可能性があります。そうすると、マシン上で問題なく動作していても、アプリは壊れてしまいます。ただし、同じマシン上の異なるアプリケーションを異なるバージョンのアセンブリにバインドする必要がある場合は、LoadFromなどを使用せずに各アプリに適切なバージョンを使用できるように、それらのビルドに異なるアセンブリバージョンを指定することをお勧めします。
ビルドの出荷
ビルドを出荷するためにそのバージョンを変更することをお勧めするかどうかについては、エンドユーザーに対してバインディングをどのように機能させるかによって異なります。これらのビルドを並べて配置しますか、それともインプレースにしますか？ 2つのビルド間に多くの変更がありますか？彼らは何人かの顧客を壊すつもりですか？それがそれらを壊すことを気にしますか（またはユーザーにあなたの重要な更新を使用するように強制したいですか）？はいの場合は、アセンブリバージョンをインクリメントすることを検討する必要があります。ただし、繰り返しになりますが、これを何度も行うと、ユーザーのディスクに古いアセンブリが散らばる可能性があることを考慮してください。アセンブリのバージョンを変更する場合
ハードコードされたバージョンを新しいバージョンに変更するには、変数をヘッダーファイルのバージョンに設定し、ソースのハードコードを変数に置き換えることをお勧めします。次に、ビルド中にプリプロセッサを実行して、正しいバージョンを配置します。変更によるバグを見つける時間を増やすために、出荷直前ではなく出荷直後にバージョンを変更することをお勧めします。
バージョン管理を定義する1つの方法は、各部分に意味的な意味を与えることです。
- 新しいリリースとの互換性が失われた場合は、N.xからN +1.0に移行します
- 互換性を損なうことのない新機能が追加されたら、N.MからN.M +1に移行します
- バグ修正が追加されたら、N.M.XからN.M.X +1に移行します
上記は単なる例です。自分にとって意味のあるルールを定義する必要があります。しかし、ユーザーがバージョンを見るだけで非互換性が予想されるかどうかをすばやく判断できるのは非常に便利です。
ああ、そしてあなたが思いついたルールを公開することを忘れないでください。そうすれば人々は何を期待すべきかを知ることができます。
セマンティックバージョニングには、これを適用する方法（およびいつ）に関する一連のガイドラインとルールがあります。従うのは非常に簡単で、それはうまくいきます。
私が最初にお勧めするのは、アセンブリバージョンとファイルバージョンの違いを理解することです。残念ながら、.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