Update System.Net.Http to 4.3.2 breaks serilog-sinks-seq

[stokara]

Fuslog shows app looks for http 4.3.1 and crashes

[nblumhardt]

Hi @stokara - which runtime are you testing this on? If .NET Framework, has the package install process created an assembly binding redirect in your app.config/web.config file? Cheers!

[skovsende]

I have a similar problem. Updated my project from .net 4.5 to 4.6, which meant System.Net.Http got pulled in, Now it has problems loading the dll. My situation may be special because I am running as a Visual Studio Extension, so I can't set up bindingRedirect.

[janpieterz]

Encountered the same, running .NET framework NServiceBus Hosts. Made sure all assembly bindings that existed were correct, didn't matter.

Then downgraded back to 4.1.1 to at least for now push some changes out easily, and encountered #70

Then looked at why certain endpoints did work and others not, and for some reason one endpoint did not get an app.config redirect for System.Net.Http (was in the NServiceBus.Host.Exe) but did have a redirect for Serilog. Removed Serilog redirect and added the System.Net.Http and it worked.

[nblumhardt]

Thanks for the feedback, @janpieterz .

@skovsende I had a bit of a Google around, and via Stack Overflow found: https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.providebindingredirectionattribute.aspx?f=255&MSPPError=-2147217396 - looks like you can do binding redirects in extensions by way of an attribute. Any luck with this?

[skovsende]

Brilliant! Just had a similar problem, and it seems like your solution worked. I shall try to fix my original problem the same way and see if it works.

[kinetiq]

Just a note that this one has been driving me crazy for a long time. :) I think I am going to disable this sink, unfortunately, until a solution is posted.

[nblumhardt]

Hi @kinetiq, thanks for weighing in :-)

Just to make sure I understand the issue correctly - are you working on an app that can't do binding redirects? Unfortunately the versioning of System.Net.Http seems to have gone awry at some point, I don't know whether there's any one version we can target that won't cause problems in some way, so going with the most recent version has seemed to be (potentially) the least painful..... :-S

Let me know which .NET Framework version you're using and I'll dig in! :-) Thanks!

[kinetiq]

@nblumhardt Thanks for the response. Here are the details:

This is a relatively simple ASP.NET 4.6.1 application that I have just moved over to VS2017... I honestly do not understand what's going wrong here - I think it has more to do with System.Net.Http than with Serilog.

Let me put it this way: I have the System.Net.Http package in the project and working at version 4.0.0.0 ... If I try to bump that up even to 4.1.0 (which would let me use an earlier v3 rev of this project), nuget pulls down additional packages for Microsoft.Win32.Primitives and some Crypto dependencies. These, for reasons that currently elude me, don't seem to work. Actually, the project runs, but I have warnings for each of them: the referenced component 'Microsoft.Win32.Primitives' could not be found. I have tried everything I can think of... Update-Package -Reinstall, referencing the libraries manually, etc etc.

(this must be related to #83 although I don't grasp exactly what's going on here yet)

[flookami]

Nice article here https://stackify.com/net-core-dll-hell/ about dll hell brought by older versions of .NET standard :)

[kinetiq]

Thanks @flookami - and this is possible even if you are actually running .NET 4.6.1 (not core/standard)?

[nblumhardt]

Hi all, thanks for the continued help.

There's a new package 3.4.0-dev-00134 now on NuGet. This should resolve these issues, but, for it to do so you must make sure that .NET Framework apps reference the built-in System.Net.Http, and .NET Core apps reference the package. There's an example of this in: https://github.com/serilog/serilog-sinks-seq/blob/dev/sample/Sample/Sample.csproj.

I can't deny that the situation here distresses me a bit - I've been through the ins-and-outs of .NET library packaging for many years and I'm still not 100% confident the package will work with all current scenarios and project types. I'll need some help verifying this as widely as possible before shipping 3.4 final.

For a start, would it be possible to try the new package @kinetiq @flookami @skovsende @janpieterz @stokara and let me know that it installs cleanly, and runs successfully, in all of your varied project configurations?

[janpieterz]

Just kicked off a couple of builds and deployments, looks good for these:
✔️ ASP.NET Core running netcoreapp1.1
✔️ ASP.NET Core running net462
✔️ ASP.NET Core running netcoreapp2.0
✔️ Desktop Service running .net 4.7 (NServiceBus service)

[kinetiq]

Confirmed that this works for .Net Framework 4.6.1 (ASP.NET MVC scenario)!

I tried this both by manually adding the reference to System.Net.Http, and also using the package, but forcing it to use version 4.0.0.0 ... Both worked. In the latter case, I believe the package actually redirects to the Framework Assembly Reference, so it's the same thing.

There is some deep strangeness going on with System.Net.Http right now, still getting the "The referenced component 'System.Net.Http' could not be found." warning as described https://github.com/dotnet/corefx/issues/22781 and many other places. I've read this a few times and I still don't completely have my head around it.

Thanks for working this out. For what it's worth, this is just in time to help me debug some things that absolutely require logging. :)

[kinetiq]

I found this concise write-up on the issue... Anyone following along may want to read up, but be warned, the versioning situation has become, errr, somewhat abstract: dotnet/standard#481

Under Workarounds, it contains some very specific guidance for various project types.

[flookami]

@nblumhardt I confirm it works like a charm now on a solution targeting NET47 full framework (with ASP.NET webforms, web API 2, libraries and windows services)
The build is now using the framework assembly of System.Net.Http instead of the nuget package

[nblumhardt]

@janpieterz @kinetiq @flookami thanks for checking it out! Great to hear we're on the right track, finally.

I'll aim to get the release out soon.

[tsimbalar]

Confirm that 3.4.0 does fix System.Net.Http reference madness in our projects .
Thanks ! 👍

[nblumhardt]

Awesome, thanks @tsimbalar

[stokara]

Was fixed but has returned when used with Windows Application Packaging project to package my WPF app for UWP bridge

[nblumhardt]

Thanks for the update @stokara - would it be possible to open a new ticket and paste in your CSPROJ file contents? Especially the referenced packages/assemblies. Thanks!