| 

.NET C# Java Javascript Exception

3
In der AssemblyInfo.cs gibt es zwei Attribute für die Version: AssemblyVersion und AssemblyFileVersion. Was ist denn der Unterschied zwischen den beiden?
21.05.2011
FragenKleister 31 2
2 Antworten
0
21.05.2011
Golo Roden 2,7k 3 9
Nebenbei: Es gibt fast nichts Schlimmeres als diese "maschinell übersetzten" KB-Artikel.
Achso 21.05.2011
Ein Klick auf "Maschinell-übersetzte und englische Version des Artikels nebenander anzeigen" hilft ;-)
Golo Roden 22.05.2011
0
Hi,
kleiner Tipp noch.
Wenn du dein Assembly auslieferst, dann ist es sinnvoll die AssemblyFileVersion auf Major.Minor.Build.Revision zu setzen.
Bei der AssemblyVersion ist es dagegen etwas sinnvoller nur Major.Minor.0.0 zu setzen.
Beim Referenzieren von Assemblies untereinander wird immer die AssemblyVersion herangezogen.
Damit ist es möglich einzelne Assemblies (sofern deine Software aus mehreren eigenen Assemblies besteht) zu aktualisieren (Hotfix etc.), ohne dass alle Assemblies ausgetauscht werden müssen.
Das funktioniert natürlich nur solange Major.Minor bei AssemblyVersion gleich geblieben ist.
Die AssemblyFileVersion kannst du dagegen im Windows Explorer immer schön erkennen. Du kannst Dafür eine extra Spalte einblenden. Außerdem hast du darin dann z.B. auch immer die konkrete Revision-Nummer von deiner Versionsverwaltung.

Gruß Ralf
21.05.2011
ralf.hientzsch 637 1 7
Warum ist es sinnvoller bei der AssemblyVersion die Build und Revision auf 0 zu belassen? Ich finde das nicht so.

Ich halte beide Versionen auf dem gleichen Stand.
gfoidl 21.05.2011
Wenn du mehrere Assemblies hast, die unterschiedliche Funktionen kappseln, dann brauchst Du bei einem Hotfix auch nur das eine Assembly zu tauschen. Neue Funktionalität wird ja über Major Minor angezeigt, und das bleibt gleich.
Wenn die Assemblies aber nicht signiert sind, dann ist es egal.
Wir hatten auch immer AssemblyVersion und AssemblyFileVersion synchron gehalten. Seitdem wir es nicht mehr tun, ist es etwas einfacher für uns.
In diesem Buch http://amzn.to/jhRroA wird es glaube ich auch so empfohlen.
Gruß Ralf
ralf.hientzsch 22.05.2011
Was hat nun ein Hotfix mit der Build-# zu tun?
Die Build-# sollte, so wie der Name suggerieren mag, mit jedem Build (auf dem Build-Server) inkrementiert werden. Somit lässt sich jedes Build einfacher testen und allg. besser verfolgen. => d(Build)/dt != 0 ;-)

Da die FileVersion für .net keinen Nutzen hat halte ich sie gleich wie die AssemblyVersion damit - wie du auch geschrieben hast - im Explorer die "Version" sofort sichtbar ist.
gfoidl 22.05.2011
Hotfix oder wie auch immer hat schon was mit build zu tun. Zumindest wenn du deine Assemblies signierst.
Dann nämlich kannst Du Updates nur von dem Teil vornehmen, der neu gebuildet werden musste. Du musst nicht die gesamte Software aktualisieren.
Hier mal noch ein Artikel, speziell der Absatz Working with strong name.
http://msdn.microsoft.com/en-us/magazine/cc163583.aspx
Grüße Ralf
ralf.hientzsch 22.05.2011
Ist aber ganz streng genommen falsch - geändert hat sich nämlich nicht nur die modifizierte DLL, sondern geändert haben sich auch die Abhängigkeiten. Aber das wäre MIR auch zu viel Erbsenzählerei, insofern stimme ich Dir mit dem .0.0 zu ;-)
Golo Roden 22.05.2011
OK - du redest von signierten und ich von nicht signierten ;-)

Ich finde dass die Build.Revision schon sinnvoll und entsprechend der Bedeutung gesetzt werden soll. In dem von dir angesprochenen Fall eines Hotfixes bei signierten Assemblies kann die Nummer ja gleich bleiben - steht übrigens auch in den von dir verlinkten Artikel so - aber warum es immer 0 sein muss/soll erschließt sich mir nicht.
Darauf ist auch noch keine Antwort gekommen. Ich denke aber dass wir diese Diskussion abschließen können denn alles benötigte wurde mMn geschrieben ;-)
gfoidl 22.05.2011

Stelle deine Assembly-Frage jetzt!