it-swarm-tr.com

AssemblyVersion, AssemblyFileVersion ve AssemblyInformational Version arasındaki farklar nelerdir?

Üç Derleme sürümü özelliği vardır. Farklılıklar nelerdir? AssemblyVersion kullanıyor ve gerisini yok sayarsam sorun olur mu?


MSDN diyor ki:

  • AssemblyVersion :

    Yüklenecek Derleme sürümünü belirtir.

  • AssemblyFileVersion :

    Bir derleyiciye, Win32 dosya sürümü kaynağı için belirli bir sürüm numarası kullanması talimatını verir. Derlemenin sürüm numarasıyla aynı olması için Win32 dosya sürümü gerekli değildir.

  • AssemblyInformationalVersion :

    Montaj bildirimi için ek sürüm bilgilerini tanımlar.


Bu 'ın devamıdır; Assembly Attributes'ı kullanmak için en iyi yöntemler nelerdir?

824
Jakub Šturc

AssemblyVersion

Meclisinize başvuran diğer meclislerin bakacağı yer. Bu sayı değişirse, diğer meclislerin referanslarını Meclisinize güncellemesi gerekir! AssemblyVersiongerekli.

Bu formatı kullanıyorum: major.minor . Bu sonuçlanır:

[Assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Dağıtım için kullanılır. Her dağıtım için bu sayıyı artırabilirsiniz. Kurulum programları tarafından kullanılır. Aynı AssemblyVersionolan ancak farklı derlemelerden oluşturulan derlemeleri işaretlemek için kullanın.

Windows'ta, dosya özelliklerinde görüntülenebilir.

Mümkünse, MSBuild tarafından oluşturulmasına izin verin. AssemblyFileVersion isteğe bağlıdır. Verilmezse, AssemblyVersion kullanılır.

Formatını kullanıyorum: major.minor.revision.build , geliştirme aşaması (Alpha, Beta, RC ve RTM), servis paketleri ve düzeltmeler için revizyon kullanıyorum. Bu sonuçlanır:

[Assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

Montajın Ürün versiyonu. Bu, müşterilerle konuşurken veya web sitenizde görüntülemek için kullanacağınız sürümdür. Bu sürüm ' 1.0 Sürüm Adayı ' gibi bir dize olabilir.

Kod Analizi bundan şikayet edecektir (CA2243) - Microsoft'a bildirildi (VS2013'te düzeltilmedi).

AssemblyInformationalVersionisteğe bağlıdır. Verilmezse, AssemblyFileVersion kullanılır.

Bu formatı kullanıyorum: major.minor [string olarak revision] . Bu sonuçlanır:

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

.NET'teki derlemelerin sürümlenmesi, Derlemeniz için bir sürüm belirtmenin en az üç yolu olduğu göz önüne alındığında, kafa karıştırıcı bir olasılık olabilir.

İşte sürümle ilgili üç ana derleme özelliği:

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

Kurallara göre, sürümün dört bölümüne Büyük Sürüm , Küçük Sürüm , Derleme ve Revizyon .

AssemblyFileVersion, bağımsız Meclisinin bir yapısını benzersiz şekilde tanımlamayı amaçlar.

Genelde, Major ve Minör AssemblyFileVersion'u Montaj sürümünü yansıtacak şekilde manuel olarak ayarlayacaksınız, daha sonra yapım sisteminiz montajı her derlediğinde Oluştur ve/veya Düzeltmeyi artıracaksınız. AssemblyFileVersion, bir derleme yapısını benzersiz bir şekilde tanımlamanıza izin vermelidir, böylece herhangi bir sorunu ayıklamak için onu başlangıç ​​noktası olarak kullanabilirsiniz.

Şu anki projemde build server, kaynak kontrol depomuzdaki değişiklik listesi sayısını AssemblyFileVersion'un Build ve Revizyon bölümlerine kodladı. Bu, derleme sunucusu tarafından oluşturulan herhangi bir derleme için doğrudan bir derlemeden kaynak koduna eşlememize izin verir (kaynak kontrolünde etiket veya dallar kullanmak zorunda kalmadan veya yayınlanan sürümlerin herhangi bir kaydını manuel olarak tutmak zorunda kalmadan).

Bu sürüm numarası Win32 sürüm kaynağında depolanır ve Derleme için Windows Gezgini özellik sayfalarını görüntülerken görülebilir.

CLR, AssemblyFileVersion'u umursamıyor veya incelemiyor.

AssemblyInformationalVersion, tüm ürün sürümünüzü temsil etmeyi amaçlamaktadır

AssemblyInformationalVersion, belki de farklı sürüm politikaları ile bağımsız olarak sürümlendirilmiş ve potansiyel olarak farklı ekipler tarafından geliştirilen birçok montajdan oluşabilecek tüm ürünün tutarlı bir şekilde sürümlenmesine izin vermek için tasarlanmıştır.

“Örneğin, bir ürünün 2.0 sürümü birkaç montaj içerebilir; Bu montajlardan biri, aynı ürünün 1.0 sürümünde piyasaya sürülmemiş yeni bir Meclis olduğu için sürüm 1.0 olarak işaretlenmiştir. Genellikle, bu sürüm numarasının ana ve küçük bölümlerini, ürünün genel sürümünü temsil edecek şekilde ayarlarsınız. Daha sonra, tüm montajları ile birlikte komple bir ürün paketlediğinizde yapı ve revizyon parçalarını arttırırsınız. ”- Jeffrey Richter, [CLR via C # (Second Edition)] s. 57

CLR AssemblyInformationalVersion'ı umursamıyor veya incelemiyor.

AssemblyVersion, CLR'nin umursadığı tek versiyondur (ancak AssemblyVersion'nin tamamı için de geçerlidir)

AssemblyVersion, CLR tarafından güçlü bir şekilde adlandırılmış montajlara bağlanmak için kullanılır. Yapılı derlemenin AssemblyDef manifest meta veri tablosunda ve ona başvuran herhangi bir derlemenin AssemblyRef tablosunda depolanır.

Bu çok önemlidir, çünkü güçlü bir şekilde adlandırılmış bir Meclis'e başvurduğunuzda, o Meclisin belirli bir Meclisine sıkı sıkıya bağlı kaldığınız anlamına gelir. AssemblyVersion'ın tamamı, bağlamanın başarılı olması için tam bir eşleşme olmalıdır. Örneğin, derleme zamanında kesin olarak adlandırılmış bir Derlemenin 1.0.0.0 sürümüne başvurursanız, ancak bu Derlemenin yalnızca 1.0.0.1 sürümü çalışma zamanında mevcutsa, ciltleme başarısız olur! (Daha sonra bunun üzerinde çalışmak zorunda kalacaksınız Assembly Binding Redirection .)

AssemblyVersion dosyasının tamamının eşleşmesi gerekip gerekmediği üzerine kafa karışıklığı. (Evet öyle.)

Bir Meclisin yüklenebilmesi için tüm Meclis Sürümü'nün tam bir eşleşme olması gerekip gerekmediği konusunda biraz karışıklık var. Bazı insanlar, Meclis Sürümü'nün sadece Büyük ve Küçük bölümlerinin, başarılı olabilmeleri için birbiriyle uyuşması gerektiğine dair yanlış inanç içindedirler. Bu mantıklı bir varsayım, ancak sonuçta yanlış (.NET 3.5'ten itibaren) ve CLR sürümünüz için bunu doğrulamak çok önemli. Sadece yürütün bu örnek kod .

Makinemde ikinci Meclis yükü başarısız oluyor ve füzyon kütüğünün son iki satırı nedenini açıkça gösteriyor:

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

Bu kargaşanın kaynağının büyük olasılıkla Microsoft'un aslında sadece Büyük ve Küçük versiyon bölümlerinde eşleştirerek, AssemblyVersion'un bu tam eşleşmesinde biraz daha hafif olması amaçlanmasından kaynaklandığını düşünüyorum:

“Bir Montajı yüklerken, CLR talep edilen Montajın ana/küçük versiyonuna uyan en son kurulu servis sürümünü otomatik olarak bulur.” - Jeffrey Richter, [CLR ile C # (İkinci Baskı)] s. 56

Bu, 1.0 CLR'nin Beta 1’sindeki davranıştı, ancak bu özellik 1.0 sürümünden önce kaldırıldı ve .NET 2.0'da yeniden yüzeye çıkmayı başaramadı:

“Not: Sadece sürüm numaralarını nasıl düşünmeniz gerektiğini anlattım. Maalesef, CLR sürüm numaralarını bu şekilde ele almaz. [.NET 2.0'da], CLR sürüm numarasını opak bir değer olarak görür ve bir Montaj başka bir Montajın 1.2.3.4 sürümüne bağlıysa, CLR yalnızca 1.2.3.4 sürümünü yüklemeye çalışır (bir ciltleme yönlendirmesi olmadıkça) ). Ancak, Microsoft, CLR'nin yükleyicisini gelecekteki bir sürümde değiştirmeyi planlıyor, böylece bir Meclis'in belirli bir büyük/küçük sürümü için en son derleme/revizyonu yüklüyor . Örneğin, CLR'nin gelecekteki bir sürümünde, yükleyici bir Meclisin 1.2.3.4 sürümünü ve 1.2.5.0 sürümünü bulmaya çalışıyorsa, en son hizmet sürümünü otomatik olarak alan yükleyici. Bu, CLR’nin yükleyicisinde çok hoş bir değişiklik olacak - Ben birisini bekleyemem. ”- Jeffrey Richter, [CLR via C # (Second Edition)] s. 164 (Vurgu madeni)

Bu değişiklik hala uygulanmadığından, Microsoft’un bu niyetini tekrar takip ettiğini varsaymanın güvenli olduğunu ve şimdi bunu değiştirmek için belki de çok geç olduğunu düşünüyorum. Bu planlarda ne olduğunu bulmak için web’de arama yapmaya çalıştım, ancak herhangi bir cevap bulamadım. Hala dibine ulaşmak istedim.

Bu yüzden Jeff Richter'a e-posta gönderdim ve doğrudan sordum - birinin ne olduğunu bilip bilmediğini, onun olacağını biliyordum.

12 saat içinde, en az bir Cumartesi sabahı cevap verdi ve .NET 1.0 Beta 1 yükleyicisinin, mevcut bir Derleme için en yeni Yapım ve Revizyonu almak için bu 'otomatik ileri sarma' mekanizmasını uyguladığını açıkladı, ancak bu davranış oldu. .NET 1.0 gönderilmeden önce geri alındı. Daha sonra bunu canlandırmak niyetindeydi, ancak CLR 2.0 gönderilmeden önce gelmedi. Sonra CLR ekibi için öncelik alan Silverlight geldi, bu yüzden bu işlev daha da ertelendi. Bu arada, CLR 1.0 Beta 1 günlerinde etrafta olan insanların çoğu o zamandan beri harekete geçti, bu nedenle, halihazırda içine konan tüm zorlu çalışmalara rağmen, bunun gün ışığını görmesi pek mümkün değil.

Görünüşe göre mevcut davranış burada kalmaktır.

Üstelik Jeff ile yaptığım görüşme göre, AssemblyFileVersion'ın yalnızca 'otomatik ileri sarma' mekanizmasının kaldırılmasından sonra eklendiğini belirtmek gerekir - çünkü 1.0 Beta 1’den sonra, AssemblyVersion’da yapılan herhangi bir değişiklik müşterileriniz için büyük bir değişiklikti. yapı numaranızı güvenle saklayabileceğiniz hiçbir yer yok. AssemblyFileVersion, CLR tarafından hiçbir zaman otomatik olarak incelenmediğinden bu güvenli bölgedir. Belki de, bu şekilde, AssemblyVersion'un Ana/Küçük (kırma) ve Yapı/Revizyon (kırılmayan) bölümleri arasında bir ayrım yapmayı denemek yerine, iki ayrı sürüm numarasına sahip olmaktan ayrı anlamlara sahip olduğu daha açıktır.

Sonuç olarak: AssemblyVersion numaranızı değiştirirken dikkatlice düşünün.

Ahlaki, eğer diğer geliştiricilerin referans alacağı meclisleri gönderiyorsanız, bu meclislerin Meclis Değişikliğini ne zaman değiştirdiğiniz (ve ne zaman değiştirmeyeceğiniz) konusunda çok dikkatli olmanız gerekir. AssemblyVersion'da yapılacak herhangi bir değişiklik, uygulama geliştiricilerin ya yeni sürüme karşı yeniden derlemek zorunda kalacakları (bu AssemblyRef girişlerini güncellemek için) ya da ciltlemeyi el ile geçersiz kılmak için Assembly ciltleme yönlendirmelerini kullanmaları gerektiği anlamına gelir.

  • Geriye dönük olarak uyumlu olması gereken bir hizmet sürümü için AssemblyVersion ürününü değiştirmeyin .
  • Değişiklikleri olduğunu bildiğiniz bir sürüm için AssemblyVersion uygulamasını değiştirmeyin .

Mscorlib'deki sürüm niteliklerine bir kez daha bakın:

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

Tüm ilginç servis bilgilerini içeren AssemblyFileVersion olduğunu (bu sürümün hangi Servis Paketinde bulunduğunuzu size söyleyen kısmıdır), bu arada AssemblyVersion sıkıcı bir eski 2.0.0.0'da sabitlenmiştir. AssemblyVersion'da yapılacak herhangi bir değişiklik, mscorlib.dll dosyasına başvuran her .NET uygulamasını yeni sürüme karşı yeniden derlemeye zorlar!

570
Daniel Fortunov

AssemblyVersion hemen hemen .NET'te kalır, AssemblyFileVersion ise Windows’un gördüğü şeydir. Bir dizinde oturan bir Derecenin özelliklerine gidip sürüm sekmesine geçerseniz, AssemblyFileVersion en üstte göreceğiniz şeydir. Dosyaları sürüme göre sıralarsanız, Explorer tarafından kullanılan budur.

AssemblyInformationalVersion, "Ürün Sürümü" ile eşleşir ve tamamen "insan kullanımı" anlamına gelir.

AssemblyVersion kesinlikle en önemlisidir, ancak AssemblyFileVersion'yi de atlamazdım. AssemblyInformationalVersion işlevini sağlamazsanız, derleyici sürüm numaranızın "revizyon" kısmını çıkartarak ve major.minor.build bırakarak sizin için ekler.

42
Bob King

Dosya özelliklerini görüntüleyerek Windows Explorer üzerinden bir dosyada "Sürüm" bilgisini görüntülediğinizde AssemblyInformationalVersion ve AssemblyFileVersion görüntülenir. Bu özellikler aslında derleyici tarafından oluşturulan VERSION_INFO kaynağında derlenir.

AssemblyInformationalVersion, "Ürün sürümü" değeridir. AssemblyFileVersion "Dosya sürümü" değeridir.

AssemblyVersion, .NET derlemelerine özgüdür ve .NET derleme yükleyicisi tarafından çalışma zamanında yüklenecek/ciltlenecek bir derleme sürümünü bilmek için kullanılır.

Bunlardan kesinlikle .NET tarafından istenen tek şey AssemblyVersion niteliğidir. Ne yazık ki, özellikle meclislerinizi isimlendirmek için güçlü iseniz, fark gözetmeden değiştiğinde en çok soruna neden olabilir.

21
Scott Dorman

Bu soruyu güncel tutmak için, AssemblyInformationalVersiondosyasının NuGet tarafından kullanıldığını ve yayın öncesi ön ekler de dahil paket sürümü 'yi yansıttığını vurgulamak önemlidir.

Örneğin, 1.0.3. * 'Dan oluşan bir AssemblyVersion, asp.net core dotnet-cli ile paketlenmiştir.

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

Aşağıdakileri kullanarak yansıma ile inceleyebileceğiniz 1.0.3-ci-7 sürümüne sahip bir paket üretir:

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

Başka şeyler de dikkate değer:

1) Oluşturulan Montaj dosyası için Windows Gezgini Özellikleri iletişim kutusunda gösterildiği gibi, "Dosya sürümü" olarak adlandırılan iki yer vardır. İletişim kutusunun başlığında görülen, AssemblyFileVersion'u değil, AssemblyVersion'u gösterir.

Diğer sürüm bilgileri bölümünde "Dosya Sürümü" adlı başka bir öğe var. AssemblyFileVersion adıyla ne girildiğini burada görebilirsiniz.

2) AssemblyFileVersion sadece düz metindir. AssemblyVersion'un yaptığı numaralandırma düzeni kısıtlamalarına uymak zorunda değildir (<build> <65K, örneğin). İsterseniz, 3.2. <Sürüm etiketi metni> olabilir. <datetime> olabilir. Yapı sisteminiz belirteçleri doldurmak zorundadır.

Dahası, AssemblyVersion'un olduğu joker karakter değişikliğine tabi değildir. AssemblyInfo.cs dosyasında "3.0.1. *" Değerine sahipseniz, tam olarak Diğer sürüm bilgisi-> Dosya Sürümü öğesinde gösterilecek olan budur.

3) Ancak, bir yükleyici üzerindeki sayısal dosya sürüm numaraları dışında bir şey kullanmanın etkisini bilmiyorum.

7
DavidM

Bir Meclis'in Meclisi Değişimi değiştiğinde, Güçlü bir adı varsa, referans meclislerinin yeniden derlenmesi gerekir, aksi takdirde Meclis yüklenmez! Güçlü bir adı yoksa, açıkça proje dosyasına eklenmediyse, derleme sırasında çıktı dizinine kopyalanmayacağından, özellikle çıktı dizinini temizledikten sonra bağlı derlemeleri kaçırabilirsiniz.

2
linquize