it-swarm-eu.dev

Jaké jsou rozdíly mezi AssemblyVersion, AssemblyFileVersion a AssemblyInformationalVersion?

Existují tři atributy verze Assembly. Jaké jsou rozdíly? Je v pořádku, když používám AssemblyVersion a zbytek ignoruji?


MSDN říká:

  • AssemblyVersion :

    Určuje verzi přiřazené sestavy.

  • AssemblyFileVersion :

    Nařídí kompilátoru, aby používal konkrétní číslo verze pro prostředek verze souboru Win32. Verze souboru Win32 nemusí být stejná jako číslo verze shromáždění.

  • AssemblyInformationalVersion :

    Definuje další informace o verzi manifestu Assembly.


Toto je pokračování Jaké jsou doporučené postupy pro použití atributů Assembly?

824
Jakub Šturc

AssemblyVersion

Kde budou vypadat další sestavy, které odkazují na vaši sestavu. Pokud se toto číslo změní, musí ostatní sestavy aktualizovat své odkazy na vaše shromáždění! AssemblyVersion je povinné.

Používám formát: major.minor . Výsledkem by bylo:

[Assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Používá se k nasazení. Toto číslo můžete zvýšit pro každé nasazení. Používá se v instalačních programech. Slouží k označení sestav, které mají stejné AssemblyVersion, ale jsou generovány z různých sestavení.

Ve Windows jej lze zobrazit ve vlastnostech souboru.

Pokud je to možné, nechte jej vygenerovat MSBuild. AssemblyFileVersion je volitelná. Pokud není uveden, použije se AssemblyVersion.

Používám formát: major.minor.revision.build , kde používám revizi pro vývojovou fázi (Alpha, Beta, RC a RTM), aktualizace Service Pack a hot opravy. Výsledkem by bylo:

[Assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

Verze produktu sestavy. Toto je verze, kterou byste použili při rozhovoru se zákazníky nebo k zobrazení na vašem webu. Tato verze může být řetězec, například ' 1.0 Release Candidate '.

Analýza kódu si na to bude stěžovat (CA2243) - nahlášeno společnosti Microsoft (není opraveno ve VS2013).

AssemblyInformationalVersion je volitelné. Pokud není uveden, použije se AssemblyFileVersion.

Používám formát: major.minor [revize jako řetězec] . Výsledkem by bylo:

[Assembly: AssemblyInformationalVersion("1.0 RC1")]
871

Verze verzí sestav v .NET může být matoucí vyhlídka, protože v současné době existují alespoň tři způsoby, jak určit verzi pro vaši sestavu.

Zde jsou tři hlavní atributy sestavení související s verzí:

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

Podle konvence jsou čtyři části verze označovány jako hlavní verze , drobná verze , Sestavení a Revize .

Účelem AssemblyFileVersion je jednoznačně identifikovat sestavení jednotlivé sestavy

Obvykle ručně nastavíte Major a Menší AssemblyFileVersion tak, aby odrážel verzi Shromáždění, a pak pokaždé, když systém sestavení sestaví shromáždění, zvýšíte sestavení a/nebo revizi. AssemblyFileVersion by vám měla umožnit jedinečně identifikovat sestavení sestavení, abyste ji mohli použít jako výchozí bod pro odladění jakýchkoli problémů.

V mém aktuálním projektu máme server sestavení zakódovat číslo seznamu změn z našeho zdroje řízení zdroje do částí Sestavit a Revize v AssemblyFileVersion. To nám umožňuje mapovat přímo ze sestavy na jeho zdrojový kód, pro jakoukoli sestavu generovanou serverem buildu (bez použití štítků nebo větví v řízení zdroje nebo ručního uchovávání záznamů o uvolněných verzích).

Toto číslo verze je uloženo ve zdroji verze Win32 a je vidět při prohlížení stránek vlastností Průzkumníka Windows pro sestavení.

CLR se nestará ani nezkoumá AssemblyFileVersion.

Účelem AssemblyInformationalVersion je představovat verzi celého vašeho produktu

Účelem AssemblyInformationalVersion je umožnit koherentní verzování celého produktu, které se může skládat z mnoha sestav, které jsou nezávisle verzovány, možná s odlišnými politikami verzování, a potenciálně vyvíjené různými týmy.

„Například verze 2.0 produktu může obsahovat několik sestav; jedna z těchto sestav je označena jako verze 1.0, protože se jedná o novou sestavu, která nebyla dodána ve verzi 1.0 stejného produktu. Obvykle nastavíte hlavní a vedlejší části tohoto čísla verze tak, aby představovalo veřejnou verzi vašeho produktu. Pak zvětšujete součásti sestavení a revize pokaždé, když zabalíte kompletní produkt se všemi jeho sestavami. “- Jeffrey Richter, [CLR via C # (Druhé vydání)] s. 1. Jeffrey Richter. 57

CLR se nestará ani nezkoumá AssemblyInformationalVersion.

AssemblyVersion je jedinou verzí, o kterou CLR záleží (ale záleží na celém AssemblyVersion)

The AssemblyVersion používá CLR k navázání na silně pojmenované sestavy. Je uložen v tabulce manifestu metadat sestavené sestavy a v tabulce AssemblyRef každé sestavy, která na ni odkazuje.

To je velmi důležité, protože to znamená, že když odkazujete na silně pojmenované shromáždění, jste pevně vázáni na konkrétní sestaveníVersion tohoto shromáždění. Aby byla vazba úspěšná, musí být celá AssemblyVersion přesně shodná. Pokud například při sestavení odkazujete na verzi 1.0.0.0 silně pojmenovaného Assembly, ale za běhu je k dispozici pouze verze 1.0.0.1 tohoto Assembly, vazba se nezdaří! (Poté budete muset tento problém vyřešit pomocí Přesměrování vazby sestavy .)

Zmatek ohledně toho, zda se musí shodovat celé AssemblyVersion. (Ano.)

Existuje trochu zmatek ohledně toho, zda musí být celá AssemblyVersion přesná shoda, aby mohla být načtena sestava. Někteří lidé jsou pod falešným přesvědčením, že pouze hlavní a minoritní části AssemblyVersion se musí shodovat, aby vazba uspěla. Toto je rozumný předpoklad, nicméně je to nakonec nesprávné (od verze .NET 3.5) a je triviální ověřit to pro vaši verzi CLR. Stačí spustit tento ukázkový kód .

Na mém stroji selhalo druhé zatížení sestavy a poslední dva řádky protokolu fúze jasně ukazují proč:

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

Myslím si, že zdroj tohoto zmatku je pravděpodobně proto, že Microsoft původně zamýšlel být o něco mírnější v tomto přísném přizpůsobení úplné AssemblyVersion tím, že by se přizpůsobil pouze v částech Major a Menší verze:

"Při načítání sestavy CLR automaticky najde nejnovější nainstalovanou servisní verzi, která odpovídá hlavní/vedlejší verzi požadované sestavy." - Jeffrey Richter, [CLR přes C # (druhé vydání)] s. 56

Toto chování bylo ve verzi Beta 1 z CLR 1.0, avšak tato funkce byla před vydáním 1.0 odstraněna a nepodařilo se ji znovu převést do rozhraní .NET 2.0:

"Poznámka: Právě jsem popsal, jak byste měli myslet na čísla verzí." CLR bohužel nezpracovává čísla verzí tímto způsobem. [V .NET 2.0] CLR považuje číslo verze za neprůhlednou hodnotu a pokud sestava závisí na verzi 1.2.3.4 jiné sestavy, pokusí se CLR načíst pouze verzi 1.2.3.4 (pokud není zavedeno přesměrování vazby) ). Společnost Microsoft však plánuje v budoucí verzi změnit zavaděč CLR tak, aby načítal nejnovější sestavení/revizi dané hlavní/vedlejší verze shromáždění . Například na budoucí verzi CLR, pokud se zavaděč snaží najít verzi 1.2.3.4 sestavy a verze 1.2.5.0, zavaděč automaticky vyzvedne nejnovější servisní verzi. Bude to velmi vítaná změna zavaděče CLR - já na to nemůžu čekat. “- Jeffrey Richter, [CLR přes C # (druhé vydání)] s. 164 (důraz na důl)

Vzhledem k tomu, že tato změna ještě nebyla provedena, domnívám se, že je bezpečné předpokládat, že společnost Microsoft tento záměr zpětně sledovala, a možná je příliš pozdě na to tuto změnu změnit. Snažil jsem se prohledávat web, abych zjistil, co se stalo s těmito plány, ale nemohl jsem najít žádné odpovědi. Stále jsem se chtěl dostat na dno.

Takže jsem poslal e-mail Jeffu ​​Richterovi a zeptal jsem se ho přímo - usoudil jsem, že pokud někdo ví, co se stalo, bude to on.

Odpověděl do 12 hodin, v sobotu ráno, a objasnil, že zavaděč .NET 1.0 Beta 1 implementoval tento mechanismus „automatického převíjení vpřed“, který vyzvedl nejnovější dostupné sestavení a revizi shromáždění, ale toto chování bylo vráceno před odesláním .NET 1.0. To bylo později zamýšleno oživit, ale neudělalo to před dodáním CLR 2.0. Poté přišel Silverlight, který měl prioritu pro tým CLR, takže se tato funkce dále zpozdila. Mezitím se většina lidí, kteří byli ve dnech CLR 1.0 Beta 1, od té doby pohnul, takže je nepravděpodobné, že to uvidí denní světlo, a to i přes veškerou těžkou práci, která již byla do něj vložena.

Zdá se, že současné chování je tu.

Z mé diskuse s Jeffem také stojí za zmínku, že AssemblyFileVersion byla přidána až po odstranění mechanismu „automatického převrácení“ - protože po 1.0 Beta 1 byla jakákoli změna v AssemblyVersion pro vaše zákazníky zlomovou změnou, nikde bezpečně uložit vaše číslo sestavení. AssemblyFileVersion je to bezpečné útočiště, protože CLR ho nikdy automaticky nezkoumá. Možná je to jasnější, protože mají dvě samostatná čísla verzí, se samostatnými významy, spíše než se pokoušet o rozdělení mezi hlavní/vedlejší (zlomení) a sestavení/revizi (nerozbití) částí AssemblyVersion.

Sečteno a podtrženo: Pečlivě přemýšlejte, když změníte své AssemblyVersion

Morální je, že pokud přepravujete sestavy, na které se budou odkazovat další vývojáři, musíte být velmi opatrní, když změníte (a ne) změníte Assembly Assembly na těchto sestavách. Jakékoli změny v AssemblyVersion budou znamenat, že vývojáři aplikací budou muset buď překompilovat proti nové verzi (aktualizovat tyto záznamy AssemblyRef), nebo použít přesměrování vazeb Assembly k ručnímu přepsání vazby.

  • Neměňte neměňte AssemblyVersion pro servisní vydání, které má být zpětně kompatibilní.
  • Do změníte AssemblyVersion pro verzi, o které víte, že má přerušení.

Stačí se ještě jednou podívat na atributy verze na mscorlibu:

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

Všimněte si, že je to AssemblyFileVersion, která obsahuje všechny zajímavé servisní informace (je to část Revize této verze, která vám řekne, na kterém Service Packu jste), mezitím je AssemblyVersion opravena na nudnou starou verzi 2.0.0.0. Jakákoli změna AssemblyVersion by nutila každou .NET aplikaci odkazující na mscorlib.dll, aby se znovu kompilovala proti nové verzi!

570
Daniel Fortunov

AssemblyVersion do značné míry zůstává interní .NET, zatímco AssemblyFileVersion je to, co vidí Windows. Pokud přejdete na vlastnosti sestavy sedící v adresáři a přejdete na kartu verze, zobrazí se nahoře AssemblyFileVersion. Pokud soubory seřadíte podle verze, používá to Průzkumník.

AssemblyInformationalVersion mapuje na „verzi produktu“ a je zamýšlen jako čistě „lidský“.

AssemblyVersion je určitě nejdůležitější, ale já AssemblyFileVersion bych také nevynechal. Pokud nezadáte AssemblyInformationalVersion, kompilátor jej přidá za vás odstraněním části „revize“ čísla vaší verze a ponecháním major.minor.build.

42
Bob King

AssemblyInformationalVersion a AssemblyFileVersion se zobrazí při zobrazení informací o verzi v souboru pomocí Průzkumníka Windows zobrazením vlastností souboru. Tyto atributy se skutečně zkompilují do zdroje VERSION_INFO, který je vytvořen kompilátorem.

AssemblyInformationalVersion je hodnota „Verze produktu“. AssemblyFileVersion je hodnota „Verze souboru“.

Název AssemblyVersion je specifický pro sestavení .NET a používá zavaděč .NET Assembly ke zjištění, která verze sestavy se načte/sváže za běhu.

Z nich je jediný, který je absolutně vyžadován .NET, atribut AssemblyVersion. Bohužel to může také způsobit nejvíce problémů, když se mění bez rozdílu, zejména pokud jste silně pojmenováváte své sestavy.

21
Scott Dorman

Aby byla tato otázka aktuální, je třeba zdůraznit, že AssemblyInformationalVersion je používán společností NuGet a odráží verze balíčk včetně jakékoli přípony před vydáním.

Například AssemblyVersion 1.0.3. * Zabalený s jádrem asp.net dotnet-cli

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

Vytvoří balíček s verzí 1.0.3-ci-7, kterou si můžete prohlédnout s odrazem pomocí:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
8
KCD

Za zmínku stojí i několik dalších věcí:

1) Jak je zobrazeno v dialogovém okně Vlastnosti Průzkumníka Windows pro vygenerovaný soubor sestavy, existují dvě místa nazvaná „Verze souboru“. Ten, který vidíte v záhlaví dialogu, zobrazuje AssemblyVersion, nikoli AssemblyFileVersion.

V části Další informace o verzi je další prvek nazvaný „Verze souboru“. Zde uvidíte, co bylo zadáno jako AssemblyFileVersion.

2) AssemblyFileVersion je pouze prostý text. Nemusí odpovídat omezením schémat číslování, která AssemblyVersion dělá (např. <build> <65K). Může to být 3.2. <Text značky vydání>. <Čas>, pokud se vám líbí. Váš systém sestavení bude muset vyplnit tokeny.

Navíc není předmětem nahrazení zástupných znaků, jaké je AssemblyVersion. Pokud máte v souboru AssemblyInfo.cs hodnotu „3.0.1. *“, Bude to přesně to, co se zobrazí v prvku Další informace o verzi -> Verze souboru.

3) Nevím však, jaký dopad má instalační program na používání čísla jiného než číselného čísla verze souboru.

7
DavidM

Když se změní AssemblyVersion sestavy, Pokud má silné jméno, musí být znovu sestaveny odkazující sestavy, jinak se sestava nenačte! Pokud nemá silný název, není-li explicitně přidán do souboru projektu, nebude při sestavování zkopírován do výstupního adresáře, takže můžete vynechat závislé sestavy, zejména po vyčištění výstupního adresáře.

2
linquize