.Net toplama yanlış referanslı montaj sürümü

Mevcut bir projeyi geliştirmeye başlamak için yepyeni bir makineye kopyaladım ve referans aldığım derlemelerden birinin (bir telerik DLL olduğu gibi) sürümü ile ilgili bir sorunla karşılaştım.

Proje başlangıçta derlemenin eski bir sürümüne başvurdu (buna v1.0.0.0 diyelim). Yeni makinemde montajın en son sürümü yüklü, bu yüzden güncellediğimi düşündüm (yeni sürümü v2.0.0.0 olarak adlandıralım).

Şimdi sorun İşte: Ben eski v1.0.0.0 dll proje klasörüne kopyalayın ve referans olarak ekleyin, web sitesi sorunsuz başlar. Bu başvuruyu silersem (ve ayrıca eski DLL dosyasını sistemimden silersem) ve yeni sürümü (v2.0.0.0) eklerseniz, sayfa aşağıdaki özel durumu gösterir:

Dosya veya derleme 'XXXXXX, Sürüm = 1.0.0.0, Kültür = nötr, PublicKeyToken = 121fae78165ba3d4' veya bağımlılıklarından biri yüklenemedi. Konumlandırılan derlemenin bildirim tanımı derleme başvurusuyla eşleşmiyor. (HRESULT istisnası: 0x80131040)

Açıkçası, kod güncel olmayan sürümü arıyor ve bulamıyor. Ama neden?

Bu sürüm numarası için çözüm klasörünü açtım ve tek bir başvuru bulamadım. .Csproj dosyasının metnini iki kez kontrol ettim ve sürümün en son sürümü ve HintPath'in yeni DLL dosyasının yolunu doğru bir şekilde gösterdiğini buldum. Ayrıca, sisteme eski DLL'yi yüklemediğim için GAC'ımda görünmüyor (ancak v2.0.0.0 beklendiği gibi çalışıyor).

Daha sonra füzyon günlüğü görüntüleyicisini neden bu eski sürümü aradığını anlamaya çalışmak için etkinleştirdim, ancak şans yok:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Tüm bunlar, eski meclisi arayarak başladığını söylüyor. Çevrimiçi bir çözüm bulmaya çalıştım ve bu benzer SO sorusunu gördüm , ancak sorunumun tam tersi gibi görünüyor. Bu sorucının programı başvurulan program yerine yanlış DLL buluyordu. Benim sorunum ise programın gizemli bir şekilde yanlış DLL'yi arıyor ve doğru olanı bin klasöründe ve GAC'da yerel olarak bulunabiliyorsa bulamıyor.

Benimki neden eski versiyonu arıyor? Bu kötü referansı bulmak için başka nerede arama yapabilirim?

Benim tahminim kullandığınız başka bir derleme eski dll referans olmasıdır. Kullanılan diğer tüm proje referanslarına aşina mısınız ve bunlardan herhangi birinin Telerik dll'lerine bir referansı var mı?

Web.config dosyanıza böyle bir bağlayıcı yönlendirme koyabilir misiniz?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Chris Conway ile birlikteyim (onu oyladım). Sorun şu ki, projenizde telerik meclislerinden birine referansta bulunuyorsunuz.

İlk şey: GAC içine HERHANGİ bir satıcı (yani: telerik) meclisleri kurmak olmazdı. Telerik'in işleri zaten sadece iki meclise derlendi (telerik.web.design ve telerik.web.ui). Sadece uygulama ile dağıtın.

İkincisi, .proj dosyalarınızın (.csproj gibi) her birinde <reference include..>Telerik.Web.UI dosyasına işaret eden bir dosya olacaktır. Bu normalde bir sürüm numarası içerir. Bin klasörüne koyduğunuz montajın bu sürümle eşleştiğinden emin olun.

