Method not found

Looks like its similar to this issue: https://github.com/serilog/serilog-sinks-seq/issues/70

We aren’t using Azure like the OP there, but we are are upgrading an old AspNet MVC 6 / Web Api 2 project. Version 1.5 of Seq works but we need to upgrade to 2.0+ (2.5 with 3.4.0 of Serilog.Sinks.Seq).

Method not found: 'Serilog.LoggerConfiguration Serilog.SeqLoggerConfigurationExtensions.Seq(Serilog.Configuration.LoggerSinkConfiguration, System.String, Serilog.Events.LogEventLevel, Int32, System.Nullable`1<System.TimeSpan>, System.String, System.String, System.Nullable`1<Int64>, System.Nullable`1<Int64>, Serilog.Core.LoggingLevelSwitch, System.Net.Http.HttpMessageHandler, System.Nullable`1<Int64>, Boolean, Int32)'.

[MissingMethodException: Method not found: 'Serilog.LoggerConfiguration Serilog.SeqLoggerConfigurationExtensions.Seq(Serilog.Configuration.LoggerSinkConfiguration, System.String, Serilog.Events.LogEventLevel, Int32, System.Nullable`1<System.TimeSpan>, System.String, System.String, System.Nullable`1<Int64>, System.Nullable`1<Int64>, Serilog.Core.LoggingLevelSwitch, System.Net.Http.HttpMessageHandler, System.Nullable`1<Int64>, Boolean, Int32)'.]
   ProjectName.WebApiApplication.Application_Start() in C:\Project\Project.Web\Global.asax.cs:34

[HttpException (0x80004005): Method not found: 'Serilog.LoggerConfiguration Serilog.SeqLoggerConfigurationExtensions.Seq(Serilog.Configuration.LoggerSinkConfiguration, System.String, Serilog.Events.LogEventLevel, Int32, System.Nullable`1<System.TimeSpan>, System.String, System.String, System.Nullable`1<Int64>, System.Nullable`1<Int64>, Serilog.Core.LoggingLevelSwitch, System.Net.Http.HttpMessageHandler, System.Nullable`1<Int64>, Boolean, Int32)'.]
   System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) [phone]
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +118
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +173
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +336
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +296

[HttpException (0x80004005): Method not found: 'Serilog.LoggerConfiguration Serilog.SeqLoggerConfigurationExtensions.Seq(Serilog.Configuration.LoggerSinkConfiguration, System.String, Serilog.Events.LogEventLevel, Int32, System.Nullable`1<System.TimeSpan>, System.String, System.String, System.Nullable`1<Int64>, System.Nullable`1<Int64>, Serilog.Core.LoggingLevelSwitch, System.Net.Http.HttpMessageHandler, System.Nullable`1<Int64>, Boolean, Int32)'.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) [phone]
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +95
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +254

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.2556.0

Fails in our Global.asax if we leave our Write.To.Seq(blah) in place. Removing it allows the application to launch properly, but obviously can’t log to seq anymore 😦

So far the only way to get it to work is to downgrade to v 1.5 of Seq, which doesn’t work with some other logging we are trying to add.

[rolfik]

Well, this is ugly error. We had it as well, but in a little different scenario: One shared library initializing Serilog logging to Seq called in two applications. One application was working well, another was failing. The difference was a .csproj setting regarding assembly redirects - the correct one which puts correct redirects into .config is AutoGenerateBindingRedirects = true:

[nblumhardt]

Terrific 👍

Assembly version matching is precise/strict on the .NET CLR, so unless all binaries are built against the exact same version of a dependency, redirects are necessary.

In this case, since Serilog.Sinks.Seq was built against a different System.Net.Http version to your app, the HttpMessageHandler argument to WriteTo.Seq() isn’t considered to be the exact same type as the HttpMessageHandler type already loaded into the appdomain.

One of the big improvements in .NET Core is a looser policy around these things, I think.