3 つのアセンブリ バージョン属性があります。違いは何ですか？AssemblyVersion残りは無視して使ってもいいですか？
MSDN は次のように述べています。
帰属するアセンブリのバージョンを指定します。
Win32 ファイル バージョン リソースに特定のバージョン番号を使用するようにコンパイラに指示します。Win32 ファイルのバージョンは、アセンブリのバージョン番号と同じである必要はありません。
AssemblyInformationalVersion :
アセンブリ マニフェストの追加のバージョン情報を定義します。
これは、アセンブリ属性を使用するためのベスト プラクティスは何ですか?のフォローアップです。
アセンブリ バージョン
アセンブリを参照する他のアセンブリが表示される場所。この数が変更された場合、他のアセンブリはアセンブリへの参照を更新する必要があります! 下位互換性が損なわれる場合にのみ、このバージョンを更新してください。AssemblyVersionが必要です。
私は次の形式を使用します: major.minor (および非常に安定したコードベースの場合はmajor )。これにより、次のようになります。
[assembly: AssemblyVersion("1.3")]
SemVerに厳密に従っている場合、これは、1.0、2.0、3.0 などの主要な変更時にのみ更新することを意味します。
AssemblyFileVersion
展開に使用されます (セットアップ プログラムなど)。展開ごとにこの数を増やすことができます。AssemblyVersion同じものを持っているが、異なるビルドやコードから生成されたアセンブリをマークするために使用します。
Windows では、ファイルのプロパティで表示できます。
AssemblyFileVersion はオプションです。指定しない場合、AssemblyVersion が使用されます。
私は次の形式を使用します: major.minor.patch.build。最初の 3 つの部分はSemVerに従い、最後の部分はビルドサーバーのビルド番号 (ローカル ビルドの場合は 0) を使用します。これにより、次のようになります。
[assembly: AssemblyFileVersion("1.3.2.42")]
System.Versionがこれらの部分にmajor.minor.build.revision!という名前を付けていることに注意してください。
アセンブリ情報バージョン
アセンブリの製品バージョン。これは、顧客と話したり、Web サイトに表示したりするときに使用するバージョンです。このバージョンは、' 1.0 Release Candidate ' のような文字列にすることができます。
はAssemblyInformationalVersionオプションです。指定しない場合、AssemblyFileVersion が使用されます。
私は次の形式を使用します：major.minor[.patch] [文字列としてのリビジョン]。これにより、次のようになります。
[assembly: AssemblyInformationalVersion("1.3 RC1")]
アセンブリのバージョンを指定する方法が現在少なくとも3つあることを考えると、.NETでのアセンブリのバージョン管理は混乱を招く可能性があります。
バージョンに関連する3つの主要なアセンブリ属性は次のとおりです。
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
慣例により、バージョンの4つの部分は、メジャーバージョン、マイナーバージョン、ビルド、およびリビジョンと呼ばれます。
AssemblyFileVersionのビルドを一意に識別することを目的としています通常、アセンブリのバージョンを反映するようにメジャーおよびマイナーAssemblyFileVersionを手動で設定し、ビルドシステムがアセンブリをコンパイルするたびにビルドまたはリビジョン、あるいはその両方をインクリメントします。AssemblyFileVersionを使用すると、アセンブリのビルドを一意に識別できるため、問題をデバッグするための開始点として使用できます。
私の現在のプロジェクトでは、ビルドサーバーにソース管理リポジトリからのチェンジリスト番号をAssemblyFileVersionのビルド部分とリビジョン部分にエンコードさせています。これにより、ビルドサーバーによって生成されたアセンブリについて、アセンブリからそのソースコードに直接マップできます（ソース管理でラベルやブランチを使用したり、リリースされたバージョンのレコードを手動で保持したりする必要はありません）。
このバージョン番号はWin32バージョンリソースに保存されており、アセンブリのWindowsエクスプローラのプロパティページを表示すると表示されます。
CLRは、AssemblyFileVersionを考慮も検査もしません。
AssemblyInformationalVersion、製品全体のバージョンを表すことを目的としていますAssemblyInformationalVersionは、製品全体の一貫したバージョン管理を可能にすることを目的としています。これは、おそらく異なるバージョン管理ポリシーを使用して、独立してバージョン管理され、異なるチームによって開発される可能性のある多くのアセンブリで構成される場合があります。
「たとえば、製品のバージョン2.0には、複数のアセンブリが含まれている場合があります。これらのアセンブリの1つは、同じ製品のバージョン1.0で出荷されなかった新しいアセンブリであるため、バージョン1.0としてマークされています。通常、このバージョン番号のメジャー部分とマイナー部分は、製品のパブリックバージョンを表すように設定します。次に、すべてのアセンブリを含む完全な製品をパッケージ化するたびに、ビルドパーツとリビジョンパーツをインクリメントします。」—ジェフリー・リッチター、[C＃経由のCLR（第2版）]p。57
CLRは、AssemblyInformationalVersionを気にしたり調べたりしません。
AssemblyVersionは、CLRが気にする唯一のバージョンです（ただし、全体を気にしますAssemblyVersion）AssemblyVersionは、厳密に名前が付けられたアセンブリにバインドするためにCLRによって使用されます。これは、ビルドされたアセンブリのAssemblyDefマニフェストメタデータテーブルと、それを参照するアセンブリのAssemblyRefテーブルに格納されます。
これは非常に重要です。これは、厳密に名前が付けられたアセンブリを参照すると、そのアセンブリの特定のAssemblyVersionに緊密にバインドされることを意味します。バインディングが成功するには、AssemblyVersion全体が完全に一致している必要があります。たとえば、ビルド時に厳密に名前が付けられたアセンブリのバージョン1.0.0.0を参照しているが、実行時にそのアセンブリのバージョン1.0.0.1しか使用できない場合、バインドは失敗します。（次に、アセンブリバインディングリダイレクトを使用してこれを回避する必要があります。）
AssemblyVersionが一致する必要があるかどうかについての混乱。（はい、そうです。）アセンブリをロードするために、AssemblyVersion全体が完全に一致する必要があるかどうかについては少し混乱があります。一部の人々は、バインディングが成功するためには、AssemblyVersionのメジャー部分とマイナー部分のみが一致する必要があるという誤った考えの下にあります。これは賢明な仮定ですが、最終的には正しくなく（.NET 3.5以降）、ご使用のバージョンのCLRでこれを確認するのは簡単です。このサンプルコードを実行するだけです。
私のマシンでは、2番目のアセンブリのロードが失敗し、フュージョンログの最後の2行で、理由が完全に明確になっています。
.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral,
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'
=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
(Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
この混乱の原因は、Microsoftが元々、メジャーバージョンとマイナーバージョンの部分のみを照合することにより、完全なAssemblyVersionのこの厳密な照合をもう少し寛大にすることを意図していたためだと思います。
「アセンブリをロードすると、CLRは、要求されているアセンブリのメジャー/マイナーバージョンと一致する最新のインストール済みサービスバージョンを自動的に検出します。」—ジェフリー・リッチター、[C＃経由のCLR（第2版）]p。56
これは1.0CLRのベータ1での動作でしたが、この機能は1.0リリースの前に削除され、.NET2.0で再表示することはできませんでした。
「注：バージョン番号の考え方について説明しました。残念ながら、CLRはバージョン番号をこのように扱いません。[.NET 2.0では]、CLRはバージョン番号を不透明な値として扱い、アセンブリが別のアセンブリのバージョン1.2.3.4に依存している場合、CLRはバージョン1.2.3.4のみを読み込もうとします（バインディングリダイレクトが設定されていない場合） ）。ただし、 Microsoftは、CLRのローダーを将来のバージョンで変更して、アセンブリの特定のメジャー/マイナーバージョンの最新のビルド/リビジョンをロードするようにする予定です。。たとえば、CLRの将来のバージョンで、ローダーがアセンブリのバージョン1.2.3.4を検索しようとしていて、バージョン1.2.5.0が存在する場合、ローダーは最新のサービスバージョンを自動的に取得します。これは、CLRのローダーへの非常に歓迎すべき変更です—私は待ちきれません。」—ジェフリー・リッチター、[C＃経由のCLR（第2版）]p。164（エンファシスマイン）
この変更はまだ実装されていないので、Microsoftがこの意図を後戻りしたと考えるのは安全だと思います。おそらく、今これを変更するには遅すぎます。これらの計画で何が起こったのかをウェブで検索しようとしましたが、答えが見つかりませんでした。私はまだそれの底に行きたかった。
それで私はジェフ・リクターに電子メールを送り、彼に直接尋ねました—誰かが何が起こったのか知っていれば、それは彼だろうと思いました。
彼は土曜日の朝に12時間以内に返信し、.NET 1.0 Beta 1ローダーが、アセンブリの利用可能な最新のビルドとリビジョンを取得するこの「自動ロールフォワード」メカニズムを実装していることを明らかにしましたが、この動作は.NET1.0が出荷される前に元に戻されました。後でこれを復活させることを目的としていましたが、CLR2.0が出荷される前にはうまくいきませんでした。次に、CLRチームが優先するSilverlightが登場したため、この機能はさらに遅れました。その間、CLR 1.0 Beta 1の時代にいたほとんどの人はその後移動しているので、すでに多大な労力を費やしているにもかかわらず、これが日の目を見ることはありそうにありません。
現在の振る舞いは、ここにとどまっているようです。
また、Jeffとの話し合いから、AssemblyFileVersionは「自動ロールフォワード」メカニズムの削除後にのみ追加されたことにも注意してください。1.0Beta1以降、AssemblyVersionへの変更は顧客にとって重大な変更であったためです。ビルド番号を安全に保存する場所がありません。AssemblyFileVersionは、CLRによって自動的に検査されることはないため、安全な場所です。AssemblyVersionのメジャー/マイナー（ブレーク）部分とビルド/リビジョン（非ブレーク）部分を分離しようとするのではなく、2つの別々のバージョン番号を持ち、別々の意味を持つ方が、おそらくその方が明確です。
AssemblyVersion他の開発者が参照するアセンブリを出荷する場合、それらのアセンブリのAssemblyVersionを変更する（変更しない）場合は、細心の注意を払う必要があります。AssemblyVersionを変更すると、アプリケーション開発者は新しいバージョンに対して再コンパイルするか（AssemblyRefエントリを更新するため）、アセンブリバインディングリダイレクトを使用してバインディングを手動でオーバーライドする必要があります。
mscorlibのバージョン属性をもう一度見てください。
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
興味深いサービス情報がすべて含まれているのはAssemblyFileVersionであり（このバージョンのリビジョン部分で、使用しているService Packがわかります）、AssemblyVersionは退屈な古い2.0.0.0に修正されていることに注意してください。AssemblyVersionを変更すると、mscorlib.dllを参照するすべての.NETアプリケーションが新しいバージョンに対して再コンパイルされます。
AssemblyVersionほとんどの場合、.NET の内部にとどまりますAssemblyFileVersionが、Windows が認識しているのは.NET です。ディレクトリにあるアセンブリのプロパティに移動し、バージョン タブに切り替えると、それAssemblyFileVersionが一番上に表示されます。ファイルをバージョンで並べ替えると、これがエクスプローラーで使用されるものになります。
「AssemblyInformationalVersion製品バージョン」にマップされ、純粋に「人間が使用する」ことを意図しています。
AssemblyVersionは確かに最も重要ですが、私もスキップAssemblyFileVersionしません。を指定しない場合AssemblyInformationalVersion、コンパイラは、バージョン番号の「リビジョン」部分を取り除き、major.minor.build を残すことで、それを追加します。
AssemblyInformationalVersionAssemblyFileVersionファイルのプロパティを表示して、Windows エクスプローラーでファイルの「バージョン」情報を表示すると表示されます。VERSION_INFOこれらの属性は、コンパイラによって作成されるリソースに実際にコンパイルされます。
AssemblyInformationalVersionは「製品バージョン」の値です。AssemblyFileVersion「ファイルバージョン」の値です。
これAssemblyVersionは .NET アセンブリに固有であり、実行時にロード/バインドするアセンブリのバージョンを認識するために .NET アセンブリ ローダーによって使用されます。
これらのうち、.NET で絶対に必要なものはAssemblyVersion属性だけです。残念ながら、特にアセンブリに厳密な名前を付けている場合は、無差別に変更すると、ほとんどの問題が発生する可能性があります。
この質問を最新の状態に保つためにAssemblyInformationalVersion、NuGet で使用され、プレリリース サフィックスを含むパッケージ バージョンを反映していることを強調する価値があります。
たとえば、asp.net コア dotnet-cli でパッケージ化された 1.0.3.* の AssemblyVersion
dotnet pack --version-suffix ci-7 src/MyProject
以下を使用してリフレクションで検査できるバージョン 1.0.3-ci-7 のパッケージを生成します。
CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
他のいくつかのことに注意する価値があります。
生成されたアセンブリ ファイルは、Windows エクスプローラの [プロパティ] ダイアログに示されているように、「ファイル バージョン」と呼ばれる場所が 2 つあります。ダイアログのヘッダーに表示されるものは、AssemblyFileVersion ではなく、AssemblyVersion を示しています。
その他のバージョン情報セクションには、「ファイル バージョン」という別の要素があります。ここで、AssemblyFileVersion として入力された内容を確認できます。
AssemblyFileVersion は単なるプレーン テキストです。AssemblyVersion が行う番号付けスキームの制限 (<build> < 65K など) に準拠する必要はありません。必要に応じて、3.2.<リリース タグ テキスト>.<日時> にすることもできます。ビルド システムでトークンを入力する必要があります。
また、AssemblyVersion であるワイルドカード置換の対象外です。AssemblyInfo.cs に "3.0.1.*" の値がある場合、それがまさに [その他のバージョン情報] -> [ファイル バージョン] 要素に表示されます。
ただし、数値のファイル バージョン番号以外を使用した場合のインストーラへの影響はわかりません。
アセンブリの AssemblyVersion が変更されたときに、厳密な名前が付けられている場合は、参照アセンブリを再コンパイルする必要があります。そうしないと、アセンブリが読み込まれません! 厳密な名前がなく、プロジェクト ファイルに明示的に追加されていない場合、ビルド時に出力ディレクトリにコピーされないため、特に出力ディレクトリを消去した後に、依存するアセンブリを見逃す可能性があります。