Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03253.jsonl.gz/833

Die drei Versions Musketiere werden in der AssemlbyInfo.cs Datei festgelegt. Diese Datei befindet sich im VisualStudio im Verzeichnis Properties.
Während die AssemblyVersion für die Kompatibilitätsprüfung bei Strong-Name Assemblies verwendet werden, haben die zwei anderen Angaben – AssemblyFileVersion und AssemblyInformationalVersion – nur informellen Charakter.
Die Werte können im Eigenschaften (Property) Dialog einer Datei ausgelesen werden. Die dargestellten Werte unterscheiden sich teilweise von den Werten, die über die .NET Klassen Attribute und Application ausgelesen werden können. Während die AssemblyVersion und die AssemblFileVersion aus der Klasse Assembly ermittelt werden (GetCustomAttribute) wird die AssemblyInformationalVersion über die statische Klasse Application.ProductVersion ausgegeben.
Die Matrix stellt dar, wann welche Versionsnummer verwendet werden.
AssemblyVersion
Entspricht der eindeutigen Versionsnummer der Assembly. Wird von derCLR berücksichtigt und in jedem Fall erzeugt. Wenn in der AssemblyInfo.cs kein expliziter Eintrag steht, dann wird die Version auf <ip-pii> gesetzt.
Die Versionsnummer ist immer 4-Stellig und entspricht folgender Struktur:
[Major].[Minor].[Build].[Revision]
Die CLR berücksichtigt bei der Versions-Kompatibilitätsprüfung die Major und die Minor Stellen. Build und Revision gelten als kompatibel.
Die Stellen der Versionsnummern können Zahlenwerte von 0 bis 65 534 annehmen. (65534.65534.65534.65534) Da es sich um einen Zahlenwert handelt, werden führende 0 nicht berücksichtigt.
Mit dem * Pattern kann VisualStudio angeweisen werden, eine Revision- und Buildnummer automatisch zu erzeugen. 1.0.* wird beispielsweise zu 1.0.2979.24869. Grundsätzlich kann das * Zeichen auch auf der Revisionstelle verwendet werden: 1.0.0.*. Allerdings kann daraus eine Fehlerquelle entstehen, da diese Version einerseits nicht mehr eindeutig sein wird und andererseits auch nicht eindeutig aufsteigend inkrementiert wird. Dies kommt aus der Tatsache, wie Microsoft die Build- und Revisionnummer definiert. Der Zahlenwert der Buildnummer entspricht der anzahl Tage seit 1. Januar 2000 und die Revisionnummer entspricht der lokalen Tageszeit. (Was erklärt, warum 1.0.0.* ein fehlerhaftes Pattern ist und nur 1.0.* verwendet werden darf bzw. das Pattern nur für die Build- und Revisionnummer gleichzeitig in Frage kommt). Das Pattern 1.* wird im Gegensatz dazu schon gar nicht akzeptiert.
In der AssemblyInfo können Werte 1- bis 4-Stellig angegeben werden. Die fehlenden Stellen werden zu 0 ergänzt:
4 = <ip-pii>
4.1 = <ip-pii>
4.1.2 = <ip-pii>
<ip-pii> = <ip-pii>
0.1.2 = <ip-pii>
AssemblyFileVersion
Diese Versionsinformation hat keine CLR Relevanz.
Die AssemlbyFileVersion entspricht der Versionsnummer, die im ToolTip des Windows-Dateiexplorer, sowie im Windows-Fileproperties Fenster dargestellt wird:
Es ist zu erkennen, dass die AssemblyVersion eine andere Versionsnummer ausweist. Dieselbe AssemblyFileVersion wird auch dargestellt, wenn in “Other version information” der entsprechende Listeneintrag ausgewählt wird.
In der AssemblyInfo.cs wird eine Zeichenkette (string) für diesen Versionstyp akzeptiert. Aus diesem Grunde kann prinzipiell alles eingegeben werden. Wie hoch die Begrenzung bei der Zeichenanzahl effektiv ist habe ich nicht ausprobiert, allerdings liegt sie bei mehr als 255 Zeichen. Wird eine Zeichenkette eingegeben, die nicht dem Versionsnummernpattern entspricht, dann wird so gut wie möglich die Versionsnummer erzeugt. [assembly: AssemblyFileVersion(“1.FOO.1.BOO”)] ergibt:
Die Folgerung daraus ist: Dass die Informationen prinzipiell auch korrekt ausgelesen werden können (Value von Other version information) aber dass die eigentliche File version wie sie von Windows gehandhabt wird, damit nicht klar kommt und nicht korrekt darstellt. Im Extremfall wird <ip-pii> dargestellt, wenn aus der Versionsangabe nichts schlüssiges geparst werden kann. Beim Parsen von gültigen Versionszahlen verhält es sich wie bei der AssemblyVersion; 1.2 wird beispielsweise zu <ip-pii> (Etc.). Korrekt dargestellt wird jedoch auch beispielsweise 1.0 RC 1, wie man dem 2. Screenshot entnehmen kann.
AssemblyInformationVersion
Diese Versionsinformation hat keine CLR Relevanz.
Die MSDN beschreibt es wie folgt: Zeichenfolgenwert zur Angabe von Versionsinformationen, die von der Common Language Runtime nicht verwendet werden, z. B. die vollständige Produktversionsnummer.
Die Handhabung der AssemblyInformationalVersion in der AssemblyInfo.cs entspricht vollumfänglich derjenigen der AssemblyFileVersion. Die Versionsinformation wird im Eigenschaftendialog ebenfalls dargestellt.
Man kann auf dem 2. Screenshot erkennen, dass sich diese Versionsinformation auch gut dazu eignet, gängige Bezeichnungen für einen Build anzugeben: BETA, RC 1 etc. Oder man kann das Feld für Versionsbezeichner verwenden, die vom gängigen vierstelligen Pattern abweichen wie man es auf dem 3. Bild sieht.
Praxis
Mir erschliesst sich der Sinn der AssemblyFileVersion nicht ganz. Faktisch kann es weggelassen werden und man erreicht damit, dass sie der AssemlyVersion entspricht. Sowohl für die CLR relevant, sowie auch in Windows im Eingeschaftendialog gleich ersichtlich und identisch.
Der Nutzen von AssemblyInformationalVersion kann durchaus gegeben sein. So kann sie verwendet werden, um eine Marketing- Versionsbezeichnung in der Assembly zu speichern, die mit der AssemblyVersion nicht direkt übereinstimmt. (Siehe Beispiel oben, wenn die Versionsnummer ein anderes Format ausweisen muss)
Tool Version Controlled Build
Ein nützliches Tool zum setzen der Versionsnummer aller AssemblyInfo Dateien innerhalb einer VisualStudio Solution. Die Anwendung Version Controlled Build macht slebstverstädnlich nur Sinn, wenn die Buildnummern nicht anschliessen nicht von einem Buildservice (Buildserver) beim Builden neu vergeben werden.