search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.63k stars 4.57k forks source link

System.IO.FileLoadException in System.Net.Http 4.1.1 (NuGet package 4.3.0) on System.Diagnostics.DiagnosticSource 4.0.1 (NuGet package 4.3.0) #19866

Closed baal2000 closed 4 years ago

baal2000 commented 7 years ago

System.IO.FileLoadException at System.Net.Http.WinHttpHandler.SendAsync(): Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Our research has shown that:

This ticket can also be answered at http://stackoverflow.com/questions/41550563

Thanks!

karelz commented 7 years ago

cc @ericstj who had some insights.

We believe it will be fixed as a side-effect of fix for dotnet/runtime#18280. I would still like to understand the root cause here (it's not clear to me from the bug description).

baal2000 commented 7 years ago

cc @karelz: More details at http://stackoverflow.com/questions/41550563.

Maybe this sequence is clearer:

  1. System.Net.Http.dll 4.1.1 has been built while referencing System.Diagnostics.DiagnosticSource.dll v 4.0.0
  2. Nevertheless, System.Diagnostics.DiagnosticSource.dll v 4.0.1 is auto-deployed with System.Net.Http v 4.3.0 package. This package carries System.Net.Http.dll 4.1.1 with itself, as explained in the issue description.
  3. Invoking certain System.Net.Http classes methods causes FileLoadException because the runtime can not find exact match (strong name, version) to System.Diagnostics.DiagnosticSource.dll referenced from System.Net.Http.

The error can be prevented by manually adding the binding redirect section to app.config or manually adding System.Diagnostics.DiagnosticSource v 4.0.0 package to the project dependencies when NuGet package of System.Net.Http v 4.3.0 is installed.

davidsh commented 7 years ago

@karelz @ericstj Any fix for dotnet/runtime#18280 will not affect this problem unless DiagnosticSource is removed completely from the set of assemblies used for the net46 build of System.Net.Http.dll. Can you explain why you think the problem would be fixed as a side-affect of fixing dotnet/runtime#18280?

karelz commented 7 years ago

