Mam dziwny problem, który doprowadza mnie do szału…
Mam prosty projekt biblioteki klas (pełna .NET Framework, 4.6.1) z klasą opakowującą dla funkcjonalności wokół Cosmos DB. Dlatego dodałem pakiet NuGet 1.19.1 „Microsoft.Azure.DocumentDB” do tego projektu. Poza tym mam odniesienie do pakietu NuGet „Newtonsoft.Json” 10.0.3, a także do kilku pakietów NuGet „Microsoft.Diagnostics.EventFlow. *”.
Jak dotąd wszystko kompiluje się bez żadnego błędu.
Ale gdy tylko trafię na moją klasę otoki - zużywaną z prostej usługi bezstanowej usługi Service Fabric (pełna .NET Framework 4.6.1) - i spróbuj wykonać następujący wiersz kodu:
_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);
Otrzymuję ten dziwny błąd w czasie wykonywania:
Wystąpił wyjątek System.IO.FileNotFoundException HResult = 0x80070002
Message = Nie można załadować pliku lub zestawu „System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.
Source = StackTrace: at Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable
1 pożądaneConsistencyLevel)Wyjątek wewnętrzny 1: FileNotFoundException: nie można załadować pliku lub zestawu „System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.
Nie mam absolutnie pojęcia, dlaczego w ogóle nie znaleziono zestawu System.Net.Http - w moim projekcie biblioteki klas znajduje się nawet odniesienie do zestawu .Net Framework Assembly „System.Net.Http 4.0.0.0”.
Czego też nie rozumiem, to to, że jest to dziwne przekierowanie do 4.2.0.0 - skąd to pochodzi? Aby obejść ten problem, próbowałem dodać następujące przekierowanie do pliku app.config usługi Service Fabric (która zużywa bibliotekę klas):
Ale nadal bez różnicy, nadal pojawia się błąd w czasie wykonywania.
Czy ktoś ma wskazówkę? Czy ktoś widział taki problem?
Dzięki i pozdrawiam, OliverB
Odpowiedzi:
Problem, z którym się spotykasz, jest związany z programem Visual Studio, zwłaszcza 2017, który jest dostarczany z
System.Net.Http v4.2.0.0
. Jednak przyjęcie nowego sposobu, w którym wszelkie odwołania powinny być wykonywane za pośrednictwem NuGet, którego najnowsza wersjaSystem.Net.Http
to 4.3.3 zawiera dll w wersji 4.1.1.2.Problem polega na tym, że program VS w czasie kompilacji, a także w czasie wykonywania, zignoruje twoje odwołanie i spróbuje odwołać się do biblioteki DLL, o której wie.
Jak to naprawić:
c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\
); jeśli masz inną wersję, ścieżka będzie się nieco różnić, choć niewieleBłędy czasu wykonywania: dodaj przekierowanie powiązania zestawu
Jeśli zajrzysz do Google w Internecie, znajdziesz kilka otwartych problemów z Microsoftem na ten temat, więc miejmy nadzieję, że naprawią to w przyszłości.
Mam nadzieję że to pomoże.
Aktualizacja:
Patrząc na znalezienie pewnych trwałych poprawek dla tego problemu, aby działały na agentach kompilacji, zauważyłem, że po migracji do nowego modelu NuGet PackageReference (
.csproj
nie wpackages.config
) zwykle działa lepiej. Oto link do przewodnika, jak wykonać tę aktualizację: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-referenceźródło
Usunięcie przekierowania wiązania zadziałało dla mnie, możesz spróbować je usunąć:
źródło
dependentAssembly
Dodatek do odpowiedzi już podanej przez @AndreiU i jak lokalnie odtwarzać błędy uruchomieniowe.
Podczas wdrażania na platformie Azure, a nie lokalnie, wystąpił poniżej błąd środowiska wykonawczego.
Kiedy zacząłem przeglądać zestawy, zauważyłem, że mój projekt sieci Web i projekt usługi były przeznaczone dla różnych wersji
System.Net.Http
.Projekt internetowy:
Projekt serwisowy:
Łatwo jest pomyśleć, że jest to spowodowane niedopasowaniem wersji, ale kluczowe jest tutaj przyjrzenie się błędowi
The system cannot find the file specified.
.Patrząc na właściwość path, widzimy, że projekt sieci Web jest przeznaczony dla zestawu .Net Framework, podczas gdy usługa jest przeznaczona dla zestawu z programu Visual Studio 2017. Ponieważ na serwerze nie jest zainstalowany program Visual Studio 2017, wystąpi błąd w czasie wykonywania.
Ścieżka internetowa:
Ścieżka serwisowa:
Coś tak prostego jak ustawienie
Copy Local
, abytrue
można rozwiązać ten problem, jednak nie we wszystkich przypadkach.Aby odtworzyć błąd na komputerze lokalnym, po prostu usuń potrzebne pliki
System.Net.Http.dll
z folderu określonego programu Visual Studio. Spowoduje to błąd w czasie wykonywania i prawdopodobnie błędy kompilacji. Po ich naprawieniu wszystko powinno działać, przynajmniej mi się udało.Jeśli zainstalowałeś
System.Net.Http
za pomocą,NuGet
sprawdź, który zestaw jest używany, patrząc na.csproj
wersję.System.Net.Http 4.3.4
podaje na przykład następujący montaż:Jeśli używasz serwera kompilacji, takiego jak Jenkins, TeamCity lub AppVeyor,
.dll
może tam również brakować środowiska wykonawczego . W takim przypadku może nie pomóc użycie wersji NuGet System.Net.Http lub usunięcie brakującego.dll
lokalnego. Aby rozwiązać ten błąd, spójrz na wersję, która nie została znaleziona, i na konkretną wersjęPublicKeyToken
. Następnie utwórz przekierowanie wiążące w jednymWeb.config
lub wApp.config
zależności od projektu. W moim przypadku zamiast tego chciałbym użyć 4.0.0.0:Dobry wątek na Githubie dotyczący problemu:
https://github.com/dotnet/corefx/issues/22781
źródło
Właśnie zainstalowałem
System.Net.Http
za pomocą NuGet. Możesz go pobrać tutaj:https://www.nuget.org/packages/System.Net.Http/
ASP.NET MVC
Projekt pracuję nad celami.NET 4.6.1
. Działa doskonale na moim komputerze podczas debugowania wIIS Express
programie Visual Studio 2019.Problem wystąpił podczas próby uruchomienia aplikacji wdrożonej na platformie Azure. Otrzymałem ten błąd:
To, co naprawdę zadziałało w moim przypadku, to otwarcie pliku .csproj i wyszukanie czegoś
System.Net.Http
takiego jak na poniższym zrzucie ekranu ...Zobacz, że
.csproj
plik ma wersję4.1.1.3
:W
<HintPath>
rzeczywistości wskazuje na..\packages
folder z Nuget, to znaczy jest to prawdziwa wersja zainstalowana przez Nuget. Po wdrożeniu ta konkretna wersja zostanie również przywrócona po stronie serwera i wszystko powinno działać z przekierowaniem powiązania.... więc przekierowanie powiązania powinno zawierać tę konkretną wersję w
Web.config
następujący sposób:To rozwiązało problem w moim przypadku po kilku zatwierdzeniach do Azure Kudu . Witryna internetowa platformy Azure została ostatecznie uruchomiona bez błędów.
źródło
To, co zrobiłem, aby naprawić problem, zostało usunięte ze wszystkich powiązań z pliku web.config i zrobiłem
Update-Package -reinstall
Spowodowało to usunięcie wielu starych wiązań, które prawdopodobnie nie muszą tam być, i faktycznie zrobiło dobre czyszczenie.
źródło
Napotkałem ten błąd podczas wdrażania usługi internetowej na jednym z naszych serwerów. Projekt dotyczył platformy .Net Framework 4.7.2, która nie była zainstalowana na serwerze. Zainstalowanie frameworka 4.7.2 na serwerze rozwiązało problem.
źródło
Odpowiedź Andrieja U prowadzi do mojego zbawienia. Jednak rozumowanie nie pasowało do mojego przypadku. Dla osób, które są w tym samym scenariuszu co ja:
Był to błąd czasu wykonania (nie czasu kompilacji), w którym kompilacja powiodła się, ale działała na jednym komputerze, ale nie na serwerze. Rozwiązanie: - Dodano pakiet System.Net.Http. - Zmień nazwę pliku: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (np. Zmień nazwę na: System.Net.Http.dll.BAK) na budować serwer.
Nie miałem i nadal nie mam przekierowań zestawu dla tej biblioteki dll
źródło
Jedno proste rozwiązanie, które znalazłem, obniża platformę docelową dla projektu internetowego do wersji 4.6.
Tworzę aplikację kliencką i internetową, klient ma .NET Framework 4.7.1, a sieć ma to samo i mam ten sam problem, kiedy obniżam wersję docelową .NET Framework dla sieci, to działa dla mnie.
źródło
Po kilku dniach zmagania się z tym w końcu udało mi się rozwiązać problem .Net 4.7.2 / System.Net.Http dla mojego projektu. Oprócz zmiany pliku * .csproj na wersję docelową frameworka 4.7.2 musiałem również zaktualizować app.config w projektach z
do:
źródło
Miałem ten sam problem. W końcu rozwiązałem to, zmieniając plik Deploy-FabricApplication.ps1 na coś takiego
Znalazłem 4.2.0.0 System.Net.Http.dll, który jest x64. Przed wdrożeniem tego skryptu kopiuje bibliotekę dll do katalogu pakietu i zmienia plik konfiguracyjny, aby jawnie używać tego pliku. Napisałem także bloga o moich problemach z System.Net.Http pod adresem http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html
Nie zapomnij zamienić [ProjectName] na własną nazwę projektu
Mam nadzieję, że to pomoże, nie krępuj się zapytać
źródło
Dla mnie było to coś naprawdę dziwnego. Potrzebne godziny debugowania po znalezieniu przyczyny. Nie wydarzyło się to lokalnie, ale tylko przy użyciu Jenkinsa do budowy projektu.
Miałem małą bibliotekę korzystającą z dotnet standart 2.0, a głównym projektem był projekt WCF oparty na normalnym .NET (mój był konkretnie w wersji 4.6.1). Ale w klasie startowej standardowej biblioteki dotnet miałem kod, który wyglądał następująco:
Interfejs IStaticDataConfiguration wygląda jak poniżej:
Ten interfejs znajduje się w bibliotece standardowej dotnet, gdy implementacja znajduje się poza nią (znajduje się w projekcie WCF).
Spoza biblioteki wywoływałem
AddStaticDataConfiguration
metodę jak poniżej:Problem polega na tym, że przechodzę
Func<HttpClient>
z normalnego projektu .NET do standardowej biblioteki dotnet, której z jakiegoś szalonego powodu standard dotnet nie lubi i może myśli, żeHttpClient
pochodzi z różnych klas, w wyniku czego rzucaSystem.Net.Http 4.x.x.x
not found wyjątek. Po usunięciu kodu, aby nie akceptować aHttpClient
z normalnego projektu .NET, ale tworząc nowąfunc
w samej bibliotece, jest szczęśliwy i działa dobrze. Mam nadzieję, że może to pomóc komuś innemu, ponieważ ten błąd występuje z wielu powodów :)źródło
Moje rozwiązanie było podobne do @ Raquib's. Mój projekt miał wersję 4.7.2 i działał dobrze na moim komputerze. Za każdym razem, gdy instalowałem na naszym serwerze deweloperskim, pojawiał się problem wspomniany w pytaniu. Okazuje się, że najwyższa wersja .net na serwerze to 4.6.1. Zmiana wersji mojego projektu na 4.6.1 rozwiązała problem. Aktualizacja wersji .net serwera nie była dla mnie opcją.
źródło
Myślę, że część odpowiedzi można znaleźć w dokumentacji Microsoftu .
Jak wskazuje odpowiedź @Vivek Sharma, usuwając:
rozwiązałem problem w 3 takich przypadkach w mojej aplikacji. Podczas badania biblioteki DLL za pomocą programu PowerShell, na przykład:
Wyjścia
Najwyraźniej przekierowanie do powiązania
4.2.0.0
nie zadziała, ponieważ wysyłamy dane4.0.0.0
do bin.Warto też sprawdzić GAC, żeby zobaczyć czy tam też nie brakuje zespołu:
W moim przypadku w GAC również brakowało konkretnej wersji. Jeśli biblioteka DLL znajdowała się w GAC, powinna zostać znaleziona w procesie wiązania zestawu .
źródło
Najpierw usuń z lokalnego systemu plików:
Następnie usuń wszystkie odwołania w projektach i dodaj odwołanie 4.0.
To rozwiązało mój problem.
źródło