Không tìm thấy sự cố lạ với System.Net.Http 4.2.0.0


108

Tôi có một vấn đề kỳ lạ, khiến tôi phát điên lên…

Tôi có một Dự án thư viện lớp đơn giản (Full .NET Framework, 4.6.1) với lớp trình bao bọc cho chức năng xung quanh Cosmos DB. Do đó, tôi đã thêm Gói NuGet “Microsoft.Azure.DocumentDB” 1.19.1 vào dự án này. Ngoài ra, tôi có tham chiếu đến Gói NuGet 10.0.3 “Newtonsoft.Json”, cũng như một vài Gói NuGet "Microsoft.Diagnostics.EventFlow. *".

Cho đến nay, mọi thứ biên dịch mà không có bất kỳ lỗi nào.

Nhưng ngay sau khi tôi nhấn vào lớp trình bao bọc của mình - được sử dụng từ một Dịch vụ không trạng thái của Service Fabric (Full .NET Framework 4.6.1) - và cố gắng thực thi dòng mã sau:

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

Tôi gặp lỗi kỳ lạ này trong thời gian chạy:

System.IO.FileNotFoundException xảy ra HResult = 0x80070002
Thông báo = Không thể tải tệp hoặc lắp ráp 'System.Net.Http, Phiên bản = 4.2.0.0, Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a' hoặc một trong các phụ thuộc của nó. Hệ thống không thể tìm thấy các tập tin được chỉ định.
Source = StackTrace: tại Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 mong muốnConsistencyLevel)

Ngoại lệ bên trong 1: FileNotFoundException: Không thể tải tệp hoặc lắp ráp 'System.Net.Http, Phiên bản = 4.0.0.0, Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a' hoặc một trong các phụ thuộc của nó. Hệ thống không thể tìm thấy các tập tin được chỉ định.

Tôi hoàn toàn không biết tại sao không tìm thấy lắp ráp System.Net.Http - thậm chí còn có một tham chiếu hợp ngữ trong dự án thư viện lớp của tôi tới .Net Framework Assembly “System.Net.Http 4.0.0.0”.

Những gì tôi cũng không hiểu là, có sự chuyển hướng ràng buộc kỳ lạ này đến 4.2.0.0 - điều đó đến từ đâu? Để giải quyết vấn đề này, tôi đã cố gắng thêm chuyển hướng sau vào app.config của Dịch vụ Vải Dịch vụ (đang sử dụng thư viện lớp):

Nhưng vẫn không có gì khác biệt, tôi vẫn gặp lỗi trong thời gian chạy.

Có ai có manh mối không? Có ai gặp vấn đề như vậy không?

Trân trọng cảm ơn OliverB


3
Xin chào, OliverB! Bạn có tìm thấy giải pháp cho vấn đề này không? Tôi chỉ phải đối mặt với tình huống tương tự và đó là một cơn ác mộng :-(
user1178399

@HansPassant rằng liên kết đó hiện đã bị hỏng
reggaeguitar Ngày

tôi trả lời câu này: stackoverflow.com/a/63031440/330680
Mahdi

Câu trả lời:


129

Vấn đề bạn đang gặp phải liên quan đến Visual Studio, đặc biệt là phiên bản 2017 được vận chuyển cùng System.Net.Http v4.2.0.0. Tuy nhiên, việc áp dụng cách thức mới, theo đó mọi tham chiếu phải được thực hiện thông qua NuGet, phiên bản mới nhất System.Net.Httplà 4.3.3 chứa phiên bản dll 4.1.1.2.

Vấn đề là VS tại thời điểm xây dựng và thời gian chạy cũng sẽ bỏ qua tham chiếu của bạn và nó sẽ cố gắng tham chiếu đến DLL mà nó biết.

Cách khắc phục:

  • đảm bảo rằng mọi tham chiếu đến System.Net.Http đều được thực hiện qua NuGet
  • Lỗi thời gian xây dựng: thay đổi phần mở rộng của System.Net.Http.dll (hoặc di chuyển nó đến một nơi khác ... về cơ bản loại bỏ nó) được vận chuyển với VS 2017 ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); nếu bạn có một phiên bản khác thì đường dẫn sẽ hơi khác một chút, mặc dù không nhiều
  • Lỗi thời gian chạy: thêm chuyển hướng liên kết lắp ráp

