Strange issue with System.Net.Http 4.2.0.0 not found

[oliverbes]

I have a strange issue, which drives me crazy…

I have a simple Class Library Project (Full .NET Framework, 4.6.1) with a wrapper class for functionality around Cosmos DB. Therefore I have added the “Microsoft.Azure.DocumentDB” NuGet Package 1.19.1 to this project. Other than that, I have a reference to the “Newtonsoft.Json” NuGet Package 10.0.3, as well as to a couple of "Microsoft.Diagnostics.EventFlow.*" NuGet Packages.
So far, everything compiles without any error.

But as soon as I hit my wrapper class – consumed from a simple Service Fabric Stateless Service (Full .NET Framework 4.6.1) – and try to execute the following line of code:
_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);
I get this strange error at runtime:

System.IO.FileNotFoundException occurred HResult=0x80070002
Message=Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
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, Nullable1 desiredConsistencyLevel)
Inner Exception 1: FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

I have absolutely no clue, why the System.Net.Http assembly is not found at all – there is no direct assembly reference in my class library project to the .Net Framework Assembly “System.Net.Http”.
What I also do not understand is, that there is this weird binding redirect to 4.2.0.0 – where is that one coming from? To get around this one, I tried to add the following redirect to the app.config of the Service Fabric Service (which is consuming the class library).

In a Service Fabric Service without any of the EventFlow NuGet Packages I have no runtime error at all, everything works as expected. From that, my assumption is about the .NETStandard references being pulled in through the EventFlow Packages. So somehow the mixture of .NET 4.6.1 full Framework and .NETStandard causes this issue.

Any clue?

Thanks and regards,
OliverB

[oliverbes]

Probably mine is kind of similar to issue #154 - but still I'm looking for a solution...

[karolz-ms]

So @oliverbes were you able to get to the bottom of this?

Looks like Sven just started using the new C# project system format and that fixed things for him.

[oliverbes]

Sorry, was busy with other stuff. Hope to continue on this soon.

[alexszym]

Experiencing a similar issue. I've got a project using 4.6.1 and ASP.Net Core 1.1. Everything seems to work fine when I deploy to the local cluster or deploy to Azure via Visual Studio, but when I deploy to Azure with the scripts I get a ReflectionTypeLoadException.

Replica had multiple failures during open on _backnodes_2. API call: IStatelessServiceInstance.Open(); Error = System.Reflection.ReflectionTypeLoadException (-2146232830)
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.RuntimeAssembly.get_DefinedTypes()
   at System.Linq.Enumerable.d__16`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at AutoMapper.ServiceCollectionExtensions.AddAutoMapperClasses(IServiceCollection services, Action`1 additionalInitAction, IEnumerable`1 assembliesToScan)
   at Zonal.BusinessStructure.Gateway.ServiceCollectionExtensions.ConfigureControllerDependencies(IServiceCollection serviceCollection, IConfiguration configuration)
   at Zonal.BusinessStructure.Gateway.Startup.ConfigureServices(IServiceCollection services)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.ConfigureServices(IServiceCollection services)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at Microsoft.ServiceFabric.Services.Communication.AspNetCore.AspNetCoreCommunicationListener.OpenAsync(CancellationToken cancellationToken)
   at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.d__13.MoveNext()
For more information see: http://aka.ms/sfhealth

When I dig into Loader exceptions I get the following:
Could not load file or assembly 'System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The issue does seem to be tied to eventflow, I don't think anything else has the System.Net.Http dependency and this is the only new dependency I've added. That and I had to upgrade the application from 4.5.2 to 4.6.1 to support eventflow.

[karolz-ms]

@alexszym verify that your cluster actually has 4.6.1 installed

After that it is most likely that what you are seeing is related to dotnet issue 481 so please apply all the workarounds mentioned in that issue and let us know if that helped!

[karolz-ms]

Closing this one for now, but please reopen as necessary

[houseofcat]

Not a reopen request but the issue can still happen but I have a work around.

Upgraded project to 4.7.2. Went through all the bells and whistles necessary.

Go to run finally and get the File not found exception looking for a 4.2.0.0 version of System.Net.Http...

Turns out Visual Studio 2017, when installing the .NET 4.3.3 Nuget package for System.Net.HTTP is also adding DLL reference (old school) from the GAC. This in tandem with an Assembly redirect causes run time System.IO.FileNotFoundException looking for version 4.2.0.0 of System.Net.Http.

The good news, is to add references, uncheck System.Net.Http from the GAC (which was added automatically or by other developers in the project at one point in time), and simply delete the Assembly redirect.

Issue was gone after that.

[karolz-ms]

Thanks for sharing @thyams, appreciate your help.

[melwil]

@thyams Could you elaborate a bit on what you did? I have the same issue now, but I can't follow the steps you did to fix this issue.

What do you mean by uncheck System.Net.Http from the GAC (which was added automatically or by other developers in the project at one point in time)? Is there a place I can specifically tell it not to copy from the GAC? Or do you just mean Add reference -> assemblies -> uncheck System.Net.Http? I tried that for my project, and I am unable to remove it from references, as I'm using a lot of features from it.

Also, what do you mean by and simply delete the Assembly redirect.? Do I remove some hint path from a file, or something like that?

[karolz-ms]

@melwil I will let @thyams provide the definitive reply but typically

• assembly references come from the project (.csproj) file
• binding redirects come from the app.config or web.config file https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/bindingredirect-element

So I would look into these two kinds of files with a text editor (notepad or similar) and look for suspicious entries for System.Net.Http (wrong version and/or referring to GAC as opposed to standard Nuget feed).

Hope this helps!