Could not load file or assembly System.Net.Http, Version=4.0.0.0

We have a ASP.NET WebForms application, written in VB.NET.

We have now bumped the .NET Framework from v4.6.1 to v4.8

All NuGet’s were updated to latest version, so we are now using Sentry v3.11.1 (previously we were using v2.1.6)

We also removed Sentry.PlatformAbstractions and Sentry.Protocol, as these are now deprecated.

Now, as soon as SentrySdk.Init is called, the following exception is thrown.

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.

at Sentry.Internal.SdkComposer.CreateTransport() in //src/Sentry/Internal/SdkComposer.cs:line 86
at Sentry.Internal.SdkComposer.CreateBackgroundWorker() in /
/src/Sentry/Internal/SdkComposer.cs:line 99
at Sentry.SentryClient…ctor(SentryOptions options, IBackgroundWorker worker) in //src/Sentry/SentryClient.cs:line 52
at Sentry.Internal.Hub…ctor(SentryOptions options, ISentryClient client, ISessionManager sessionManager, ISystemClock clock, IInternalScopeManager scopeManager) in /
/src/Sentry/Internal/Hub.cs:line 51
at Sentry.SentrySdk.InitHub(SentryOptions options) in //src/Sentry/SentrySdk.cs:line 53
at Sentry.SentrySdk.Init(SentryOptions options) in /
/src/Sentry/SentrySdk.cs:line 97

The version of System.Net.Http in use now is 4.2.0.0, so I guess that is where the issue lies, but this is what the version of this was prior to the update, where no exceptions were thrown.

Hello BigGazMetro,

Have you checked this page? Migration Guide for .NET | Sentry Documentation? There were some breaking changes on version 3.X.X that are worth checking since you were using a version prior to it.

Since you’re using ASP.NET, you’ll need an additional package named Sentry.AspNet , the new initialization process is demonstrated here: Migration Guide for .NET | Sentry Documentation

Let me know if the problem persists after the migration.

Thank you for the reply and links regarding migration

I did not have the Sentry.AspNet package installed, so have added that now, and included it in the options with options.AddAspNet()

After reviewing I noticed that the following had been added to my app.config and web.config files

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

The projects had the same version of System.Net.Http before, but the above was not in the *.config files.

I have removed these entries as a test and the exception is no longer thrown, but no events are getting to Sentry.

An update on progress.

With no success on the legacy application, I decided to do some more isolated testing.

Created a new VB dot NET console app, using .NET 4.8, using exact same code, this successfully captured my exception in Sentry, so the code looks like it works in isolation.

I then created a new VB dot NET ASP dot NET web application, using .NET 4.8, using exact same code, to mirror the legacy app as best I could, this also successfully captured my exception in Sentry, so again the code looks like it works in isolation.

So there is clearly something about the legacy application that is interfering somewhere, but not enough to give me any errors or exceptions.

The Legacy App, when SentrySdk.CaptureException(ex) is called, this returns a SentryId of all zeros.

This can mean:

  • The SDK was not initialized
  • There are already 30 events queued up to be submitted to Sentry (back pressure)
  • The event was dropped by a BeforeSend callback or EventProcessor you specified in the options
  • The event was dropped by the deduplication logic

You can turn debug mode on and see what’s going on in the SDK: Basic Options for .NET | Sentry Documentation

On IIS based projects I believe logs should be in Visual Studio already, but you can change where they go through: Diagnostic Logger for .NET | Sentry Documentation

Thank you for the links regarding debugging the SDK, this has given me more information about what is going on.

I noted this error, so hunted down any references to this file.

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

It appears in the various app.config and web.config files, I have commented it out for more testing, when doing so, everything is now working as expected, errors now getting to sentry.

<dependentAssembly>
	<assemblyIdentity name="System.Runtime.InteropServices.RuntimeInformation" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
	<bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
</dependentAssembly>

Visual Studio itself is what updates these *.config files, I do not normally manually edit these files, except for any specific config needed, so I guess I will have to read up why these entries exist and which are safe to remove, although could they be automatically added back in by Visual Studio in the future?

After a little research, I elected to remove all of these setting from app.config and web.config files in my solution.

I then ran the following command from the Package Manager Console

PM> Get-Project –All | Add-BindingRedirect

This recreates all the assembly redirects that are needed in the web.config or app.config file for the solution and updates them to match the versions from the various packages that are installed in each project.

I now have a working app that communicates with Sentry, not throwing an (almost silent) errors.

1 Like