Please update Microsoft.Extensions.DependencyModel to the latest version.

[niemyjski]

This might break asp.net core 1.0 but if you are running on 2.0 you have major headaches and runtime errors as well as these warnings if you are using the AspNetCore.All meta package. And you are faced to add <PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.3" /> of version >=2.0.3

warning MSB3277: Found conflicts between different versions of "Microsoft.Extensions.DependencyModel" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

[nblumhardt]

👍 this sounds like a fair change to make, at this point.

Help appreciated if anyone's able to work through it.

[skomis-mm]

I didn't notice any compatibility at runtime and build issues with netcoreapp2.0 (tested Microsoft.AspNetCore.All 2.0.0 - 2.0.5 and sdks 2.0.0-2.1.4). Nuget resolves Microsoft.Extensions.DependencyModel to 2.0.0 since its closer to the app (it is a direct dependency of SDK) than 1.0.0.

[nblumhardt]

Any chance you're using an old dotnet SDK version, @niemyjski ? I've found pretty substantial differences in behaviour from 2.0 up to 2.1.4.

[zagros]

Any update on this?

[nblumhardt]

@zagros any chance you can help pin this issue down to a particular configuration/SDK version/project setup? How are you reproducing? Thanks!

[zagros]

This is happening on .NET Framework 4.6.2 for me the nuget package i'm using is 2.6.0

I enabled verbose logs and I then I saw this error

2>  Unified primary reference "Microsoft.Extensions.DependencyModel, Version=2.0.4.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
2>      Using this version instead of original version "1.0.0.0" in "C:\Work\_the_project\packages\Serilog.Settings.Configuration.2.6.0-dev-00081\lib\net451\Serilog.Settings.Configuration.dll" because AutoUnify is 'true'.

i'm using the serilog in a class libary that I include in my Windows Service Projects, and Web API projects (both parts of the same sln). The Web API project for example is using Microsoft.AspnetCore 2.0.1 at the moment (I upgraded the project from 1.1 to 2.0.1 and this is happening on the first .boot)

[nblumhardt]

Thanks @zagros - it sounds like perhaps the missing datum was "full .NET Framework". Do you have the <AutoGenerateBindingRedirects>True</AutoGenerateBindingRedirects> in your .csproj file? Thanks again 👍

[zagros]

No that node doesn't exists

By default it's true

Here's the copy of the propertygroup that normally would have that <AutoGenerateBindingRedirects> if it were to be explicitly mentioned

in my case it's not there at all and hence takes the default behaviour

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{0A749D0A-22AF-4976-A82B-86EA60ECE1EE}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>MyProject.Extensions.Logging</RootNamespace>
    <AssemblyName>MyProject.Extensions.Logging</AssemblyName>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <TargetFrameworkProfile />
    <NuGetPackageImportStamp>
    </NuGetPackageImportStamp>
  </PropertyGroup>

I think it's fair to update the version of the dependency library as the very first post in this thread suggests - 1.0 is long come and gone

[nblumhardt]

I've updated our dev branch to publish a new major version; I don't think there's a lot of harm in making this change, just to keep things simple - is anyone able to PR this?

[MV10]

Not to hijack the topic, but any chance you'd be willing to update Microsoft.Extensions.Configuration.Abstractions to 2.0 at the same time? I use this settings-provider, and next week I'm going to look at fixing the netsandard MS SQL sink config issue and would prefer to go with MEC 2.0 across the board. (I haven't checked whether other Serilog repos are dependent on MEC.)

Probably low-risk, it has been my experience that upgrading MEC 1.0 references to 2.0 are largely transparent. (The only real issue for the .NET Framework side is that annoying SDK JSON.NET =9.0.1 binding redirect mess... the MEC.Json 2.0 specfies =10.0.1 or maybe >=10.0.1).