MVC4 Web API'sinde 'System.Net.Http, Sürüm = 2.0.0.0 dosyası veya derlemesi yüklenemedi

Biraz tuhaf bir problemim var.
MVC 4 ve yeni Web API ile bir uygulama geliştirdim ve yerel olarak gayet iyi çalışıyor. MVC4'ü sunucuya kurdum ve uygulamayı konuşlandırdım. Şimdi şu hatayı alıyorum:

Dosya veya derleme 'System.Net.Http, Sürüm = 2.0.0.0, Culture = nötr, PublicKeyToken = 31bf3856ad364e35' veya bağımlılıklarından biri yüklenemedi. Bulunan derlemenin bildirim tanımı, derleme başvurusuyla eşleşmiyor. (HRESULT istisnası: 0x80131040)

Açıklama: Mevcut web isteğinin yürütülmesi sırasında işlenmeyen bir istisna oluştu. Hata hakkında ve hatanın nereden kaynaklandığı hakkında daha fazla bilgi için lütfen yığın izlemeyi inceleyin

Yeterince komik, yerel olarak paket klasörümde veya ASP.NET MVC 4 \ Assemblies klasöründe bulunan System.Net.Http sürümü 1.0.0.0. Aslında System.Net.Http referansını projemden kaldırdım, ancak yine de aynı mesajı alıyorum. 2.0.0.0 referansını nereden aldığı ve neden yerel olarak çalışıp sunucuda çalışmayacağı konusunda biraz kafam karıştı.

Nuget bağımlılıklarına baktığımızda:

ASP.NET WEb API Çekirdek Kitaplıkları (Beta) System.Net.Http.Formatting'e bağlıdır.
Ve System.Net.Http.Formatting System.Net.Http'ye bağlıdır.
Sanırım bu nereden geliyor. Ama bu paketin 2.0.20126.16343 Sürümü yüklüyse, sadece içindeki dll'de 1.0.0.0 sürümü var

Bir şey mi kaçırıyorum?

GÜNCELLEME:

Bu, başka bir ASP.NET uygulamasının bir alt uygulamasıdır, ancak diğeri hala WebForms'a dayanmaktadır. Yani bir şeyler karışıyor. Ancak web.config'deki derleme bölümünün altında bir temizlik yaparsam, uygulamanın kendisini artık bulamazsa.

Uygulamamı appharbor'a yerleştirirken de aynı sorunu yaşadım. Sorun henüz .NET 4.5'i desteklemiyor. Ben ne yaptım.

1. Projemi .NET 4.0 profiline geçirdim.
2. Kaldırılan Web API NuGet paketi.
3. Web API (Beta) NuGet paketi yeniden yüklendi.
4. .Csproj dosyasının başvurulan TÜM derlemeler için içerdiği doğrulandı, bu nedenle dosyayı her zaman GAC yerine Bin klasöründen alacak.

Önceden dönüştürülmüş (.NET 4.5'ten 4.0'a) web uygulamasını IIS 6.0'da dağıtırken aynı hatayı aldım.

Bulduğum web.config çalışma zamanı bölümünde

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

ben değiştim

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Şimdi cazibe gibi çalışıyor.

Benimki ile çalıştı:

1-4'ten 2.0'a yönlendirmeye dikkat edin

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Projenizin Referanslar klasöründe bu dll'ye referans olmalı ve sürüm 2.0.0.0 olmalıdır. Bunun Yerel Kopyala = doğru olarak ayarlandığından emin olun. Ve sonra sunucu uygulamanızın bin klasörüne giden yolu bulduğundan emin olun.

Bu, şu anda nuget tarafından yönetilen kütüphanelerden biridir. Bu yüzden Nuget'i açın ve her şeyin güncel olduğundan emin olun. Ve proje paketleri dizininizde dosya burada olmalıdır: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Ayrıca yeni bir MVC4 uygulaması oluşturmayı deneyebilir ve dosyanın bunun için görünüp görünmediğine bakabilirsiniz.

Benim durumumda bunu çok daha kolay bir şekilde düzelttim, sadece nuget paketinin referansına bir HintPath verin:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

Benim durumumda istemeden NuGet aracılığıyla System.Net.Http sürüm 2.1.10.0'a bir bağımlılık ekledim. NuGet Paket Yöneticisinde ondan kurtulamadım (çünkü diğer paketler buna bağlı görünüyordu). Ancak bu paketler bu özel sürüme bağlı değildir. İşte ondan kurtulmak için yaptığım şey (bunun yerine NuGet konsolunu da kullanabilirsiniz (–force parametresini kullanarak):

• Package.config'deki Microsoft.Net.Http sürümünü 2.1.10.0'dan 2.0.0.0'a değiştirin
• NuGet Paket Yöneticisinden BCL Taşınabilirlik Paketini Kaldırma
• Bağımlı kitaplıklardan elle kurtulun (2.1.10.0 sürümüne sahip System.Net.Http. *)
• System.Net.Http 2.0.0.0'a bir başvuru ekleyin

Dosya yapılandırmasında bağımlı Meclisi sildim:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Şimdi iyi çalışıyor.

Bu sorunla, sözde dağıtım için "hazır" olan bir test sunucusunda (Windows 2008 R2) karşılaşıyordum;)

İpucu, DEV makinem ile dağıtım sunucum arasındaki System.net sürümlerini kontrol ettiğimde eşleşmedikleri idi.

Aşağıdaki adımlar kullanılarak düzeltildi:

1. NET Framework 4.5 Bağımsız yükleyici BURADAN indirildi

2. Yükleyiciyi dağıtım makinesinde çalıştırdı

