Üç montaj sürümü özelliği vardır. Farklılıklar nelerdir? AssemblyVersionGerisini kullanmam ve görmezden gelmem uygun olur mu?
MSDN diyor ki:
İlişkilendirilen derlemenin sürümünü belirtir.
Derleyiciye Win32 dosya sürümü kaynağı için belirli bir sürüm numarası kullanma talimatı verir. Win32 dosya sürümünün derlemenin sürüm numarası ile aynı olması gerekmez.
Bir montaj bildirimi için ek sürüm bilgilerini tanımlar.
Bu, Meclis Özniteliklerini kullanmak için en iyi uygulamalar nelerdir?
Yanıtlar:
AssemblyVersion
Montajınıza başvuruda bulunan diğer montajların nerede görüneceği. Bu sayı değişirse, diğer montajların montajınıza olan referanslarını güncellemesi gerekir! Bu sürümü yalnızca geriye dönük uyumluluğu bozarsa güncelleyin. AssemblyVersionGereklidir.
Formatını kullanıyorum: major.minor . Bunun sonucu:
[assembly: AssemblyVersion("1.0")]SemVer'i kesinlikle takip ediyorsanız, bu sadece büyük değişiklikler olduğunda , yani 1.0, 2.0, 3.0 vb.
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ı yapıya sahip olan AssemblyVersion, ancak farklı yapılardan oluşturulan derlemeleri işaretlemek için kullanın .
Windows'da, dosya özelliklerinde görüntülenebilir.
AssemblyFileVersion isteğe bağlıdır. Verilmezse, AssemblyVersion kullanılır.
: Ben biçimi kullanmak major.minor.patch.build ben takip SemVer ilk üç parça ve (yerel yapı için 0) son bölümü için buildserver ait YapıNumarası kullanın. Bunun sonucu:
[assembly: AssemblyFileVersion("1.3.2.254")]Unutmayın bu System.Version adlandırdığı gibi, bu parçalar major.minor.build.revision!
AssemblyInformationalVersion
Montajın Ürün sürümü. 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 .
AssemblyInformationalVersionİsteğe bağlıdır. Verilmezse, AssemblyFileVersion kullanılır.
Formatını kullanıyorum: major.minor [.patch] [dize olarak revizyon] . Bunun sonucu:
[assembly: AssemblyInformationalVersion("1.0 RC1")]major.minor[.build[.revision]]ve major.minor.revision.buildverilen cevapta, sınıf özelliklerini kullanıyorsanız veya System.Reflection.Assembly.GetExecutingAssembly().GetName().Versionderleme ve revizyon numaralarını tespit etmek için derleme ve revizyon numaraları değiştirilecektir.
AssemblyInformationalVersion, atlanırsa AssemblyFileVersionkullanılır. Sonra AssemblyVersion her ikisi de atlanırsa.
Derlemelerinizin sürümünün, derlemeniz için bir sürüm belirtmenin en az üç yolu olduğu düşünüldüğünde, kafa karıştırıcı bir olasılık olabilir.
İşte sürümle ilgili üç ana montaj özniteliğ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")]Kural olarak, sürümün dört bölümü Ana Sürüm , Alt Sürüm , Derleme ve Revizyon olarak adlandırılır .
AssemblyFileVersionBenzersiz bir yapı belirlemek için tasarlanmıştır bireysel montajGenellikle Major ve Minor AssemblyFileVersion öğelerini derlemenin sürümünü yansıtacak şekilde manuel olarak ayarlarsınız, ardından derleme sisteminiz derlemeyi her derlediğinde Derlemeyi ve / veya Revizyonu artırırsınız. AssemblyFileVersion, derlemenin bir yapısını benzersiz bir şekilde tanımlamanıza izin vermelidir, böylece herhangi bir sorunu ayıklamak için bir başlangıç noktası olarak kullanabilirsiniz.
Şu anki projemde, derleme sunucusunun kaynak kontrol depomuzdaki changelist numarasını AssemblyFileVersion'un Build ve Revision bölümlerine kodlaması var. Bu, derleme sunucusu tarafından oluşturulan herhangi bir derleme için doğrudan bir derlemeden kaynak koduna eşlememizi sağlar (kaynak denetiminde etiket veya dal kullanmak zorunda kalmadan veya yayımlanan sürümlerin kayıtlarını el ile tutmadan).
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'ı umursamıyor veya incelemiyor.
AssemblyInformationalVersionTüm ürünün sürümünü temsil etmesi amaçlanmıştırAssemblyInformationalVersion, bağımsız olarak sürümlendirilebilen, belki de farklı sürüm oluşturma ilkeleri olan ve potansiyel olarak farklı ekipler tarafından geliştirilen birçok montajdan oluşan tüm ürünün tutarlı sürümüne izin vermek üzere tasarlanmıştır.
“Örneğin, bir ürünün 2.0 sürümü birkaç derleme içerebilir; aynı derlemenin 1.0 sürümünde gönderilmeyen yeni bir derleme olduğundan, bu derlemelerden biri sürüm 1.0 olarak işaretlenir. Genellikle, bu sürüm numarasının büyük ve küçük parçalarını ürününüzün genel sürümünü temsil edecek şekilde ayarlarsınız. Ardından, komple bir ürünü tüm montajlarıyla her paketlediğinizde derleme ve revizyon parçalarını artırırsınız. ” - Jeffrey Richter, [CLR üzerinden C # (İkinci Baskı)] s. 57
CLR, AssemblyInformationalVersion'ı umursamıyor veya incelemiyor.
AssemblyVersionSadece versiyonu hakkında CLR umurunda (ama entire umurunda AssemblyVersion)AssemblyVersion, CLR tarafından güçlü bir şekilde adlandırılmış derlemelere 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 adlandırılmış derlemeye başvurduğunuzda, söz konusu derlemenin belirli bir AssemblyVersion sürümüne sıkı sıkıya bağlı olduğunuz anlamına gelir. Bağlamanın başarılı olması için tüm AssemblyVersion tam eşleşmesi gerekir. Örneğin, derleme sırası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 kullanılabilirse, bağlama başarısız olur! (Daha sonra, Montaj Bağlama Yeniden Yönlendirmesi'ni kullanarak bu soruna geçici bir çözüm bulmak zorunda kalacaksınız .)
AssemblyVersioneşleşmesi gerekip gerekmediği konusunda kafa karışıklığı . (Evet öyle.)Bir montajın yüklenmesi için AssemblyVersion'ın tamamının tam olarak eşleşmesi gerekip gerekmediği konusunda biraz karışıklık vardır. Bazı insanlar, bağlantının başarılı olması için AssemblyVersion'un sadece Büyük ve Küçük bölümlerinin eşleşmesi gerektiği konusunda yanlış inanç altındadır. Bu mantıklı bir varsayımdır, ancak sonuçta yanlıştır (.NET 3.5'ten itibaren) ve bunu CLR sürümünüz için doğrulamak önemsizdir. Sadece bu örnek kodu yürütün .
Makinemde ikinci montaj yükü başarısız oluyor ve füzyon günlüğünün son iki satırı nedenini açıkça ortaya koyuyor:
.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 karışıklığın kaynağının muhtemelen Microsoft'un aslında sadece Major ve Minör sürüm parçalarıyla eşleştirerek tam AssemblyVersion'ın bu sıkı eşleşmesinde biraz daha yumuşak olması amaçlandığını düşünüyorum:
"Bir montajı yüklerken, CLR otomatik olarak istenen montajın ana / ikincil sürümüyle eşleşen en son kurulu servis sürümünü bulur." - Jeffrey Richter, [CLR üzerinden C # (İkinci Baskı)] s. 56
Bu, 1.0 CLR'nin Beta 1'indeki davranıştır, ancak bu özellik 1.0 sürümünden önce kaldırılmıştır ve .NET 2.0'da yeniden yüzey oluşturmayı başaramamıştır:
“Not: Sürüm numaralarını nasıl düşünmeniz gerektiğini daha yeni anlattım. Ne yazık ki, CLR sürüm numaralarını bu şekilde işlemez. [.NET 2.0'da], CLR sürüm numarasını opak bir değer olarak ele alır ve bir derleme başka bir derlemenin 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 bağlayıcı yeniden yönlendirme mevcut değilse) ). Ancak Microsoft, CLR'nin yükleyicisini gelecekteki bir sürümde değiştirmeyi planlıyor, böylece bir derlemenin belirli bir büyük / küçük sürümü için en son derlemeyi / düzeltmeyi yüklüyor. Örneğin, CLR'nin gelecekteki bir sürümünde, yükleyici bir montajın 1.2.3.4 sürümünü bulmaya çalışıyorsa ve 1.2.5.0 sürümü varsa, en son servis sürümünü otomatik olarak yükleyen yükleyici. Bu, CLR'nin yükleyicisinde çok hoş bir değişiklik olacak - biri için bekleyemem. ” - Jeffrey Richter, [CLR üzerinden C # (İkinci Baskı)] s. 164 (Vurgu madeni)
Bu değişiklik hala uygulanmadığından, Microsoft'un bu amaçla geri adım attığını varsaymanın güvenli olduğunu düşünüyorum ve şimdi değiştirmek için belki de çok geç. Bu planlarda neler olduğunu öğrenmek için web'de arama yapmaya çalıştım, ancak cevap bulamadım. Hala dibe inmek istedim.
Bu yüzden Jeff Richter'a e-posta gönderdim ve ona doğrudan sordum - ne olduğunu bilen biri olup olmadığını anladım.
12 saat içinde, Cumartesi sabahı daha az cevap vermedi ve .NET 1.0 Beta 1 yükleyicinin, bir montajın mevcut en son Yapı ve Revizyonunu almak için bu 'otomatik ileri sarma' mekanizmasını uyguladığını açıkladı, ancak bu davranış .NET 1.0 gönderilmeden önce geri döndürüldü. Daha sonra bunu yeniden canlandırması amaçlandı, ancak CLR 2.0 sevk edilmeden önce olmadı. Daha sonra CLR ekibi için öncelikli olan Silverlight geldi, bu nedenle bu işlevsellik daha da gecikti. Bu arada, CLR 1.0 Beta 1 günlerinde etrafta olan insanların çoğu, o zamandan beri devam etti, bu nedenle, zaten yerleştirilmiş olan tüm sıkı çalışmalara rağmen, günün ışığını görmesi olası değildir.
Mevcut davranış, öyle görünüyor ki, burada kalmak için.
Jeff ile yaptığım görüşmeden, AssemblyFileVersion'un 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'daki herhangi bir değişiklik müşterileriniz için bir kırılma değişikliği oldu. yapı numaranızı güvenle saklayamazsınız. AssemblyFileVersion, güvenli bir sığınaktır, çünkü CLR tarafından asla otomatik olarak incelenmez. Belki bu şekilde, AssemblyVersion'un Major / Minor (kırılma) ve Build / Revision (kırılmayan) bölümleri arasındaki ayrımı yapmaya çalışmak yerine, ayrı anlamlarla iki ayrı sürüm numarasına sahip olmak daha açıktır.
AssemblyVersionAhlaki, diğer geliştiricilerin referans vereceği montajları gönderiyorsanız, bu montajların AssemblyVersion'unu ne zaman değiştirdiğiniz (ve değiştirmediğiniz) konusunda son derece dikkatli olmanız gerekir. AssemblyVersion'da yapılacak herhangi bir değişiklik, uygulama geliştiricilerinin ya yeni sürüme karşı derleme yapmaları (bu AssemblyRef girişlerini güncellemek için) ya da ciltlemeyi manuel olarak geçersiz kılmak için derleme bağlama yeniden yönlendirmeleri kullanmaları gerektiği anlamına gelir.
Mscorlib'daki sürüm özelliklerine bir göz atı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ğuna dikkat edin (bu sürümün hangi Servis Paketinde olduğunuzu söyleyen Revizyon kısmıdır), bu arada AssemblyVersion sıkıcı eski bir 2.0.0.0'da düzeltildi. AssemblyVersion herhangi bir değişiklik mscorlib.dll başvuran her .NET uygulaması yeni sürümüne karşı yeniden derlemek için zorlar!
AssemblyVersionAssemblyFileVersionWindows'un gördüğü şey hemen hemen .NET'in içinde kalır . Bir dizinde oturan bir montajın özelliklerine gidip sürüm sekmesine AssemblyFileVersiongeçerseniz, üstte göreceğiniz şey budur. Dosyaları sürüme göre sıralarsanız, Explorer tarafından kullanılan budur.
AssemblyInformationalVersion"Ürün Version" eşleştiren ve tamamen "insan-used" olması gerekiyordu.
AssemblyVersionkesinlikle en önemlisidir, ama ben de atlamam AssemblyFileVersion. Eğer girmezseniz AssemblyInformationalVersion, derleyici Sürüm numarasının "revizyon" parçasını kapalı sıyırma ve major.minor.build bırakarak sizin için ekler.
AssemblyInformationalVersionve AssemblyFileVersiondosya özelliklerini görüntüleyerek Windows Gezgini aracılığıyla bir dosyadaki "Sürüm" bilgilerini görüntülediğinizde görüntülenir. Bu öznitelikler VERSION_INFOderleyici tarafından oluşturulan bir kaynağa derlenir .
AssemblyInformationalVersion"Ürün sürümü" değeridir. AssemblyFileVersion"Dosya sürümü" değeridir.
AssemblyVersion.NET düzenekleri için özel olan ve montaj yükleyici yük / bağlama zamanında bir derleme sürümünü bilmek .NET tarafından kullanılır.
Bunlardan, .NET tarafından kesinlikle gerekli olan tek AssemblyVersionözellik özniteliktir. Ne yazık ki, özellikle montajlarınızı güçlü bir şekilde isimlendiriyorsanız, gelişigüzel bir şekilde değiştiğinde en çok soruna neden olabilir.
Bu soruyu güncel tutmak için AssemblyInformationalVersionNuGet tarafından kullanılan ve paket sürümünü yansıtan vurgulamaya değer öncesi son içeren .
Örneğin, asp.net çekirdek dotnet-cli ile paketlenmiş 1.0.3. * Derlemesi
dotnet pack --version-suffix ci-7 src/MyProject1.0.3-ci-7 sürümüne sahip, aşağıdakileri kullanarak yansıma ile inceleyebileceğiniz bir paket üretir:
CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);Başka bazı şeyleri belirtmeye değer:
1) Oluşturulan derleme dosyası için Windows Gezgini Özellikleri iletişim kutusunda gösterildiği gibi, "Dosya sürümü" adı verilen iki yer vardır. İletişim kutusunun başlığında görülen, AssemblyFileVersion değil AssemblyVersion'ı gösterir.
Diğer sürüm bilgileri bölümünde, "Dosya Sürümü" adlı başka bir öğe vardır. Bu, AssemblyFileVersion olarak girilenleri görebileceğiniz yerdir.
2) AssemblyFileVersion sadece düz metindir. AssemblyVersion'un yaptığı numaralandırma şeması kısıtlamalarına uymak zorunda değildir (<build> <65K, örn.). İsterseniz 3.2 olabilir. <Serbest bırakma metni>. Derleme sisteminizin jetonları doldurması gerekecek.
Ayrıca, AssemblyVersion'ın joker karakter değişimine tabi değildir. AssemblyInfo.cs içinde sadece "3.0.1. *" Değerine sahipseniz, tam olarak Diğer sürüm bilgileri -> Dosya Sürümü öğesinde gösterilen değer budur.
3) Yükleyicinin sayısal dosya sürümü numaralarından başka bir şey kullanmasının etkisini bilmiyorum.
Bir montajın AssemblyVersion değiştiğinde, güçlü bir adı varsa, başvuru derlemelerinin yeniden derlenmesi gerekir, aksi takdirde derleme yüklenmez! Güçlü bir adı yoksa, proje dosyasına açıkça eklenmediyse, derlendiğinde çıktı dizinine kopyalanmaz, bu nedenle özellikle çıktı dizinini temizledikten sonra bağlı montajları kaçırabilirsiniz.