I was just quoting @ericstj. These things are mind-blowing (feels like the good old Fusion days with inconsistent versions of participating assemblies on top of that :() - I need to grab @ericstj and understand the problem better.

davidsh commented 7 years ago

After reviewing the binaries and dependencies of System.Net.Http.dll, I see that once the fix for dotnet/runtime#18280 is checked in (with PR dotnet/corefx#15036), the set of dependent assemblies for the NET46 build of System.Net.Http.dll is reduced. See below:

Current System.Net.Http.dll NET46 build in [master] branch.

// Metadata version: v4.0.30319
.module extern crypt32.dll
.module extern kernel32.dll
.module extern winhttp.dll
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System.Diagnostics.DiagnosticSource
{
  .publickeytoken = (CC 7B 13 FF CD 2D DD 51 )                         // .{...-.Q
  .ver 4:0:2:0
}
.assembly extern System.Core
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System.Buffers
{
  .publickeytoken = (CC 7B 13 FF CD 2D DD 51 )                         // .{...-.Q
  .ver 4:0:2:0
}

Pending revised System.Net.Http.dll NET46 build (once PR dotnet/corefx#15036 is checked in):

// Metadata version: v4.0.30319
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System.Core
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}

So, since the hard dependency against System.Diagnostics.DiagnosticSource is removed, the exception "System.IO.FileLoadException" should go away.

baal2000 commented 7 years ago

Agree removing System.Diagnostics.DiagnosticSource dependency should do. Thank you all.

baal2000 commented 7 years ago

@davidsh What about WinHttpHandler package dependencies that new version of System.Net.Http.dll requires to support HTTP/2 protocol per PR 15036?

davidsh commented 7 years ago

System.Net.Http.dll doesn't have a dpendency to System.Net.Http.WinHttpHandler.dll. But it does include the source of WinHttpHandler as the default HttpClientHandler implementation. That, however, is changing with the PR dotnet/corefx#15036.

The PR dotnet/corefx#15036 will end up implicitly removing a dependency where System.Net.Http.dll requires DiagnosticSource.dll because that requirement bubbles up from using WinHttpHandler.

That said, any explicit use of WinHttpHandler (i.e. via the System.Net.Http.WinHttpHandler package) will bring in DiagnosticSource. And perhaps, there will be a problem surfacing regarding version conflict dependencies with DiagosticSource.dll.

I would suggest we wait until PR dotnet/corefx#15036 is done. And then you can try a new repro case where you have explicit code referencing WinHttpHandler. In that case, we might want to close this issue as resolved since it talks about System.Net.Http.dll needing DiagnosticSource.dll. But perhaps then open up a new issue regarding WinHttpHandler.dll dependencies with DiagnosticSource.

baal2000 commented 7 years ago

Sure may close System.Net.Http case then

davidsh commented 7 years ago

Now that PR dotnet/corefx#15036 is checked in, this problem should go away w.r.t. net46. System.Net.Http.dll no longer use WinHttpHandler internally and thus no longer trys to load System.Diagnostics.DiagnosticSource.dll at runtime.

Please try out the latest packages on the MyGet dev feed. You'll want to use the latest built System.Net.Http.dll packages which as of today is: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

version 4.4.0-beta-24913-02.

You can use dev feed packages via changing your NuGet package source fees either with command line tools or Visual Studio.

Instructions:

Command-Line: Add the following in nuget.config, under element:


<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Visual Studio: In VS, Tools->Options->Nuget Package Manager->Package Sources -> Add, under Source, use this url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

In either case, make sure you list the MyGet dev feed as the first feed in the list.

davidsh commented 7 years ago

I'll close this issue for now. If the problem isn't solved w.r.t. System.Net.Http.dll, please re-open this issue.

If there is a different problem, then please open up a new issue. Thanks!

Muhammadbilawal commented 7 years ago

I have a problem error " 'System.IO.FileLoadException' " how can i get rid of this error .... i am new to programing

karelz commented 7 years ago

I would recommend to use StackOverflow.com or similar communities for general programming questions. Doing search on bing/google usually leads to helpful things as well.

GZidar commented 7 years ago

Hi all, I have just installed VS2017 on a brand new computer (nothing but windows 10 - insider build 15048) and tried dotnet ef migrations list and the command crashes with the below message. 

Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The project is a netcoreapp1.1 csproj with all packages referencing version 1.1.1 (except tools as there is no 1.1.1 version) as shown below.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AssemblyName>WebAPI.Database</AssemblyName>
    <PackageId>WebAPI.Database</PackageId>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
  </PropertyGroup>

    <ItemGroup>
      <PackageReference Include="Microsoft.EntityFrameworkCore" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Configuration.FileExtensions" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="1.1.1" />
      <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.1" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.1" />
    </ItemGroup>

    <ItemGroup>
        <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
    </ItemGroup>

    <ItemGroup>
      <ProjectReference Include="..\WebAPI.Shared\WebAPI.Shared.csproj" />
    </ItemGroup>

    <ItemGroup>
      <None Update="appsettings.json">
        <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </None>
    </ItemGroup>
</Project>
karelz commented 7 years ago

@GZidar I would recommend to not post into closed issues - they may not be monitored.

I am not sure which command crashes for you ... can you specify if it is some migration tool or your app? (note that migration tools are not part of CoreFX - so if that's the case, we will be able to direct you to the right repo)

GZidar commented 7 years ago

@karelz Sorry for posting here but I did so under direction (in a previous closed issue EF#7742 - linked above). The command that fails is "dotnet ef migrations list" this is not a problem with my app code as far as I can tell and it has been an issue that has been reproduced by others. Unfortunately the fix which should have been shipped with dotnet core 1.1.1 does not seem to work (for me at least).

I am at something of a loss.

There is a workaround that involves changing the target framework of my project to netcoreapp1.0 then running the command and then changing it back afterwards.

k7hpn commented 7 years ago

I am seeing this as well. They mentioned in aspnet/EntityFramework#7557 using the netcoreapp1.0 workaround and routed us over here.

Stacktrace:

> dotnet ef migrations add initial

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:03.51
System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'System.Diagnostics.DiagnosticSource, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Microsoft.EntityFrameworkCore.Infrastructure.RelationalServiceCollectionExtensions.AddRelational(IServiceCollection services)
   at Microsoft.Extensions.DependencyInjection.SqliteServiceCollectionExtensions.AddEntityFrameworkSqlite(IServiceCollection services)
   at Microsoft.EntityFrameworkCore.Internal.ServiceProviderCache.<>c__DisplayClass4_1.<GetOrAdd>b__2(Int64 k)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Microsoft.EntityFrameworkCore.DbContext.InitializeServices()
   at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()
   at Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions.GetService[TService](IInfrastructure`1 accessor)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(Func`1 factory)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(String contextType)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
karelz commented 7 years ago

I admit I don't know what the "dotnet ef ..." command does. I guess it is the CLI exe, dotnet.exe. @piotrpMSFT @eerhardt can you please help route it?

k7hpn commented 7 years ago

My guess is that the issue might have something to do with the Microsoft.EntityFrameworkCore.Tools.DotNet v1.0.0 CLI tooling package (I believe that's what provides dotnet ef) but I'm not sure. It might actually belong over in EF.

karelz commented 7 years ago

If it is in tooling, I assume it is part of CLI repo - we just need to identify which exe it is and that will give us the repo with its source code, which points at where to file a bug (I assume) ...

k7hpn commented 7 years ago

Maybe aspnet/EntityFramework.Tools?

karelz commented 7 years ago

I honestly have no idea ... @natemcmaster can you help route it?

natemcmaster commented 7 years ago

"dotnet ef" lives in https://github.com/aspnet/EntityFramework.Tools. Use https://github.com/aspnet/EntityFramework for issues

karelz commented 7 years ago

Thanks @natemcmaster! @haraldnagel @GZidar can you please post your bug there? Sorry for the ping-pong between repos. I would normally move the bug into another repo via GitHubMover, but we hijacked different (although similar) closed issue with the discussion report, so it is not appropriate in this case ...

k7hpn commented 7 years ago

I'll do a little more review to make sure I can't get this to work and then I'll post over there. Thanks @karelz et al. for your help!

karelz commented 7 years ago

@haraldnagel I would suggest to not wait and file it there right away. It looks pretty bad from scenario perspective, so either it is known issue, or it should get attention ASAP IMO.

k7hpn commented 7 years ago

This was user error on my part. I was not specifying the startup project with -s as the dotnet ef instructions clearly say to. The bit in the stack trace about Microsoft.Extensions.DependencyInjection tipped me off. Thanks again @karelz for following up on my questions in an already-closed issue, it's greatly appreciated!

karelz commented 7 years ago

@haraldnagel I think it is still worth filing there - I don't like experience of exceptions when you do wrong command line. It should be proper error, explaining and leading people to what to do IMO. Of course, if possible.

GZidar commented 7 years ago

@haraldnagel You are quite correct that specifying the startup project does make the commands work (well spotted), but it is interesting that changing to netcoreapp1.0 also makes it work. Thank you and @karelz for following up despite this being a PEBKAC issue.

manuelmejiaio commented 7 years ago

I just installed System.Diagnostics.DiagnosticSource and System.Collections.Immutable from the NuGet Package Manager, and everything is working :)