Çerçevenin kurulumundan sonra, sunucu yeniden başlatma istedi, bunu yaptı ve volla! Gitmeye hazırız !!

VS 2013 kullanıyoruz, yeni bir MVC 4 Web API'si oluşturduk ve system.net.http.dll'nin TeamCity sunucumuzda oluşturulduğunda doğru sürüm olmamasıyla ilgili bir sorun yaşadık, ancak VS 2013'e sahip yerel geliştirici makinelerimizde iyi bir şekilde inşa ediliyor. Kurulmuş.

Sonunda sorunu belirledik.

Yeni bir MVC 4 Web API oluştururken ve proje oluştururken çerçeve 4.0'ı seçerken, DLL için doğru NuGet paketi sürümünün yerleştirildiğini gördük: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

Ancak, bu proje için .csproj dosyası, bu system.net.http.dll dosyasının yolunun şu olduğunu söyledi: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Dolayısıyla, derleme denendiğinde bu yol farkında başarısız olur, ancak dosyanın doğru çerçeve sürümünü geliştirici makinesinde başka bir yerde bulur, ancak TeamCity derleme sunucumuzda bulmaz.

Şimdiye kadar bulduğumuz tek fark bu. .Csproj dosyasındaki yolu değiştirmek ve VS2013 ile yerel Dev makinesinde oluşturmak hala buluyor.

Bunu sürüm denetiminde kontrol etmek ve TeamCity derleme sunucumuza sahip olmak (VS 2013 yerel olarak yüklenmeden) artık çözüm için NuGet paket klasöründe .dll'nin doğru sürümünü bulur ve system.net.http'nin başka bir sürümünü aramak yerine başarılı bir şekilde derler. .dll ve çerçeveyle eşleşmeyen yeni bir sürüm bulmak, dolayısıyla derleme hatalarına neden olur.

Bunun yardımcı olup olmadığından emin değilim.

DLL için proje dosyası yolunuzu kontrol edin ve DLL için paket klasörü yolunuzla eşleştiğinden emin olun.

Sadece benim için işe yarayan diğer cevapları basitleştirmek.

NuGet yöneticisine gittim, ilgili paketleri (Benim durumumda, "Microsoft ASP.NET Web API 2.1 İstemci Kitaplıkları" ve "Json.NET") kaldırdım ve yeniden yükledim. Sadece birkaç tıklama aldım.

Projeyi kapatın, tekrar açın. Ardından, Temiz Çözüm + Oluşturun. Benim için çalışıyor

2.2.15.0 sürümü için şunu yaptım:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>

Ben de aynı sorunu yaşadım! VS'deki Uyarılar sekmesine bir göz attım ve nuget paketlerimden birinin DOLAYLI OLARAK .NETFramework Sürüm 4.5.0.0'a başvurduğunu fark ettim. Bu paketi kaldırmam ve ardından 4.0 sürümünü yeniden yüklemem gerekiyordu, ancak 4.0'ı destekleyen paket sürümlerini belirttiğinizden emin olun (paketi yüklerken belirtmezseniz, sanırım varsayılan olarak 4.5'e dönecektir). Bu yardımcı olur umarım!

Bunu dağıtımdan sonra bir sunucuda yaşadık. Ya şunlardan kaynaklanmıştır:

A) Silinmiş olması gereken, çöp kutusu klasöründe hala asılı duran eski dosyalar

veya

B) Uygulama Havuzu Kimliği kullanıcısı için klasöre okuma erişiminin olmaması.

Başka bir deyişle, bizim için bu, site için klasörler üzerindeki izinlerin düzeltilmesi ve bin klasörünün silinmesi ve yeniden dağıtılmasıyla çözüldü.

Gembox.spreadsheet.dll sürüm 31 ile aynı sorunu yaşadım.

"Dosya veya derleme yüklenemedi 'GemBox.Spreadsheet, Sürüm = 39.3.30.1095, Culture = nötr, PublicKeyToken = b1b72c69714d4847' veya bağımlılıklarından biri. Bulunan derlemenin bildirim tanımı, derleme referansıyla eşleşmiyor. (HRESULT istisnası: 0x80131040 ) "

Bu makalelerden neredeyse her şeyi denedim ve hiçbiri işe yaramadı. Sadece basit bir adımla düzeltildi.

Temelde dll için doğru sürüm referansını ayarlayan bireysel projeler oluşturmayı denedim ve hata tamamen çözümden kurtuldu.

Benzer bir soruna gidin ve birçok yorumda bahsedilen direktif iyi çalıştı

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Bununla birlikte, eski sürüm kapsamının yeterince yüksek olmasını sağlamanız gerekir, aksi takdirde daha yeni sürümler ihtiyaç duyduğunuz belirli sürüme yeniden yönlendirilmeyebilir ve bu yeni referansı kullanan konum, eski referans zaten bin dizininde olduğundan düzgün çalışmayabilir.

Bu hata (ve benzeri) için, biraz daha eski bir sürümün bile bağımlılıkları olabileceğinden, aynı başvurulan bileşen sürümlerinin çözümde başvurulan her sınıf kitaplığında tutarlı olmasını sağlamak için NuGet Consolidate (Çözüm> NuGet Paketlerini Yönet ...) üzerinden geçmeye değer. diğer eski bileşenlerde. Güncellemeler ile birlikte kullanımı kolaydır ve çok fazla acı çekmeden tasarruf edebilir.

Bu benim için bu sorunu çözdü ve MVC veya diğer web tabanlı NuGet bileşenlerine başvuran yardımcı kitaplıklar oluşturuyorsanız, aşina olmanız gerektiğini söyleyebilirim.