MissingMethodException on .NET Core 3

[dominikjeske]

I'm using UseSerilog overload that is using WebHostBuilderContext as action parameter. MS has changed WebHostBuilderContext implementation in 3.0 so HostingEnvironment is no longer of type IHostingEnvironment - now it is IWebHostEnvironment. Are there any plans to properly target .NET Core 3.0?

[skomis-mm]

Hi, @bigdnf . The latest major version of the package (3.x) targets 2.0 of Microsoft.AspNetCore.Hosting.Abstractions that contains new type. Can you check if it works with 3.x?

[dominikjeske]

I'm not sure I'm understand right so I will clarify. I'm using 3.2 version of serilog-aspnetcore which is .net standard 2.0 that is referencing Microsoft.AspNetCore.Hosting.Abstractions 2.0. Those abstractions nuget is obsolete in .NET Core 3.0 (dotnet/core#2194) and because of this when used in new core release WebHostBuilderContext have different content in property HostingEnvironment – it used to be IHostingEnvironment and now it is IWebHostEnvironment (https://andrewlock.net/ihostingenvironment-vs-ihost-environment-obsolete-types-in-net-core-3/). So in summary everything is compiling but is failing in runtime. For me library should multi target .net core 3.0 and net standard.
I can propose pull request if you want.

[nblumhardt]

@bigdnf thanks for the note! If a project builds, there should never be runtime MissingMethodExceptions, but sometimes the package reference structure in the CSPROJ file can lead to the wrong versions of dependent assemblies being deployed. It's a bit of a mess, sometimes :-)

If you're keen to submit a PR, the likely target is https://github.com/serilog/serilog-extensions-hosting - an explanatory code/CSPROJ sample would be needed, though.

Also, if you're on 3.0, it's likely that you should be calling UseSerilog() on the IHostBuilder rather than down in the web host configuration - we've followed along with the generic host changes, and that's now the place to configure Serilog.

Hope this all helps!

[skomis-mm]

@bigdnf you are right, thanks for pointing to the article, makes sense 👍
Behavior depends on where the access to the HostingEnvironment property is compiled. If its compiled in the end asp.net core project (netcoreapp3.x) then latest (v3) WebHostBuilderContext type will be used and no exceptions.
If you use UseSerilog(..) in external class library targeting netstandard 2.0, for example, access to HostingEnvironment will be bind to v2 of type (IHostingEnvironment) so the runtime exception occurs on netcoreapp3.x runtime...

PR probably will solve this. As workaround you can multitarget your shared configuration class library like article suggests:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;netcoreapp3.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition="$(TargetFramework) == 'netcoreapp3.0'">
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

So that for netcorapp3.0 runtime it will bind to a new type.

But better is to move the configuration out of the WebHostBuilder to IHostBuilder as @nblumhardt suggests if you can afford it (e.g you don't need web specific ContentRootPath prop etc for your config). It will be better for the long term and your shared project can only target netstandard2.0.