Nếu bạn tìm kiếm trực tuyến trên google, bạn sẽ tìm thấy một số vấn đề mở với Microsoft về vấn đề này, vì vậy hy vọng họ sẽ sửa lỗi này trong tương lai.

Hi vọng điêu nay co ich.

Cập nhật:

Khi xem xét việc tìm kiếm một số bản sửa lỗi vĩnh viễn cho vấn đề này để hoạt động trên các tác nhân xây dựng, hãy lưu ý rằng nếu bạn chuyển sang mô hình NuGet PackageReference mới ( .csprojkhông phải trong packages.config) có xu hướng hoạt động tốt hơn. Đây là liên kết đến hướng dẫn về cách thực hiện nâng cấp này: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference


Có vẻ như họ đang chạm vào vesion trong net472 github.com/Microsoft/dotnet-framework-early-access/blob/master/…
Paul Miller

6
Rất cám ơn, tôi đã rất cố gắng giải quyết vấn đề này trong vài giờ qua!
Flinkman

22
Chỉ lưu ý rằng vấn đề có thể được giải quyết bằng cách thực sự loại bỏ các bindRedirects nếu bạn đang làm việc với .NET 4.7.2.
Alternatex

1
Vấn đề tương tự ngày hôm nay khi nâng cấp lên 4.7.2. System.IO.Compression và System.Runtime cũng bị ảnh hưởng. Xóa các chuyển hướng ràng buộc đã giải quyết được vấn đề.
JB. Với Monica.

7
Đúng! Cuối cùng! Theo @Alternatex và JB ở trên, đối với 4.7.2 loại bỏ các bindRedirects và bây giờ là vàng. Thật là khó khăn cho mỗi bản cập nhật khung công tác tìm ra bài hát và thói quen nhảy mới nhất cần thiết cho System.Net.Http.
Ted

76

Xóa chuyển hướng ràng buộc phù hợp với tôi, bạn có thể thử xóa nó:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

2
Đó là một trong những điều 1st tôi đã cố gắng, nhưng không thành công
OliverB

2
Loại bỏ bindRedirect đã giải quyết được vấn đề cho tôi. Các bài kiểm tra đơn vị không vượt qua với cùng một lỗi như OP và bây giờ chúng hoạt động.
Edu

1
Đây có phải là mã đầy đủ không? Và chính xác thì điều này cần được bổ sung ở đâu? Tất cả các bindRedirects khác của tôi đều được bao bọc trong thẻdependentAssembly
Flo

1
Điều này làm việc tuyệt vời. Tôi muốn nói thêm, nếu bạn có nhiều dự án trong giải pháp của mình, hãy đảm bảo bạn đánh giá tất cả chúng và giải quyết bằng phương pháp này.
Scooter

1
Cảm ơn bạn. Đã bị mắc kẹt về vấn đề này từ 2 ngày nay. Nó đã làm việc !!!
Sagar Khatri

17

Một bổ sung cho câu trả lời mà @AndreiU đã đưa ra và cách tạo cục bộ các lỗi thời gian chạy.

Tôi gặp lỗi thời gian chạy bên dưới khi triển khai tới Azure, không phải cục bộ.

