Gibt es gute Gründe für die Assembly und Assembly Spiel im Stich gelassen?

Question

Gendarme hat eine AvoidAssemblyVersionMismatchRule mit der folgenden Beschreibung:

  

Diese Regel überprüft, dass die [AssemblyVersion] Streichhölzer die [AssemblyFileVersion] wenn beide innerhalb einer Baugruppe vorhanden sind. unterschiedliche Versionsnummern in beiden Attributen kann verwirrend sein, wenn die Anwendung bereitgestellt wird.

Zum Beispiel dieser Regel würde auf Microsofts System.dll warnen, die folgenden Attribute:

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

Ich bin nicht einverstanden mit Gendarme-Regel. Im Anschluss an es unmöglich machen würde, Sie verwenden ein Versionsschema ähnlich dem von Microsoft verwendet, die

ist

• update AssemblyFileVersion auf jedem Build,
• Änderung AssemblyVersion nur auf öffentliche Schnittstelle oder sonst große Veränderungen,
• stellen Sie sicher, dass AssemblyVersion und AssemblyFileVersion teilen sich ein gemeinsames Präfix,

und ich denke, das Versionsschema ist das Design Grund, warum es wurde möglich, zwischen AssemblyVersion und AssemblyFileVersion in erster Linie zu unterscheiden.

Ich kann nicht mit einem Grund kommen, warum zwingt beide Montage-Attribute eine gute Praxis, dass sie gleich ist, aber vielleicht können Sie! Ich würde Ihre Meinung interessiert.

Wenn in der Tat gibt es keinen guten Grund, ich werde bald die Gendarme Entwickler schlägt die Regel zu ändern

  

Diese Regel überprüft, dass die [AssemblyVersion] und [AssemblyFileVersion] ein gemeinsames haben, nicht entleeren prefix , wenn beide innerhalb einer Baugruppe vorhanden sind.

Answer 1

zustimmen, wenn sie übereinstimmen sollten dann gäbe es nicht erforderlich, zwei verschiedene Attribute zu sein, mit zu beginnen! Aber wie die Regel sagt:. Es könnte verwirrend sein

Assembly ist mehr wie „Die Version Ihrer gesamten Anwendung“, während Fileversion der Version einer einzelnen Datei. Wenn die Anwendung über mehrere Baugruppen, die unterschiedliche Aktualisierungszyklen aus irgendeinem Grund haben (zB Plugins, die separat aktualisiert werden, aber die eine spezifische Hauptversion der Hauptanwendung erforderlich ist), dann könnten Sie geben jeweils eine andere Fileversion, sondern eine gemeinsame Assembly haben.

Auch, manchmal ist es wirklich unbequem, die Assemblyversion zu aktualisieren (zB Sharepoint-Workflows und Webparts sind ein PITA zu aktualisieren, weil sie eine bestimmte Assembly erwarten), so gibt die Fileversion oft als die reale Version verwendet wird.

Answer 2

Zugegeben, das ist eine dumme Regel. Sie konnten nicht ein Drop-in Bugfix-Update für eine starke Assembly mit dem Namen bereitstellen, wenn Sie ihm folgen. Es gibt sonst einige Gründe, sie nicht das gleiche zu machen, wenn Sie tatsächlich die [Assembly] ändern. Vielleicht sind Sie nicht an, dass Werkzeug verwenden, wenn Sie Fehler zu beheben. Ironic.

Answer 3

Ich denke, die Regel Sinn in vielen Szenarien macht, da im Wesentlichen die .NET Framework zwei Baugruppen mit derselben Assembly hält austauschbar sein.

So zum Beispiel eine alte Version im Download-Cache wird nicht automatisch durch eine neue Version nur in Assembly unterschiedlichen überschreibt.

Dies kann für die durchschnittlichen Entwickler verwirrend sein, daher die Regel.

Natürlich, wenn Sie wissen, was Sie tun und die Trade-offs zu verstehen, können Sie die Regel ignorieren.