Nie można załadować pliku lub zestawu „System.Net.Http, Version = 2.0.0.0” w MVC4 Web API

Mam trochę dziwny problem.
Opracowałem aplikację z MVC 4 i nowym interfejsem API sieci Web i działa dobrze lokalnie. Zainstalowałem MVC4 na serwerze i wdrożyłem aplikację. Teraz pojawia się następujący błąd:

Nie można załadować pliku lub zestawu „System.Net.Http, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zestawu nie jest zgodna z odwołaniem do zestawu. (Wyjątek od HRESULT: 0x80131040)

Opis: wystąpił nieobsługiwany wyjątek podczas wykonywania bieżącego żądania internetowego. Przejrzyj ślad stosu, aby uzyskać więcej informacji na temat błędu i miejsca jego powstania

Co zabawne, wersja System.Net.Http, którą mam lokalnie w folderze z pakietami lub w folderze ASP.NET MVC 4 \ Assemblies, to 1.0.0.0. W rzeczywistości usunąłem odwołanie do System.Net.Http z mojego projektu, ale nadal otrzymuję ten sam komunikat. Jestem trochę zdezorientowany, skąd bierze odniesienie 2.0.0.0 i dlaczego miałoby działać lokalnie, ale nie na serwerze.

Patrząc na zależności nuget:

ASP.NET WEb API Core Libraries (Beta) zależy od System.Net.Http.Formatting.
A System.Net.Http.Formatting zależy od System.Net.Http.
Myślę, że stąd to się bierze. Ale mam zainstalowaną wersję 2.0.20126.16343 tego pakietu, po prostu dll w środku ma wersję 1.0.0.0

Czy coś mi brakuje?

AKTUALIZACJA:

Jest to aplikacja podrzędna innej aplikacji ASP.NET, ale ta druga nadal jest oparta na formularzach internetowych. Więc coś się psuje. Ale jeśli wyczyszczę sekcję zespołu w pliku web.config, jeśli nawet nie znajdę już samej aplikacji.

Miałem ten sam problem z wdrożeniem mojej aplikacji w Appharbor. Problem nie obsługuje jeszcze .NET 4.5. Co ja zrobiłem.

1. Zmieniłem projekt na profil .NET 4.0.
2. Odinstalowany pakiet NuGet interfejsu API sieci Web.
3. Ponownie zainstalowano pakiet NuGet interfejsu API sieci Web (Beta).
4. Zweryfikowano, że plik .csproj zawiera WSZYSTKIE przywoływane zestawy, więc zawsze pobierze go z folderu Bin zamiast z GAC.

Wystąpił ten sam błąd podczas wdrażania wcześniej przekonwertowanej (z .NET 4.5 na 4.0) aplikacji internetowej w usługach IIS 6.0.

W sekcji runtime web.config znalazłem

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

do którego się zmieniłem

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

Teraz działa jak urok.

Mój współpracował z:

Zwróć uwagę na przekierowanie z 1-4 do 2.0

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

W folderze References twojego projektu powinno znajdować się odwołanie do tej biblioteki dll, a wersja powinna być 2.0.0.0. Upewnij się, że jest to ustawione na Copy Local = true. A następnie upewnij się, że trafia do folderu bin aplikacji serwera.

Jest to jedna z bibliotek, która jest teraz zarządzana przez nuget. Więc otwórz Nuget i upewnij się, że wszystko jest aktualne. A w katalogu pakietów projektów plik powinien być tutaj: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Możesz także spróbować utworzyć nową aplikację MVC4 i sprawdzić, czy plik pojawia się dla tej aplikacji.

W moim przypadku naprawiłem to w znacznie łatwiejszy sposób, po prostu podaj HintPath do odniesienia do pakietu nuget:

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

W moim przypadku nieumyślnie dodałem zależność do System.Net.Http w wersji 2.1.10.0 przez NuGet. Nie mogłem się go pozbyć w Menedżerze pakietów NuGet (ponieważ inne pakiety wydawały się od niego zależne). Jednak te pakiety nie są zależne od tej konkretnej wersji. Oto, co zrobiłem, aby się go pozbyć (zamiast tego możesz również użyć konsoli NuGet (używając parametru –force):

• Zmień wersję Microsoft.Net.Http w packages.config z 2.1.10.0 na 2.0.0.0
• Odinstaluj pakiet przenośności BCL w Menedżerze pakietów NuGet
• Ręcznie usuń biblioteki zależne (System.Net.Http. *, Które mają wersję 2.1.10.0)
• Dodaj odwołanie do System.Net.Http 2.0.0.0

W konfiguracji pliku usunąłem zależny zespół:

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

Teraz działa dobrze.

Miałem do czynienia z tym problemem na serwerze testowym (Windows 2008 R2), który podobno był „gotowy” do wdrożenia;)

Wskazówka była taka, że ​​kiedy sprawdzałem wersje System.net między moim komputerem DEV a serwerem wdrażania, nie pasowały.

Naprawiono, wykonując poniższe czynności:

1. Pobrano samodzielny instalator .NET Framework 4.5 TUTAJ

2. Uruchomiono instalator na maszynie wdrożeniowej

Po instalacji frameworka, serwer chciał się zrestartować, więc to zrobiłem i volla! Jesteśmy gotowi do pracy !!

