Method not found
Closed this issue · 8 comments
Looks like its similar to this issue: #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) +10061317
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) +10042604
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.
Hi John, thanks for getting in touch.
I would guess that you're using the "classic" CSPROJ project system; are you referencing System.Net.Http directly as a reference assembly, or do you have one of either Microsoft.Net.Http or the System.Net.Http NuGet package installed? IIRC you'll need to reference the version of the DLL from the framework, not via the NuGet package.
It would also be worth cleaning the solution, removing the old NuGet package from under /packages, and making sure that the latest version of the sink assembly is the one being copied into the output directory.
Does this spark some ideas? Cheers! :-)
@nblumhardt hello!
Yes we are using the "classic" csproj, we are referencing it through nuget. It does show in references but does have a yellow warning icon, but does properly place it into the bin directory when built. I've tried deleting the bin and packages directories
System.Net.Http file shows as version 4.6.25514.4 (4.3.3)
Serilog.Sinks.Seq shows as 3.4.0.0
Any ideas or things to test?
Thanks!
Thanks for the follow-up @mackayj!
Two things I can think of - first, if you remove your NuGet reference to System.Net.Http is everything happy?
Second, does your CSPROJ have binding redirects for System.Net.Http, from 0.0.0.0 -> 4.3.3.0? This is my best hope :-)
Past that, I think it's fuslogvw.exe - instructions for kicking it off are here: https://stackoverflow.com/questions/255669/how-to-enable-assembly-bind-failure-logging-fusion-in-net
Fingers crossed!
@nblumhardt I can't remove the System.Net.Http as another package we use is dependent on it. I don't have a binding redirect in the web.config for System.Net.Http either :(
@mackayj that's great :-) .. you may need the binding redirect, so with some luck this will be the issue!
Try:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.3.0" newVersion="4.3.3.0" />
</dependentAssembly>
</assemblyBinding>I had to use
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.3.0" newVersion="4.2.0.0" />
</dependentAssembly>
But yes that did fix the issue, thank you! Do you know why it wasn't working without the redirect?
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.
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:
