Was sind Unterschiede zwischen Assembly, Assembly und AssemblyInformationalVersion?
https://stackoverflow.com/questions/64602
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Es gibt drei Montageversion Attribute. Was sind Unterschiede? Ist es in Ordnung, wenn ich AssemblyVersion verwenden und den Rest ignorieren?
MSDN sagt:
-
Assembly :
Gibt die Version der Assembly zugeschrieben werden.
-
Assembly :
beauftragt einen Compiler eine bestimmte Versionsnummer für die Win32-Dateiversionsressource zu verwenden. Die Win32-Datei-Version ist nicht das gleiche wie die Assembly Versionsnummer erforderlich.
-
AssemblyInformationalVersion :
Definiert zusätzliche Versionsinformationen für ein Assembly manifest.
Dies ist ein Follow-up href="https://stackoverflow.com/questions/62353/what-are-the-best-practices-for-using-assembly-attributes"> zum
Lösung
Assembly
Wo andere Baugruppen, die Ihre Assembly verweisen aussehen wird. Wenn diese Zahl ändert, müssen andere Baugruppen ihre Verweise auf die Assembly aktualisieren! Die AssemblyVersion erforderlich ist.
Ich verwende das Format: major.minor . Dies würde zu:
[assembly: AssemblyVersion("1.0")]
Assembly
Wird für die Bereitstellung. Sie können für jeden Einsatz, diese Zahl erhöhen. Es wird von Setup-Programmen verwendet. Verwenden Sie es, Baugruppen zu markieren, die die gleiche AssemblyVersion, sondern erzeugt aus verschiedenen Builds.
Unter Windows kann es in den Dateieigenschaften angezeigt werden.
Wenn möglich, lassen Sie es von MSBuild erzeugt werden. Der Assembly ist optional. Wenn nicht angegeben, wird die Assembly verwendet wird.
Ich verwende das Format: major.minor.revision.build , wo ich Revision für Entwicklungsstufe verwenden (Alpha, Beta, RC und RTM), Service Packs und Hotfixes. Dies würde zu:
[assembly: AssemblyFileVersion("1.0.3100.1242")]
AssemblyInformationalVersion
Die Produktversion der Baugruppe. Dies ist die Version, die Sie verwenden würden, wenn sie an Kunden oder für die Anzeige auf Ihrer Website sprechen. Diese Version kann eine Zeichenfolge sein, wie ' 1.0 Release Candidate '.
Die Code-Analyse wird darüber (CA2243) beschweren - berichtet Microsoft (nicht in VS2013 festgelegt).
Die AssemblyInformationalVersion ist optional. Wenn nicht angegeben, wird die Assembly verwendet wird.
Ich verwende das Format: major.minor [Revision als string] . Dies würde zu:
[assembly: AssemblyInformationalVersion("1.0 RC1")]
Andere Tipps
Versionierung von Baugruppen in .NET kann eine verwirrende Aussicht gegeben, dass es derzeit mindestens drei Möglichkeiten, eine Version für die Assembly angeben.
Hier sind die drei Hauptversion bezogene Zusammenstellung 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")]
Nach Konvention sind die vier Teile der Version werden als die Hauptversion , Minor Version , Erstellen und Revision .
Die AssemblyFileVersion soll eindeutig einen Build der einzelnen Baugruppe identifizieren
Normalerweise werden Sie manuell die Dur- und Moll-Assembly stellen Sie die Version der Assembly zu reflektieren, dann das Erstellen erhöhen und / oder Revision jedes Mal, wenn Ihr Build-System die Assembly kompiliert. Die Assembly sollten Sie erlauben eindeutig einen Build der Baugruppe zu identifizieren, so dass Sie es als Ausgangspunkt für das Debuggen von Problemen verwenden können.
Auf meinem aktuellen Projekt haben wir die Build-Server codieren die Änderungsnummer aus unserem Quellcodeverwaltungsrepository in die Build- und Revisions Teile des Assembly. Dies ermöglicht uns, direkt von einer Baugruppe seinen Quellcode abzubilden, für jede Baugruppe von der Build-Server generiert (ohne Etiketten oder Zweige in Quellensteuerung zu verwenden, oder manuell alle Aufzeichnungen veröffentlichten Versionen behalten).
Diese Versionsnummer in der Win32-Version Ressource gespeichert ist und zu sehen, wenn die Windows-Explorer-Eigenschaftsseiten für die Montag sehen.
Die CLR etwa kümmert sich nicht darum, noch die Assembly zu untersuchen.
Die AssemblyInformationalVersion soll die Version des gesamten Produkts zu
Die AssemblyInformationalVersion sollte kohärente Versionierung des gesamten Produkts ermöglichen, die aus vielen Baugruppen bestehen können, die unabhängig voneinander versioniert werden, vielleicht mit Versionierung Politik unterscheiden und möglicherweise entwickelt von unterschiedlichen Teams.
„Zum Beispiel, Version 2.0 eines Produkts kann mehrere Baugruppen enthalten; einer dieser Baugruppen ist gekennzeichnet als Version 1.0, da es sich um eine neue Montage ist dass nicht in der Version 1.0 des Schiffes gleiches Produkt. Typischerweise setzen Sie die Haupt- und Neben Teile dieser Version Zahl darzustellen, die öffentliche Version Ihres Produktes. Dann erhöhen Sie Build- und Revisionsteile jedes Mal verpacken Sie ein komplettes Produkt mit alle ihre Versammlungen.“ - Jeffrey Richter, [CLR via C # (Second Edition)] p. 57
Die CLR etwa kümmert sich nicht darum, noch die AssemblyInformationalVersion zu untersuchen.
Die AssemblyVersion ist die einzige Version der CLR kümmert sich um (aber es kümmert sich um die gesamte AssemblyVersion)
Die Assemblyversion wird von der CLR verwendet stark benannte Baugruppen zu binden. Es ist in der AssemblyDef manifest Metadatentabelle der integrierten Baugruppe und in der AssemblyRef Tabelle jeder Baugruppe gespeichert, die es verweist.
Dies ist sehr wichtig, weil es bedeutet, dass, wenn Sie eine stark benannte Assembly verweisen, Sie sind fest an eine bestimmte Assembly dieser Versammlung gebunden. Die gesamte Assembly muss eine genaue Übereinstimmung für die Bindung sein um erfolgreich zu sein. Zum Beispiel, wenn Sie die Version 1.0.0.0 von einer stark benannte Anordnung zur Buildzeit verweisen, sondern nur Version 1.0.0.1 dieser Versammlung ist zur Laufzeit verfügbar ist, wird nicht verbindlich! (Sie werden dann um diese mit Assembly Umleitung Bindung.)
Verwirrung darüber, ob der gesamte AssemblyVersion muss übereinstimmen. (Ja, es funktioniert.)
Es ist eine wenig Verwirrung um, ob die gesamte Assembly hat eine genaue Übereinstimmung sein, um für eine Baugruppe geladen werden. Manche Menschen sind unter dem falschen Glauben, dass nur die Major undKleinere Teile des Assembly haben für die Bindung an Erfolg, um passen. Dies ist eine vernünftige Annahme, aber es ist letztlich falsch ist (wie von .NET 3.5), und es ist trivial dies für Ihre Version der CLR zu überprüfen. Nur dieser Beispielcode auszuführen.
Auf meinem Rechner die zweite Baugruppe Last versagt, und die letzten beiden Zeilen des Fusionsprotokolls machen es vollkommen 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, die Quelle dieser Verwirrung wahrscheinlich ist, dass Microsoft ursprünglich beabsichtigt ein wenig nachsichtiger auf dieser strengen Anpassung des vollständigen Assembly zu sein, nur um auf der Dur- und Moll-Version Teile passend:
„Wenn eine Assembly geladen, wird die CLR findet automatisch die neueste installierte Service-Version, die entspricht die Major / Minor-Version der Montage angefordert wird.“ - Jeffrey Richter, [CLR via C # (Second Edition)] p. 56
Dies war das Verhalten in Beta 1 der 1,0 CLR, aber diese Funktion vor der Version 1.0 entfernt wurde, und nicht in .NET 2.0 neu Oberfläche verwaltet werden:
„Hinweis: Ich habe gerade Sie beschreiben, wie denken Sie an die Versionsnummern sollten. Leider ist die CLR nicht behandeln Versionsnummern auf diese Weise. [In .NET 2,0], behandeln die CLR eine Versionsnummer als opaken Wert ist, und wenn eine Baugruppe hängt davon ab Version 1.2.3.4 des anderen Baugruppe, versucht die CLR geladen Version 1.2.3.4 nur (es sei denn, eine Bindung Umleitung ist vorhanden). Jedoch, Microsoft plant die Änderungen CLR des Laders in einer zukünftigen Version so dass es lädt die neueste Aufbau / Revision für eine bestimmte Dur / Moll Version einer Assembly . Zum Beispiel, auf einer zukünftigen Version der CLR, wenn die loader versucht Version zu finden 1.2.3.4 einer Baugruppe und Version 1.2.5.0 vorhanden ist, den Lader mit automatisch spätestens abholen Service-Version. Dies wird eine sehr sein willkommene Abwechslung des Laders CLR - I denn man kann es kaum erwarten.“ - Jeffrey Richter, [CLR via C # (Second Edition)] p. 164 (Emphasis Mine)
Da diese Änderung noch nicht umgesetzt worden ist, denke ich, es ist sicher anzunehmen, dass Microsoft hatte auf dieser Absicht-zurück verfolgt, und es ist vielleicht zu spät, dies jetzt zu ändern. Ich habe versucht, um das Netz zu suchen, um herauszufinden, was mit diesen Plänen passiert ist, aber ich konnte keine Antworten finden. Ich wollte noch auf den Boden bekommen.
So mailte ich Jeff Richter und fragte ihn direkt - Ich dachte, wenn jemand wusste, was passiert ist, wäre es ihm
.Er antwortete innerhalb von 12 Stunden, an einem Samstagmorgen nicht weniger, und stellte klar, dass der .NET 1.0 Beta 1 loader diesen ‚automatischen Rollforward‘ Mechanismus der Kommissionierung die neueste Build und Revision einer Baugruppe nach oben, umgesetzt hat, aber dieses Verhalten wurde vor .NET 1.0 ausgeliefert zurückgekehrt. Es wurde später soll diese wieder zu beleben, aber es hat sie nicht vor dem CLR 2.0 ausgeliefert machen in. Dann kam Silverlight, die Priorität für das CLR-Team nahm, so wurde diese Funktionalität weiter verzögert. die meisten Menschen in der Zwischenzeit, die um waren in den Tagen der CLR 1.0 Beta 1 sind seit gegangen, so ist es unwahrscheinlich, dass dies das Licht des Tages sehen, trotz all der harten Arbeit, die bereits in sie gesetzt worden war.
Das aktuelle Verhalten, wie es scheint, ist hier zu bleiben.
Es ist auch erwähnenswert aus meiner Diskussion mit Jeff, dass Assembly erst nach der Entfernung des ‚automatischen Rollforward‘ Mechanismus hinzugefügt wurde - denn nach 1.0 Beta 1, jede Änderung der Assembly eine Bruch Änderung für Ihre Kunden war, es gab dann nirgendwo sicher speichern Sie Ihre Build-Nummer. Assembly ist, dass sicherer Hafen, da wird es nie automatisch von der CLR untersucht. Vielleicht ist es klarer, dass Art und Weise, zwei separate Versionsnummern aufweist, mit separater meanungen, anstatt zu versuchen, dass die Trennung zwischen dem Major / Minor (Bruch) und Build / Revision (non-breaking) Teile des Assembly zu machen.
Fazit: Überlegen Sie genau, wenn Sie Ihre AssemblyVersion ändern
Die Moral ist, dass, wenn Sie Baugruppen Versand erfolgen, die anderen Entwickler Referenzierung werden werden, Sie müssen darüber äußerst vorsichtig sein, wenn Sie das tun (und nicht), um die Assembly dieser Baugruppen zu ändern. Alle Änderungen an der Assembly werden feststellen, dass Anwendungsentwickler bedeutet entweder neu zu kompilieren gegen die neue Version (auf diese AssemblyRef Einträge aktualisieren) oder Montage Bindung Umleitungen verwenden manuell außer Kraft setzen die Bindung.
- Nicht , um die Assemblyversion für eine Wartung Release ändern, die abwärtskompatibel vorgesehen ist.
- , um die Assemblyversion für eine Veröffentlichung ändern, die Sie wissen, hat wichtige Änderungen.
Nehmen Sie einfach einen Blick auf die Version auf mscorlib 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")]
Beachten Sie, dass es die Assembly ist, dass alle interessanten Serviceinformationen enthält (es ist die Revision in dieser Version enthalten, die Sie, was Service Pack Sie sind auf erzählt), mittlerweile die Assembly an einem langweiligen alten 2.0.0.0 behoben. Jede Änderung des Assembly würde jede .NET-Anwendung erzwingen Referenzierung mscorlib.dll neu zu kompilieren gegen die neue Version!
AssemblyVersion ziemlich bleibt intern zu .NET, während AssemblyFileVersion ist, was Windows sieht. Wenn Sie auf die Eigenschaften einer Baugruppe gehen in einem Verzeichnis und wechseln Sie auf die Registerkarte Version sitzt, ist die AssemblyFileVersion, was Sie oben sehen, nach oben werde. Wenn Sie Dateien von Version sortieren, das ist, was von Explorer verwendet wird.
Die AssemblyInformationalVersion Karten auf die „Produktversion“ und soll sein rein „Menschen verwendet“.
AssemblyVersion ist sicherlich die wichtigste, aber ich würde AssemblyFileVersion nicht überspringen, auch nicht. Wenn Sie nicht AssemblyInformationalVersion liefern, der Compiler fügt es für Sie durch die „Revision“ Stück Ihrer Versionsnummer und dem Verlassen des major.minor.build Abstreifen.
AssemblyInformationalVersion und AssemblyFileVersion angezeigt werden, wenn Sie die „Version“ Informationen über eine Datei über den Windows Explorer anzeigen, indem Sie die Dateieigenschaften anzeigen. Diese Attribute erhalten tatsächlich kompiliert in eine VERSION_INFO Ressource, die vom Compiler erstellt wird.
AssemblyInformationalVersion ist die „Produktversion“ Wert. AssemblyFileVersion ist der "Dateiversion" Wert.
Die AssemblyVersion ist spezifisch für .NET-Assemblies und wird von dem .NET-Assembly Loader zu wissen, welche Version einer Assembly laden / bind zur Laufzeit verwendet.
Von diesen ist die einzige, die absolut von .NET erforderlich ist, ist das AssemblyVersion Attribut. Leider kann es auch die meisten Probleme verursachen, wenn sie wahllos verändert, vor allem, wenn Sie Ihre Baugruppen stark sind zu nennen.
diese Frage aktuell zu halten ist es erwähnenswert, dass AssemblyInformationalVersion Hervorhebung von NuGet verwendet wird, und spiegelt die Paketversion: einschließlich Pre-Release-Suffix.
Zum Beispiel eines Assembly von 1.0.3. * Verpackt mit dem asp.net Kern Dotnet-cli
dotnet pack --version-suffix ci-7 src/MyProject
Erzeugt ein Paket mit Version 1.0.3-ci-7, die Sie mit Reflexion inspizieren können mit:
CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
Es ist erwähnenswert, ein paar andere Dinge:
1) Wie in Windows Explorer Eigenschaften-Dialog für die generierte Assembly-Datei gezeigt, gibt es zwei Plätze „Dateiversion“ genannt. Die in der Kopfzeile des Dialogs gesehen zeigt die Assembly, nicht die Assembly.
In der Versionsinformationen Abschnitt gibt es ein weiteres Element „Dateiversion“ genannt. Dies ist, wo man sehen kann, was als die Assembly eingegeben wurde.
2) Assembly ist einfach nur Text. Es muss nicht auf das Nummerierungsschema Einschränkungen entspricht, die Assembly tut (
Darüber hinaus ist es nicht Gegenstand des Wildcard-Ersatz, die Assembly ist. Wenn Sie nur einen Wert von „3.0.1. *“ In der AssemblyInfo.cs, das ist genau das, was in dem anderen Version Information-> Dateiversion Elemente zeigen.
3) Ich weiß nicht, die Auswirkungen auf einen Installateur von etwas anderes als numerischen Dateiversionsnummern, though.
Wenn ein Assembly‘s Assembly geändert wird, Wenn es starken Namen hat, müssen die Referenzierung Baugruppen neu kompiliert werden, da sonst die Montage nicht geladen! Wenn es nicht starke Namen hat, wenn nicht explizit Datei Projekt hinzugefügt, wird es nicht an dem Ausgabeverzeichnis kopiert werden, wenn Build so können Sie je Baugruppen verpassen, vor allem nach dem Ausgabeverzeichnis zu reinigen.
