Ci sono buone ragioni per lasciare AssemblyVersion e AssemblyFileVersion partita?

Question

Gendarme ha un AvoidAssemblyVersionMismatchRule con la seguente descrizione:

  

Questa regola controlla che il [AssemblyVersion] partite [AssemblyFileVersion] quando entrambi sono presenti all'interno di un assieme. Avere diversi numeri di versione in entrambi gli attributi possono essere fonte di confusione una volta che l'applicazione viene distribuita.

Ad esempio, questa regola dovrebbe mettere in guardia sul System.dll di Microsoft, che ha i seguenti attributi:

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

Non sono d'accordo con la regola del Gendarme. In seguito sarebbe l'impossibilità di utilizzare uno schema di controllo delle versioni simile a quello utilizzato da Microsoft, che è

• Aggiornamento AssemblyFileVersion su ogni costruzione,
• cambiamento AssemblyVersion solo su un'interfaccia pubblica o comunque grandi cambiamenti,
• assicurarsi che AssemblyVersion e condividere AssemblyFileVersion un prefisso comune,

e credo che questo schema di controllo delle versioni è la ragione per cui il design è stato reso possibile distinguere tra AssemblyVersion e AssemblyFileVersion in primo luogo.

Non riesco a trovare una ragione per la quale costringe sia il montaggio attributi per essere uguale è una buona pratica, ma forse si può! Sarei interessato a vostre opinioni.

Se, infatti, non v'è alcuna buona ragione, io presto suggerisco gli sviluppatori Gendarme di cambiare la regola

  

Questa regola controlla che il [AssemblyVersion] [AssemblyFileVersion] hanno un comune, non prefix vuoto quando entrambi sono presenti all'interno di un assieme.

Answer 1

D'accordo, se dovessero corrispondere, allora non ci sarebbe bisogno di essere due differenti attributi per cominciare! Ma, come la regola dice:. Potrebbe essere fonte di confusione

AssemblyVersion è più simile a "La versione di tutta la vostra applicazione", mentre FileVersion è la versione di un singolo file. Se l'applicazione ha più assembly che hanno diversi cicli di aggiornamento per qualsiasi motivo (ad esempio, plugin che vengono aggiornati separatamente, ma che richiedono una specifica versione principale del ricorso principale), allora si potrebbe dare a ciascuno un FileVersion diversa, ma hanno un AssemblyVersion comune.

Inoltre, a volte, è davvero scomodo per aggiornare l'AssemblyVersion (ad esempio, SharePoint flussi di lavoro e web part sono una valle di lacrime per aggiornare perché si aspettano un AssemblyVersion specificato), quindi non c'è il FileVersion è spesso usato come la versione reale.

Answer 2

D'accordo, questa è una regola stupida. Non si poteva distribuire un aggiornamento bug fix drop-in per un assembly con nome quando si segue. C'è altrimenti alcune ragioni per non fare loro la stessa se effettivamente necessario modificare il [AssemblyVersion]. Forse non dovresti usare quello strumento, quando si risolve un errore. Ironic.

Answer 3

Credo regola senso in molti scenari, poiché il .NET Framework considera essenzialmente due gruppi con lo stesso AssemblyVersion intercambiabili.

Quindi, per esempio, una vecchia versione è nella cache di download non verranno sovrascritti automaticamente da una nuova versione che differiscono solo per AssemblyFileVersion.

Questo può essere fonte di confusione per lo sviluppatore medio, da qui la regola.

Naturalmente, se si sa cosa si sta facendo e capire il trade-off, è possibile ignorare la regola.