10

GendarmeにはAvoidAssemblyVersionMismatchRule、次の説明があります。

このルールは、両方がアセンブリ内に存在する場合にが[AssemblyVersion]一致することを確認します。[AssemblyFileVersion]両方の属性に異なるバージョン番号があると、アプリケーションのデプロイ後に混乱する可能性があります。

たとえば、このルールSystem.dllは、次の属性を持つMicrosoft について警告します。

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]

私は憲兵の規則に同意しません。これに従うと、Microsoft が使用するものと同様のバージョン管理スキームを使用できなくなります。

  • AssemblyFileVersionビルドごとに更新し、
  • AssemblyVersion公開インターフェースのみの変更、またはその他の主要な変更、
  • AssemblyVersion共通のプレフィックスをAssemblyFileVersion共有していることを確認してください。

AssemblyVersionそして、このバージョン管理スキームが、そもそもとを区別できるようにした設計上の理由だと思いますAssemblyFileVersion。

両方のアセンブリ属性を強制的に等しくすることが良い方法である理由を思い付くことはできませんが、できるかもしれません! 私はあなたの意見に興味があります。

本当に正当な理由がない場合は、すぐに憲兵の開発者にルールを次のように変更するよう提案します。

このルールは、と がアセンブリ内に存在する場合に、[AssemblyVersion]とが共通の空でないプレフィックスを持っていることを確認します。[AssemblyFileVersion]

4

3 に答える 3

9

一致する必要がある場合は、最初から 2 つの異なる属性を使用する必要はありません。しかし、ルールが言うように、それは混乱を招く可能性があります.

AssemblyVersion は「アプリケーション全体のバージョン」に似ていますが、FileVersion は個々のファイルのバージョンです。アプリケーションに、何らかの理由で更新サイクルが異なる複数のアセンブリがある場合 (たとえば、個別に更新されるが、メイン アプリケーションの特定のメジャー リリースを必要とするプラグインなど)、それぞれに異なる FileVersion を指定できますが、AssemblyVersion は共通です。

また、AssemblyVersion を更新するのが非常に不便な場合もあります (たとえば、SharePoint ワークフローと Web パーツは、AssemblyVersion を指定する必要があるため更新が PITA になります)。そのため、FileVersion が実際のバージョンとして使用されることがよくあります。

于 2010-01-17T16:40:11.710 に答える
4

同意しました、これはばかげた規則です。厳密な名前のアセンブリをフォローすると、ドロップインのバグ修正更新プログラムを展開できませんでした。[AssemblyVersion] を実際に変更する必要がある場合、それらを同じにしない理由はほとんどありません。おそらく、バグを修正するときにそのツールを使用することは想定されていません。皮肉。

于 2010-01-17T16:35:35.010 に答える
0

.NET Framework は基本的に同じ AssemblyVersion を持つ 2 つのアセンブリを交換可能と見なすため、この規則は多くのシナリオで理にかなっていると思います。

したがって、たとえば、ダウンロード キャッシュにある古いバージョンは、AssemblyFileVersion のみが異なる新しいバージョンによって自動的に上書きされることはありません。

これは平均的な開発者にとっては混乱を招く可能性があるため、ルールになっています。

もちろん、自分が何をしているのかを知っていて、トレードオフを理解していれば、ルールを無視できます。

于 2010-01-18T08:27:37.823 に答える