Üçüncü olarak, TÜM projelerinizin en son montajı kullandığından emin olun. Ayrıca montajı GAC yerine yerel bir yoldan tuttuklarından emin olun. (GAC'yi gerçekten sevmiyorum. Üzerinde bulunduğum bazı projelerde sorunların sonu gelmedi). Genellikle tüm projelerin harici montaj referansları için kullandığı bir "Montajlar" klasörümüz vardır.

Dördüncüsü, visual studio bir web sitesi projesi her yüklendiğinde otomatik olarak gac'ınızı arar ve gac içinde bir şey bulursa montaj konumlarını yeniden hedefler. Bunu web uygulaması projeleri için yapılıp yapılmadığını hatırlayamıyorum, ancak uzun süredir bu sorunla karşılaşmadım. Bu, dağıtım sırasında benzer sorunlara neden olabilir.

Beşinci olarak, web.config dosyasında derlemeler için sürüm numaralarını yeniden bağlayabilirsiniz. Bölümde, runtime/assemblybinding2008 yılında dağıtılan her telerik montajını ileri götüren ve çok özel bir sürüme işaret eden aşağıdaki gibi bir şey kullanabilirsiniz:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

Cevapların çoğunu denedim ama yine de işe yaramadı. Bu benim için çalıştı:

referansa sağ tıklayın -> özellikler -> 'Spesifik Sürüm'ü false olarak değiştirin.

Bu yardımcı olur umarım.

Deneyin:

• geçici proje dosyalarını temizleme
• derleme ve obj dosyalarını temizleme
• yüklü eski sürümleri temizleme C:\Users\USERNAME\.nuget\packages\

Bu benim için çalıştı.

1. C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG adresine gidin.
2. Machine.config dosyasını bulma
3. not defterinde aç
4. çatışma dll bulmak
5. Bunu kaldırın ve kaydedin.

derleme meclisleri

addassembly = dllName, Sürüm = 1.0.0000.0000 Kültür = nötr, PublicKeyToken = "QWEWQERWETERY"

meclis derleme

benim için çalışıyor.

Bunun nedenine dair açık bir cevap değil, ama bu problemimiz vardı, işte koşullarımız ve neyi çözdü:

Dev 1:

Çözüm, NuGet Paketi'ne başvuran A Projesi'ni ve Proje A'ya başvuran bir MVC projesini içerir. NuGet Paketi Geri Yüklemeyi Etkinleştirdikten sonra NuGet paketini güncelleyin. NuGet lib'in bulunamadığından şikayet eden bir çalışma zamanı hatası var - ancak hata eski, güncellenmemiş sürümü arıyor. Çözüm (ve bu çok saçma): MVC projesinde A Projesi'ni çağıran ilk kod satırında bir kesme noktası belirleyin. F11 ile adım atın. Çözüldü - bir daha asla sorun yaşamadım.

Dev 2:

Aynı çözüm ve projeler, ama sihirli set kesme noktası ve çözüm adım çalışmıyor. Bu Nuget paketine sürüm yönlendirmeleri veya diğer kötü referanslar için her yerde aradı, paketi kaldırdı ve yeniden yükledi, sildi, obj, Asp.Net Temp, hiçbir şey çözülmedi. Son olarak, Proje A olarak yeniden adlandırılan, MVC projesini düzeltti. Yeniden orijinal adına yeniden adlandırıldı, sabit kaldı.

Bunun neden işe yaradığına dair herhangi bir açıklamam yok, ama bizi ciddi bir sorundan kurtardı.

Bu çözümde başka projeleriniz var mı? (Başka bir proje eski bir versiyona atıfta bulunabilir) Genellikle VS'de, dll bağımlılığı çözümdeki tüm projeleri kapsar.

Benim sorunum eski derlemeleri Web Uygulaması altında _bin_deployableAssemblies klasöründe idi. Bu, eski derlemelerin projeyi oluştururken GAC derlemelerinin üzerine yazdığı anlamına geliyordu.

3 saat başka birini kurtarırsa ... durumum biraz farklıydı. Kodumda DevExpress v11.1 v11.1.4.0 kullanıldı. Tüm kodumda doğru referans vardı. Ancak .net bellek profili oluşturucu, GAC'a DevExpress v11.1 v11.1.12.0'ı yükledi. Aslında referans verdiğim bileşenler değildi ama dahili olarak referans verdikleri bileşenler başarısız oldu. Mümkün olduğunca deneyin, önce GAC her zaman kontrol edilir. Derlenmiş ve iyi koştu ama kazanan form tasarımcısı görüntüleyemedim ve yığın izleme hiç yardımcı olmadı. Sonunda .net bellek profiler kaldırıldı ve tüm geri yüklendi.

Benzer bir sorunum vardı ve bin ve obj klasörlerindeki her şeyi silmek ve sorunumu aşmak için yeniden oluşturmak zorunda kaldım. Bu yardımcı olur umarım.

Uygulamayı Visual Studio ortamından (ASP.NET Development Server) sınarken ve / veya hata ayıklarken bu sorunla karşılaşıyorsanız, geliştirme web sitesi klasöründeki tüm geçici dosyaların silinmesi gerekir. Bu klasörün nerede olduğunu öğrenmek için, Windows tepsi simgesinde ASP.NET Development Server simgesini arayın (bunun gibi bir başlığa sahip olmalıdır: ASP.NET Development Server - Port ####), simgeye sağ tıklayın ve Göster'i seçin Ayrıntılar; thn, Fiziksel yol alanı geçici klasörün ne olduğunu söyleyecektir, sorunu çözmek için tüm öğeler silinmelidir. Web sitesini yeniden oluşturup çalıştırın ve sorun çözülmelidir (yine Geliştirme Ortamı için çözülmelidir).

Newtonsoft.json'un farklı sürümlerini referans alan farklı derlemelerle aynı sorunu yaşadım. Benim için çalışan çözüm, Nuget Paket Yöneticisi Konsolu'ndan güncelleme paketi çalıştırıyordu.

Bu hata biraz yanıltıcıydı - x64 mimarisinin belirtilmesini gerektiren bazı DLL'leri yükliyordum. In .csprojdosyası:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Eksik PlatformTargetbu hataya neden oldu.

Ben alıyordum:

Dosya veya montaj 'XXX-new-3.3.0.0' veya bağımlılıklarından biri yüklenemedi. Konumlandırılan derlemenin bildirim tanımı derleme başvurusuyla eşleşmiyor. (HRESULT istisnası: 0x80131040)

Çünkü meclisin ismini XXX.dll etmek XXX-new-3.3.0.0.dll. Adı orijinal haline geri döndürmek hatayı düzeltti.

Neredeyse eski dll kurtulmak için bilgisayarınızı silmek zorunda gibi. Zaten yukarıdaki her şeyi denedim ve sonra sadece bilgisayarımdaki .DLL dosyasının her örneğini silme ve uygulamadan her referansı kaldırma ek adım gitti. Ancak, hala iyi derler ve dll fonksiyonları gayet iyi çalışır. Bunu bir ağ sürücüsünden referans alıp almadığını merak etmeye başlıyorum.

Aynı DLL'nin farklı sürümlerine başvuran bir uygulamanın iki sürümü arasında geçiş yaparken aynı iletiyi aldım. Farklı klasörlerde test yapmama rağmen yanlışlıkla yeni sürümü eski sürümün üzerine kopyaladım.

Bu yüzden kontrol edilecek ilk şey, uygulamanın klasöründeki başvurulan DLL'nin sürümüdür. Her ihtimale karşı.

Belki bu yardımcı olabilir ya da olmayabilir. Hata ayıklama ve sürümlerini temizledim, sonra OBJ klasörünü yeniden adlandırdım. Bu beni nihayet sarhoş etti. Önceki adımlar temelde proje kaldırma referanslarıydı ve bunları proje özelliklerine geri ekliyorlardı.

Visual Studio 2015'te, rahatsız edici Visual Studio Project'in Başvuru Yolları Listesinin boş olmasını sağladım:

Benim için işe yarayan buydu:

Microsoft.IdentityModel.Clients.ActiveDirectorySınıf kitaplığı projesinde 3.19 sürümünü kullanıyordum ancak yalnızca gerçek ASP.NET Web Uygulaması projesinde yüklü 2.22 sürümü vardı. Web uygulaması projesinde 3.19'a yükseltmek hatayı geçti.

Benim durumumda 3 proje, 1 ana proje ve ana proje tarafından referans verilen 2 alt proje vardı .. Bu yüzden ana projeyi güncelleyerek alt projeyi dışarıda bıraktım. Çatışma buradaydı. Tüm projemi güncelledikten sonra her şey yolunda gitti.

VS2017'de, yukarıdaki tüm çözümü denedim, ancak hiçbir şey çalışmıyor. Sürüm oluşturma için Azure adanmışlarını kullanıyoruz.

1. Ekip gezgininden> Kaynak Kontrol Gezgini

2. Sizi uzun süre tahrik eden projeyi seçin

3. Şubeyi veya çözümü sağ tıklayın> Gelişmiş> belirli sürümü edinin

4. Ardından, ekran görüntüsüne göre üzerine yazma dosyalarının onay kutusunu işaretlediğinizden emin olun.

Benim durumumda, yanlışlıkla Telerik paketinin yanlış sürümünü nuget'ten seçtim, nuget daha sonra yanlış sürümle referans verdiğim her paketi değiştirdi. Daha sonra yanlış sürüme bir bağlayıcı yönlendirme ekledi, böylece her şeyi doğru sürümle değiştirdikten sonra bile, yine de yanlış sürümü arıyordu.