このページhttp://support.microsoft.com/kb/556041は、AssemblyVersion と AssemblyFile バージョンの違いを明確に説明しています。
また、このページには、両方をいつ変更するかが記載されています。まだ質問がありますが、
アセンブリ バージョン ver 1 でドット ネット コンポーネントを提供したとします。頻繁に変更されるため、AssemblyFileVersion のみを変更しています。次に、新しいコンポーネントをコピーしています。CLR がアセンブリのバージョンを変更しない方法を知る方法です。両方のコンポーネント (古いものと新しいもの) が同じ assemblyVersions を持つようになったので、CLR はどのコンポーネントを使用するかをどのように識別するのでしょうか?
CLR は[AssemblyFileVersion] に注意を払いません。これは単なる参照番号です。たとえば、Windows エクスプローラーで確認できます。通常のアプローチでは、出荷前にアセンブリを再構築するときに値を増やします。マイナーなバグ修正を分離しておく方法。
大きな犬は [AssemblyVersion] で、CLR はこれに多くの注意を払っています。実行時にアセンブリが見つかった場合、そのバージョンは、プログラムをビルドした参照アセンブリと一致する必要があります。そうでない場合、CLR は DLL Hell が発生したと見なし、プログラムの実行を拒否します。GAC にとっても重要です。同じ名前で異なるバージョンの複数の DLL を格納できます。これはDLL Hell対策です。
そのため、アセンブリのパブリック インターフェイスで重大な変更を行う場合は、[AssemblyVersion] をインクリメントすることが不可欠です。アセンブリを使用するプログラムが再コンパイルされていない場合、または変更に対処するために調整されていない場合、そのプログラムが失敗する可能性があります。そのため、ユーザーには、診断が難しい例外ではなく、明確なエラー メッセージが表示されます。さらに悪いことに、例外はまったくなく、診断できない不正行為にすぎません。
[AssemblyVersion] がインクリメントされることを確認するのはあなた次第です。実際にそうするのはそれほど簡単ではありません。多くの企業は、変更がなかったり、変更が壊れていなくても、更新をリリースするときに [AssemblyVersion] を自動的にインクリメントします。属性にアスタリスク (*) を使用することにより、.NET でサポートされます。その方が安全です。ただし、依存プログラムも更新するという追加の要件があります。これは確かに珍しいことではありません。