Esistono validi motivi per far corrispondere AssemblyVersion e AssemblyFileVersion?

Question

Gendarme ha un AvoidAssemblyVersionMismatchRule con la seguente descrizione:

Questa regola controlla che il [AssemblyVersion] corrisponde alla [AssemblyFileVersion] quando entrambi sono presenti all'interno di un assieme. Avere numeri di versione diversi in entrambi gli attributi può creare confusione una volta che l'applicazione è stata 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. 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 AssemblyFileVersion condivide un prefisso comune,

e penso 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 un motivo per cui forzare entrambi gli attributi di assemblaggio a essere uguali è una buona pratica, ma forse è possibile! Sarei interessato alle vostre opinioni.

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

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

Answer 1

Accetto, se devono corrispondere, non ci dovrebbero essere due attributi diversi per iniziare! Ma come dice la regola: potrebbe essere fonte di confusione.

AssemblyVersion è più simile a "La versione dell'intera applicazione" mentre FileVersion è la versione di un singolo file. Se la tua Applicazione ha più assembly che hanno Cicli di aggiornamento diversi per qualsiasi motivo (ad es. Plugin che vengono aggiornati separatamente ma che richiedono una release principale specifica dell'applicazione principale), allora puoi dare a ognuno una diversa versione di File ma avere una AssemblyVersion comune.

Inoltre, a volte, è davvero sconveniente aggiornare AssemblyVersion (ad esempio, i flussi di lavoro di SharePoint e le web part sono un PITA da aggiornare perché prevedono una specifica AssemblyVersion), quindi la versione di FileVersion viene spesso utilizzata come versione reale.

Answer 2

D'accordo, questa è una regola stupida. Non è possibile distribuire un aggiornamento di correzione di bug drop-in per un assembly con nome sicuro quando lo si segue. Ci sono altrimenti pochi motivi per non renderli uguali se in realtà devi cambiare la [AssemblyVersion]. Forse non dovresti usare quello strumento quando correggi bug. Ironico.

Answer 3

Penso che la regola abbia senso in molti scenari, dal momento che .NET Framework considera essenzialmente intercambiabili due assembly con la stessa AssemblyVersion.

Quindi, ad esempio, una versione precedente è in Download Cache non verrà automaticamente sovrascritta da una nuova versione che differisce solo in AssemblyFileVersion.

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

Ovviamente, se sai cosa stai facendo e capisci i compromessi, puoi ignorare la regola.