Không thể tải tệp hoặc lắp ráp 'System.Net.Http, Phiên bản = 4.2.0.0, Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a' hoặc một trong các phụ thuộc của nó. Hệ thống không thể tìm thấy tệp được chỉ định. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" tại Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n tại Company.Project .BackOffice.Web.Controllers.OrderController..ctor () trong C: \ project \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: dòng 30 \ r \ n tại lambda_method ( Đóng cửa) \ r \ n tại System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (yêu cầu HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a 'hoặc một trong các phụ thuộc của nó. Hệ thống không thể tìm thấy tệp được chỉ định. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" tại Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n tại Company.Project .BackOffice.Web.Controllers.OrderController..ctor () trong C: \ project \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: dòng 30 \ r \ n tại lambda_method ( Đóng cửa) \ r \ n tại System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (yêu cầu HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a 'hoặc một trong các phụ thuộc của nó. Hệ thống không thể tìm thấy tệp được chỉ định. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" tại Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n tại Company.Project .BackOffice.Web.Controllers.OrderController..ctor () trong C: \ project \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: dòng 30 \ r \ n tại lambda_method ( Đóng cửa) \ r \ n tại System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (yêu cầu HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}}

Khi tôi bắt đầu xem xét các tập hợp, tôi có thể thấy rằng dự án web và dự án dịch vụ của tôi đã nhắm mục tiêu các phiên bản khác nhau cho System.Net.Http.

Dự án web:

nhập mô tả hình ảnh ở đây

Dự án dịch vụ:

nhập mô tả hình ảnh ở đây

Thật dễ dàng để nghĩ rằng điều này là do sự không phù hợp trong các phiên bản, nhưng mấu chốt ở đây là xem lỗi The system cannot find the file specified..

Nhìn vào thuộc tính đường dẫn, chúng ta có thể thấy rằng dự án web nhắm mục tiêu một lắp ráp .Net Framework trong khi dịch vụ nhắm mục tiêu một hợp ngữ từ Visual Studio 2017. Vì máy chủ không được cài đặt Visual Studio 2017, lỗi thời gian chạy sẽ xảy ra.

Đường dẫn web:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

Đường dẫn dịch vụ:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

Một cái gì đó đơn giản như việc thiết Copy Localđể truecó thể khắc phục vấn đề này, tuy nhiên không phải trong mọi trường hợp.

nhập mô tả hình ảnh ở đây

Để tạo lại lỗi trên máy cục bộ của bạn, chỉ cần xóa System.Net.Http.dll khỏi thư mục cụ thể Visual Studio. Điều này sẽ cung cấp cho bạn lỗi thời gian chạy và có thể là một số lỗi xây dựng. Sau khi những thứ này được khắc phục, mọi thứ sẽ hoạt động, ít nhất nó đã làm cho tôi.

Nếu bạn đã cài đặt System.Net.Httpthông qua, NuGethãy kiểm tra lắp ráp nào được sử dụng bằng cách xem .csprojphiên bản. System.Net.Http 4.3.4cho ví dụ như lắp ráp sau:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Nếu bạn sử dụng một máy chủ xây dựng như Jenkins, TeamCity hoặc AppVeyor, thời gian chạy bị thiếu cũng .dllcó thể tồn tại ở đó. Trong trường hợp này, việc sử dụng phiên bản NuGet của System.Net.Http hoặc xóa .dllcục bộ bị thiếu có thể không hữu ích . Để giải quyết lỗi này, hãy xem phiên bản không tìm thấy và phiên bản cụ thể PublicKeyToken. Sau đó, tạo một chuyển hướng ràng buộc trong một trong hai Web.confighoặc App.configtùy thuộc vào dự án của bạn. Trong trường hợp của tôi, tôi muốn sử dụng 4.0.0.0 thay thế:

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

Một chủ đề Github hay về vấn đề này:

https://github.com/dotnet/corefx/issues/22781


4
thêm <dependentAssembly> <assemblyIdentity name = "System.Net.Http" ....... hoạt động theo hình thức tôi. cảm ơn
Romeo

Đối với tôi cũng vậy! Cảm ơn bạn cho một giải pháp! oldversion = "0.0.0.0-4.2.0.0" newVersion = "4.1.1.3" kể từ khi tôi đang sử dụng 4.1.1.3
Pavel Yermalovich

Việc chuyển hướng đến 4.0.0.0 là điều khiến tôi vượt lên hàng đầu. Cảm ơn!
Jim G.

Rất nguy hiểm nếu chuyển hướng xuống! Bạn có một sự phụ thuộc vào dự án của mình báo hiệu nó sử dụng 4.2 nhưng bạn buộc nó phải sử dụng 4.0. Nếu nó đang sử dụng bất kỳ thuộc tính hoặc phương pháp mới nào được giới thiệu trong bài 4.0, bạn sẽ gặp lỗi thời gian chạy với thời gian khó dự đoán.
David Burg

Liên kết đến chuỗi github đã chết. Nhưng chủ đề sau dường như chứa cuộc thảo luận có liên quan: github.com/dotnet/runtime/issues/24382
Hermann.Gruber

4

Những gì tôi đã làm để khắc phục sự cố đã được xóa tất cả các ràng buộc khỏi web.config và thực hiện một

Update-Package -reinstall

Điều này đã loại bỏ một loạt các ràng buộc cũ mà có lẽ không cần phải có ở đó và thực sự đã làm sạch tốt.


4

Tôi vừa cài đặt System.Net.Httpbằng NuGet. Bạn có thể lấy nó ở đây:

https://www.nuget.org/packages/System.Net.Http/

Các ASP.NET MVCdự án tôi đang làm việc trên các mục tiêu .NET 4.6.1. Nó hoạt động hoàn hảo trên máy của tôi trong khi gỡ lỗi IIS Expressbằng Visual Studio 2019.

Sự cố đã xảy ra khi cố gắng chạy ứng dụng được triển khai cho Azure. Tôi đã gặp lỗi này:

Không thể tải tệp hoặc lắp ráp 'System.Net.Http, Phiên bản = 4.2.0.0, Văn hóa = trung lập, PublicKeyToken = b03f5f7f11d50a3a' hoặc một trong các phụ thuộc của nó.

Điều thực sự hiệu quả trong trường hợp của tôi là mở tệp .csproj và tìm kiếm System.Net.Httpnhư trong ảnh chụp màn hình sau ...

nhập mô tả hình ảnh ở đây

Thấy rằng .csprojtệp có phiên bản 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

Thực <HintPath>sự trỏ đến ..\packagesthư mục từ Nuget, tức là đây là phiên bản thực được Nuget cài đặt. Sau khi triển khai, phiên bản cụ thể này cũng sẽ được khôi phục ở phía máy chủ và mọi thứ sẽ hoạt động với chuyển hướng ràng buộc.

... và do đó chuyển hướng ràng buộc nên đề cập đến phiên bản cụ thể Web.confignày như sau:

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

Điều này đã khắc phục sự cố trong trường hợp của tôi sau một vài cam kết với Azure Kudu . Trang web Azure cuối cùng đã bắt đầu mà không có lỗi.


2

Tôi gặp lỗi này khi triển khai dịch vụ web tới một trong các máy chủ của chúng tôi. Dự án nhắm mục tiêu .Net framework 4.7.2, chưa được cài đặt trên máy chủ. Việc cài đặt khung 4.7.2 trên máy chủ đã khắc phục sự cố.


Đây cũng là vấn đề của tôi. Nó cũng là một chủ đề lặp lại cho các phiên bản khác.
Jason Geiger

2

Câu trả lời của Andrei U dẫn đến sự cứu rỗi của tôi. Tuy nhiên, lý do không phù hợp với trường hợp của tôi. Đối với những người ở trong cùng một trường hợp như tôi:

Đó là lỗi thời gian chạy (không phải thời gian xây dựng), trong đó quá trình xây dựng thành công, nhưng sẽ hoạt động trên một máy tính chứ không phải máy chủ. Giải pháp: - Đã thêm gói System.Net.Http. - Đổi tên tệp: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (ví dụ: đổi tên thành: System.Net.Http.dll.BAK) trên xây dựng máy chủ.

Tôi không có và vẫn không có chuyển hướng lắp ráp cho dll này


1

Một giải pháp đơn giản mà tôi tìm thấy đó là hạ cấp khung mục tiêu cho dự án web xuống 4,6.

Tôi tạo ứng dụng khách và ứng dụng web, ứng dụng khách có .net framework 4.7.1 và web có cùng một vấn đề và tôi đang gặp phải vấn đề tương tự, khi tôi hạ cấp khung .net mục tiêu cho web thì nó phù hợp với tôi.


1

Sau khi vật lộn với điều này trong vài ngày, cuối cùng tôi đã khắc phục được sự cố .Net 4.7.2 / System.Net.Http cho dự án của mình. Ngoài việc thay đổi tệp * .csproj để nhắm mục tiêu phiên bản khung 4.7.2, tôi cũng phải cập nhật app.config trong các dự án từ

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

đến:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

0

Tôi đã từng gặp vấn đề tương tự. Cuối cùng, tôi đã giải quyết nó bằng cách thay đổi Deploy-FabricApplication.ps1 thành một cái gì đó như thế này

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

Tôi đã tìm thấy System.Net.Http.dll 4.2.0.0 là x64. Trước khi triển khai tập lệnh này, hãy sao chép dll vào thư mục gói và thay đổi tệp cấu hình để sử dụng tệp này một cách rõ ràng. Tôi cũng đã viết một blog về sự cố System.Net.Http của mình tại http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

Đừng quên thay thế [ProjectName] bằng tên dự án của riêng bạn

Hy vọng điều này sẽ hữu ích, vui lòng hỏi


0

Đối với tôi là một cái gì đó thực sự kỳ lạ. Cần hàng giờ gỡ lỗi sau khi tìm thấy vấn đề là gì. Nó không xảy ra cục bộ mà chỉ xảy ra khi sử dụng jenkins để xây dựng dự án.

Tôi có một thư viện nhỏ sử dụng dotnet standart 2.0 và dự án chính là dự án WCF dựa trên .NET bình thường (của tôi cụ thể là v4.6.1). Nhưng trong lớp khởi động của thư viện dotnet standart, tôi có một số mã trông như thế này:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

Giao diện IStaticDataConfiguration trông như sau:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

Giao diện này nằm bên trong thư viện dotnet standart trong khi việc triển khai ở bên ngoài nó (nằm trong dự án WCF).

Từ bên ngoài thư viện, tôi đã gọi AddStaticDataConfigurationphương thức như sau:

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

Vấn đề là tôi đang chuyển một Func<HttpClient>từ một dự án .NET bình thường sang một thư viện dotnet standart mà vì một số lý do điên rồ mà dotnet standart không thích và có thể nó nghĩ HttpClientlà đến từ các lớp khác nhau, do đó System.Net.Http 4.x.x.xkhông tìm thấy ngoại lệ. Khi loại bỏ mã để không chấp nhận một HttpClientdự án .NET bình thường nhưng tạo một functhư viện mới bên trong bản thân nó hoạt động tốt và hạnh phúc. Hy vọng điều này có thể giúp ai đó khác vì lỗi này xảy ra vì rất nhiều lý do :)


