Frage Was sind die Unterschiede zwischen AssemblyVersion, AssemblyFileVersion und AssemblyInformationalVersion?


Es gibt drei Assemblyversionsattribute. Was sind Unterschiede? Ist es in Ordnung, wenn ich benutze AssemblyVersion und den Rest ignorieren?


MSDN sagt:

  • AssemblyVersion:

    Gibt die Version der Assembly an, die zugeordnet wird.

  • AssemblyFileVersion:

    Weist einen Compiler an, eine bestimmte Versionsnummer für die Win32-Dateiversionsressource zu verwenden. Die Win32-Dateiversion muss nicht mit der Versionsnummer der Assembly übereinstimmen.

  • AssemblyInformationaleVersion:

    Definiert zusätzliche Versionsinformationen für ein Assemblymanifest.


Dies ist ein Follow-up zu Was sind die Best Practices für die Verwendung von Baugruppenattributen?


766
2017-09-15 16:47


Ursprung


Antworten:


AssemblyVersion

Wo andere Baugruppen, die auf Ihre Baugruppe verweisen, aussehen werden. Ändert sich diese Zahl, müssen andere Baugruppen ihre Referenzen auf Ihre Baugruppe aktualisieren! Das AssemblyVersion Wird benötigt.

Ich benutze das Format: Major.Minor. Dies würde zu folgenden Ergebnissen führen:

[assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Wird für die Bereitstellung verwendet. Sie können diese Anzahl für jede Bereitstellung erhöhen. Es wird von Setup-Programmen verwendet. Verwenden Sie es, um Baugruppen zu markieren, die das gleiche haben AssemblyVersion, sondern werden aus verschiedenen Builds generiert.

In Windows kann es in den Dateieigenschaften angezeigt werden.

Wenn möglich, lass es von MSBuild generiert werden. Die AssemblyFileVersion ist optional. Wenn nicht angegeben, wird AssemblyVersion verwendet.

Ich benutze das Format: major.minor.revision.build, wo ich eine Revision für die Entwicklungsphase (Alpha, Beta, RC und RTM), Service Packs und Hotfixes verwende. Dies würde zu folgenden Ergebnissen führen:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationaleVersion

Die Produktversion der Baugruppe. Dies ist die Version, die Sie verwenden würden, wenn Sie mit Kunden sprechen oder auf Ihrer Website angezeigt werden. Diese Version kann eine Zeichenfolge sein, wie '1.0 Freigabekandidat".

Die Code-Analyse wird sich darüber beschweren (CA2243) - an Microsoft gemeldet (nicht in VS2013 behoben).

Das AssemblyInformationalVersion es ist optional. Wenn nicht angegeben, wird AssemblyFileVersion verwendet.

Ich benutze das Format: major.minor [Revision als String]. Dies würde zu folgenden Ergebnissen führen:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

822
2017-09-15 17:46



Versionierung von Assemblys in .NET kann eine verwirrende Perspektive sein, da derzeit mindestens drei Möglichkeiten zur Angabe einer Version für Ihre Assembly bestehen.

Hier sind die drei wichtigsten versionsbezogenen Assembly-Attribute:

// 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")]

Per Konvention werden die vier Teile der Version als die bezeichnet Hauptversion, Nebenversion, Bauen, und Revision.

Das AssemblyFileVersion soll einen Build des. eindeutig identifizieren individuelle Montage

In der Regel legen Sie die Major AssemblyFileVersion und die Minor AssemblyFileVersion manuell so fest, dass sie die Version der Assembly widerspiegeln, und erhöhen dann Build und / oder Revision jedes Mal, wenn das Buildsystem die Assembly kompiliert. Die AssemblyFileVersion sollte Ihnen ermöglichen, ein Build der Assembly eindeutig zu identifizieren, sodass Sie es als Ausgangspunkt für das Debuggen von Problemen verwenden können.

In meinem aktuellen Projekt haben wir den Build-Server, der die Änderungslistennummer von unserem Quellcodeverwaltungsrepository in die Build- und Revisionsteile der AssemblyFileVersion codiert. Dies ermöglicht uns, direkt von einer Assembly auf ihren Quellcode für jede vom Build-Server generierte Assembly abzubilden (ohne die Verwendung von Labels oder Zweigen in der Quellcodeverwaltung oder die manuelle Speicherung von Datensätzen veröffentlichter Versionen).

Diese Versionsnummer wird in der Win32-Versionsressource gespeichert und kann angezeigt werden, wenn die Windows Explorer-Eigenschaftenseiten für die Assembly angezeigt werden.

Die CLR interessiert sich nicht für die AssemblyFileVersion und untersucht sie auch nicht.

Das AssemblyInformationalVersion soll die Version Ihres gesamten Produkts darstellen

Die AssemblyInformationalVersion soll eine kohärente Versionierung des gesamten Produkts ermöglichen, das aus vielen Assemblys bestehen kann, die unabhängig voneinander versioniert sind, möglicherweise unterschiedliche Versionierungsrichtlinien haben und möglicherweise von verschiedenen Teams entwickelt wurden.

"Zum Beispiel Version 2.0 eines Produkts   könnte mehrere Baugruppen enthalten; ein   dieser Baugruppen ist als markiert   Version 1.0, da es sich um eine neue Assembly handelt   das wurde nicht in der Version 1.0 der   gleiches Produkt. In der Regel legen Sie die Option fest   Haupt- und Nebenbestandteile dieser Version   Nummer zur Darstellung der öffentlichen Version   von Ihrem Produkt. Dann erhöhen Sie   die Build- und Revisionsteile jedes Mal   Sie verpacken ein komplettes Produkt mit   alle seine Versammlungen. "              - Jeffrey Richter, [CLR über C # (zweite Ausgabe)] p. 57

Die CLR interessiert sich nicht für die AssemblyInformationalVersion und untersucht sie auch nicht.

Das AssemblyVersion ist die einzige Version, an der sich die CLR interessiert (aber sie kümmert sich um das Ganze AssemblyVersion)

Die AssemblyVersion wird von der CLR verwendet, um an stark benannte Assemblies zu binden. Es wird in der AssemblyDef-Manifest-Metadatentabelle der erstellten Assembly und in der AssemblyRef-Tabelle jeder Assembly, die darauf verweist, gespeichert.

Dies ist sehr wichtig, da dies bedeutet, dass Sie beim Verweis auf eine stark benannte Assembly fest an eine bestimmte AssemblyVersion dieser Assembly gebunden sind. Die gesamte AssemblyVersion muss genau übereinstimmen, damit die Bindung erfolgreich ist. Wenn Sie z. B. zur Build-Zeit auf Version 1.0.0.0 einer Assembly mit starkem Namen verweisen, aber zur Laufzeit nur Version 1.0.0.1 dieser Assembly verfügbar ist, schlägt die Bindung fehl. (Sie müssen dann mit diesem umgehen Baugruppenumleitung.)

Verwirrung darüber, ob das Ganze AssemblyVersion muss übereinstimmen. (Ja tut es.)

Es gibt ein wenig Verwirrung darüber, ob die gesamte AssemblyVersion genau übereinstimmen muss, damit eine Assembly geladen werden kann. Manche Leute glauben, dass nur der Major- und der Minor-Teil der AssemblyVersion übereinstimmen müssen, damit die Bindung erfolgreich ist. Dies ist eine vernünftige Annahme, ist jedoch letztendlich falsch (ab .NET 3.5), und es ist trivial, dies für Ihre Version der CLR zu überprüfen. Einfach ausführen Dieser Beispielcode.

Auf meiner Maschine schlägt die zweite Montage-Ladung fehl, und die letzten beiden Zeilen des Fusionsprotokolls machen völlig klar, warum:

.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.

Ich denke, dass die Quelle dieser Verwirrung wahrscheinlich darin liegt, dass Microsoft ursprünglich beabsichtigt hatte, bei dieser strengen Übereinstimmung der vollständigen AssemblyVersion etwas nachsichtiger zu sein, indem nur die Major- und Minor-Versionsteile abgeglichen wurden:

"Wenn eine Baugruppe geladen wird, findet die CLR automatisch die neuesten   Service-Version installiert, dass   entspricht der Haupt- / Nebenversion des   Montage angefordert. "               - Jeffrey Richter, [CLR über C # (zweite Ausgabe)] p. 56

Dies war das Verhalten in Beta 1 der 1.0 CLR, jedoch wurde diese Funktion vor der 1.0-Version entfernt und konnte in .NET 2.0 nicht wiederhergestellt werden:

"Anmerkung: Ich habe gerade beschrieben, wie Sie   sollte an Versionsnummern denken.   Leider behandelt die CLR nicht   Versionsnummern auf diese Weise. [In .NET   2.0] behandelt die CLR eine Versionsnummer als undurchsichtigen Wert und wenn eine Assembly   hängt von der Version 1.2.3.4 eines anderen ab   Assembly versucht die CLR zu laden   Nur Version 1.2.3.4 (außer eine verbindliche   Umleitung ist vorhanden). Jedoch,    Microsoft hat vor, die   CLR Loader in einer zukünftigen Version so   dass es das Neueste lädt   Build / Revision für eine gegebene Dur / Moll   Version einer Baugruppe. Beispielsweise,   auf einer zukünftigen Version der CLR, wenn die   loader versucht die Version zu finden   1.2.3.4 einer Baugruppe und Version 1.2.5.0 existiert, nimmt der Lader automatisch den letzten auf   Wartungsversion. Das wird ein sehr   willkommene Änderung zum Lader der CLR - ich   denn man kann nicht warten. "               - Jeffrey Richter, [CLR über C # (zweite Ausgabe)] p. 164 (Hervorhebung   Bergwerk)

Da diese Änderung noch nicht implementiert wurde, kann man davon ausgehen, dass Microsoft diese Absicht zurück verfolgt hat, und es ist vielleicht zu spät, dies jetzt zu ändern. Ich habe versucht, im Internet zu suchen, um herauszufinden, was mit diesen Plänen passiert ist, aber ich konnte keine Antworten finden. Ich wollte immer noch auf den Grund gehen.

Also schrieb ich Jeff Richter eine E-Mail und fragte ihn direkt - ich dachte, wenn jemand wüsste, was passiert ist, würde er es sein.

Er antwortete innerhalb von 12 Stunden, an einem Samstagmorgen nicht weniger, und stellte klar, dass der .NET 1.0 Beta 1 Loader diesen "automatischen Roll-Forward" -Mechanismus implementierte, um die neueste verfügbare Build und Revision einer Assembly abzurufen, aber dieses Verhalten war rückgängig gemacht, bevor .NET 1.0 ausgeliefert wurde. Später sollte es wiederbelebt werden, aber vor der Auslieferung der CLR 2.0 kam es nicht dazu. Dann kam Silverlight, das für das CLR-Team Priorität hatte, weshalb sich diese Funktionalität weiter verzögerte. In der Zwischenzeit sind die meisten Leute, die in den Tagen von CLR 1.0 Beta 1 dabei waren, inzwischen weitergezogen, so dass es unwahrscheinlich ist, dass trotz der harten Arbeit, die bereits in diese Phase gesteckt wurde, dies das Licht der Welt erblicken wird.

Das augenblickliche Verhalten scheint hier zu bleiben.

Es ist auch erwähnenswert aus meiner Diskussion mit Jeff, dass AssemblyFileVersion nur hinzugefügt wurde, nachdem der "automatische Roll-Forward" -Mechanismus entfernt wurde - denn nach 1.0 Beta 1 war jede Änderung an der AssemblyVersion eine bahnbrechende Änderung für Ihre Kunden nirgends, um deine Build-Nummer sicher zu speichern. AssemblyFileVersion ist dieser sichere Port, da er nie automatisch von der CLR überprüft wird. Vielleicht ist es auf diese Weise klarer, da es zwei getrennte Versionsnummern mit unterschiedlichen Bedeutungen gibt, anstatt zu versuchen, diese Trennung zwischen den Major / Minor (breaking) und den Build / Revisions (non-breaking) Teilen der AssemblyVersion vorzunehmen.

Die Quintessenz: Denken Sie sorgfältig darüber nach, wenn Sie Ihre ändern AssemblyVersion

Wenn Sie Baugruppen versenden, auf die andere Entwickler verweisen, müssen Sie sehr vorsichtig sein, wenn Sie die Assemblyversion dieser Assemblys ändern (und nicht ändern). Änderungen an der AssemblyVersion führen dazu, dass Anwendungsentwickler entweder erneut mit der neuen Version kompilieren müssen (um diese AssemblyRef-Einträge zu aktualisieren) oder mithilfe von Assembly-Bindungsumleitungen die Bindung manuell überschreiben.

  • Unterlassen Sie Ändern Sie die AssemblyVersion für eine Wartungsversion, die abwärtskompatibel sein soll.
  • Machen Ändern Sie die Assemblyversion für eine Version, von der Sie wissen, dass sie Änderungen enthält.

Sehen Sie sich die Versionsattribute auf mscorlib noch einmal an:

// 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")]

Beachten Sie, dass es die AssemblyFileVersion ist, die alle interessanten Wartungsinformationen enthält (es ist der Revisionsteil dieser Version, der Ihnen sagt, auf welchem ​​Service Pack Sie sind), während die AssemblyVersion zu einem langweiligen alten 2.0.0.0 behoben ist. Jede Änderung an der AssemblyVersion würde jede .NET-Anwendung, die auf mscorlib.dll verweist, dazu zwingen, gegen die neue Version zu kompilieren!


541
2018-04-29 12:01



AssemblyVersion bleibt ziemlich intern in .NET, während AssemblyFileVersion ist, was Windows sieht. Wenn Sie zu den Eigenschaften einer Baugruppe wechseln, die sich in einem Verzeichnis befindet, und zur Registerkarte "Version" wechseln, wird die AssemblyFileVersion Das siehst du oben. Wenn Sie Dateien nach Version sortieren, wird dies vom Explorer verwendet.

Das AssemblyInformationalVersion bildet auf die "Produktversion" ab und soll rein "menschenbezogen" sein.

AssemblyVersion ist sicherlich der wichtigste, aber ich würde nicht überspringen AssemblyFileVersion, entweder. Wenn Sie nicht liefern AssemblyInformationalVersionDer Compiler fügt es für Sie hinzu, indem Sie das Stück "revision" Ihrer Versionsnummer entfernen und die Datei major.minor.build belassen.


39
2017-09-15 16:51



AssemblyInformationalVersion und AssemblyFileVersion werden angezeigt, wenn Sie die Informationen zu "Version" in einer Datei über Windows Explorer anzeigen, indem Sie die Dateieigenschaften anzeigen. Diese Attribute werden tatsächlich in a kompiliert VERSION_INFO Ressource, die vom Compiler erstellt wird.

AssemblyInformationalVersion ist der Wert "Produktversion". AssemblyFileVersion ist der Wert "Dateiversion".

Das AssemblyVersion ist spezifisch für .NET-Assemblys und wird vom .NET-Assemblyloader verwendet, um zu ermitteln, welche Version einer Assembly zur Laufzeit geladen / gebunden werden soll.

Von diesen ist die einzige, die absolut von .NET erforderlich ist AssemblyVersion Attribut. Leider kann es auch die meisten Probleme verursachen, wenn es sich wahllos ändert, besonders wenn Sie Ihre Assemblies stark benennen.


21
2017-09-15 16:52



Es ist erwähnenswert, einige andere Dinge:

1) Wie im Dialogfeld Eigenschaften von Windows Explorer für die generierte Assemblydatei gezeigt, gibt es zwei Stellen, die "Dateiversion" genannt werden. Die in der Kopfzeile des Dialogfelds angezeigte zeigt die AssemblyVersion, nicht die AssemblyFileVersion.

Im Abschnitt Andere Versionsinformationen gibt es ein weiteres Element namens "File Version". Hier können Sie sehen, was als AssemblyFileVersion eingegeben wurde.

2) AssemblyFileVersion ist nur einfacher Text. Es muss nicht den Einschränkungen des Nummerierungsschemas entsprechen, das AssemblyVersion ausführt (<build> <65K, z. B.). Es kann 3.2 sein. <Release tag text>. <Datetime>, wenn Sie möchten. Ihr Build-System muss die Tokens ausfüllen.

Außerdem unterliegt es nicht dem Platzhalterersatz AssemblyVersion. Wenn Sie in der Datei AssemblyInfo.cs nur den Wert "3.0.1. *" Haben, wird dies genau im Element Andere Versionsinformationen-> Dateiversion angezeigt.

3) Ich weiß nicht, wie sich ein Installer auf etwas anderes als numerische Dateiversionsnummern auswirkt.


7
2017-11-27 22:51



Um diese Frage aktuell zu halten, sollte dies hervorgehoben werden AssemblyInformationalVersion wird von NuGet verwendet und spiegelt die Paketversion einschließlich eines Vorab-Suffix.

Zum Beispiel eine AssemblyVersion von 1.0.3. * Verpackt mit dem asp.net Core dotnet-cli

dotnet pack --version-suffix ci-7 src/MyProject

Erzeugt ein Paket mit der Version 1.0.3-ci-7, das Sie mit Reflektion unter Verwendung von überprüfen können:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

6
2018-06-23 04:51



Wenn die Assemblyversion einer Assembly geändert wird, Wenn es einen starken Namen hat, müssen die referenzierenden Assemblys neu kompiliert werden, andernfalls lädt die Assembly nicht! Wenn es keinen starken Namen hat, wird es, wenn es nicht explizit zur Projektdatei hinzugefügt wird, beim Erstellen nicht in das Ausgabeverzeichnis kopiert, so dass Sie abhängige Assemblys vermissen können, besonders nach dem Löschen des Ausgabeverzeichnisses.


2
2018-02-17 05:21