Używamy VS 2013, utworzyliśmy nowy interfejs API sieci Web MVC 4 i wystąpił problem z wersją system.net.http.dll, która nie jest poprawną wersją po zbudowaniu na naszym serwerze TeamCity, ale działa dobrze na naszych lokalnych maszynach programistycznych, które mają VS 2013 zainstalowany.

W końcu ustaliliśmy problem.

Podczas tworzenia nowego interfejsu API sieci Web MVC 4 i wybierania frameworku 4.0 przy tworzeniu projektu stwierdziliśmy, że w: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ została umieszczona poprawna wersja pakietu NuGet dla DLL System.Net.Http.dll

Jednak plik .csproj dla tego projektu mówi, że ścieżka do tego pliku system.net.http.dll to: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Tak więc, gdy próba kompilacji kończy się niepowodzeniem na tej różnicy ścieżek, ale znajduje poprawną wersję struktury pliku w innym miejscu na komputerze dewelopera, ale nie na naszym serwerze kompilacji TeamCity.

Jak dotąd jest to jedyna różnica, jaką znaleźliśmy. Zmiana ścieżki w pliku .csproj i tworzenie na lokalnej maszynie deweloperskiej z VS2013 nadal działa find.

Sprawdzanie tego w kontroli wersji i posiadanie naszego serwera kompilacji TeamCity (bez zainstalowanego lokalnie VS 2013) teraz znajduje poprawną wersję .dll w folderze pakietu NuGet dla rozwiązania i kompiluje się pomyślnie, zamiast szukać innej wersji system.net.http .dll i znalezienie nowszej wersji, która nie jest zgodna ze strukturą, powoduje awarie kompilacji.

Nie jestem pewien, czy to pomoże.

Sprawdź ścieżkę pliku projektu dla biblioteki DLL i upewnij się, że jest zgodna ze ścieżką folderu pakietu dla biblioteki DLL.

Po prostu upraszczam inne odpowiedzi, co zadziałało dla mnie.

Poszedłem do menedżera NuGet, odinstalowałem powiązane pakiety (w moim przypadku „Biblioteki klienta Microsoft ASP.NET Web API 2.1” i „Json.NET”) i ponownie je zainstalowałem. Wystarczyło kilka kliknięć.

Zamknij projekt, otwórz go ponownie. Następnie Clean Solution + Build. Pracuje dla mnie

Dla wersji 2.2.15.0 zrobiłem to:

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

Miałem dokładnie ten sam problem! Rzuciłem okiem na moją kartę Ostrzeżenia w VS i zauważyłem, że jeden z moich pakietów NuGet POŚREDNIO odwołuje się do .NETFramework w wersji 4.5.0.0. Musiałem odinstalować ten pakiet, a następnie ponownie zainstalować wersję 4.0, ale pamiętaj, aby określić wersje pakietów, które obsługują 4.0 (myślę, że domyślnie powrócą do 4.5, jeśli nie określisz podczas instalacji pakietu). Mam nadzieję że to pomoże!

Działo się to na serwerze po wdrożeniu. Było to spowodowane:

A) Stare pliki w folderze bin wciąż wiszące w pobliżu, które powinny zostać usunięte

lub

B) Brak dostępu do odczytu folderu dla użytkownika tożsamości puli aplikacji.

Innymi słowy, dla nas problem ten został rozwiązany poprzez naprawienie uprawnień do folderów witryny i wyczyszczenie folderu bin i ponowne wdrożenie.

Miałem ten sam problem z Gembox.spreadsheet.dll w wersji 31.

„Nie można załadować pliku lub zestawu GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zestawu nie jest zgodna z odwołaniem do zestawu. (Wyjątek od HRESULT: 0x80131040 ) ”

Próbowałem prawie wszystkiego z tych artykułów i żaden z nich nie działał. Właśnie został naprawiony za pomocą prostego kroku.

Próbowałem budować indywidualne projekty, które zasadniczo ustawiały poprawną wersję odniesienia do biblioteki dll i błąd całkowicie zniknął z rozwiązania.

Idź do podobnego problemu i wspomniana w wielu komentarzach dyrektywa działała dobrze

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

Chociaż musisz upewnić się, że pokrycie starej wersji jest wystarczająco wysokie, w przeciwnym razie nowsze wersje mogą nie zostać przekierowane do określonej wersji, której potrzebujesz, i lokalizacji przy użyciu tego nowszego odwołania nie będzie działać poprawnie, ponieważ starsze odniesienie znajduje się już w katalogu bin.

W przypadku tego błędu (i podobnego) warto przejść przez konsolidację NuGet (rozwiązanie> Zarządzaj pakietami NuGet ...), aby upewnić się, że te same wersje składników, do których odwołuje się, są spójne w każdej bibliotece klas, do której odwołuje się rozwiązanie, ponieważ nawet nieco starsza wersja może mieć zależności na innych starszych komponentach. Jest łatwy w użyciu w połączeniu z aktualizacjami i może zaoszczędzić wiele bólu.

To rozwiązało ten problem i powiedziałbym, że trzeba się z nimi zapoznać, jeśli tworzysz biblioteki pomocnicze, które również odwołują się do MVC lub innych składników NuGet opartych na sieci Web.