0

Giải pháp của tôi tương tự như của @ Raquib. Dự án của tôi là 4.7.2 và hoạt động tốt trên PC của tôi. Bất cứ khi nào tôi triển khai đến máy chủ nhà phát triển của chúng tôi, tôi sẽ nhận được vấn đề được đề cập trong câu hỏi. Hóa ra phiên bản .net cao nhất trên máy chủ là 4.6.1. Hạ cấp dự án của tôi xuống 4.6.1 đã khắc phục sự cố. Nâng cấp phiên bản .net của máy chủ không phải là một lựa chọn đối với tôi.


0

Tôi tin rằng một phần của câu trả lời có thể được tìm thấy trong tài liệu của Microsoft .

Khi bạn tạo ứng dụng dành cho máy tính để bàn trong Visual Studio nhắm mục tiêu .NET Framework 4.5.1 hoặc phiên bản mới hơn, ứng dụng sẽ sử dụng chuyển hướng liên kết tự động.

Như câu trả lời của @Vivek Sharma đã chỉ ra, loại bỏ:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

đã giải quyết vấn đề trong 3 trường hợp như vậy trong ứng dụng của tôi. Khi bạn kiểm tra DLL với Powershell, ví dụ:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

Kết quả đầu ra

System.Net.Sockets, Phiên bản = 4.0.0.0

Rõ ràng là chuyển hướng ràng buộc tới 4.2.0.0sẽ không hoạt động vì chúng tôi đang xuất 4.0.0.0vào thùng.

Bạn cũng nên kiểm tra GAC ​​để xem liệu cụm từ đó có bị thiếu không:

 gacutil -l System.Net.Sockets

Trong trường hợp của tôi, phiên bản cụ thể cũng bị thiếu trong GAC. Nếu DLL nằm trong GAC thì nó phải được tìm thấy trong quá trình liên kết lắp ráp .


-2

Trước tiên hãy xóa khỏi hệ thống tệp cục bộ của bạn:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\Syste.Net.Http.dll

Sau đó, loại bỏ tất cả các tham chiếu trong Projects và thêm tham chiếu 4.0.
Điều này đã giải quyết vấn đề của tôi cho tôi.


3
ôi không, vui lòng không làm hỏng cài đặt VS của bạn bằng cách xóa một số tệp của nó.
David Burg
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.