V5.13 ServiceStack.Kestrel.Core Dependency Conflict

I have a unit testing project targeting net472 with a package reference to ServiceStack.Kestrel.Core. Prior to today, that package reference looked like this:

<PackageReference Include="ServiceStack.Kestrel.Core" Version="5.12.0" />

Now that v5.13 is available, I went ahead and updated all my package references. Every project that uses ServiceStack.Core (and other ServiceStack.*.Core references) built correctly except for this unit test project, which threw errors like this:

error CS0433: The type ‘AppSelfHostBase’ exists in both ‘ServiceStack.Kestrel, Version=, Culture=neutral, PublicKeyToken=null’ and ‘ServiceStack, Version=, Culture=neutral, PublicKeyToken=02c12cbda47e6587’

After some spelunking, I discovered that both the Core flavors and non-Core flavors of ServiceStack dlls were being found and I narrowed it down the dependencies listed for ServiceStack.Kestrel.Core v5.13:

  <group targetFramework=".NETStandard2.0">
    <dependency id="ServiceStack.Client" version="5.13.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack.Common" version="5.13.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack.Interfaces" version="5.13.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack" version="5.13.0" exclude="Build,Analyzers" />

The same nuspec from v5.12 looked like this:

  <group targetFramework=".NETStandard2.0">
    <dependency id="ServiceStack.Client.Core" version="5.12.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack.Common.Core" version="5.12.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack.Interfaces.Core" version="5.12.0" exclude="Build,Analyzers" />
    <dependency id="ServiceStack.Core" version="5.12.0" exclude="Build,Analyzers" />

Rolling back my package reference for ServiceStack.Kestrel.Core to v5.12 solved the build errors, even with all other ServiceStack-related package references still at v5.13. Is this an oversight in the .nuspec for the ServiceStack.Kestrel.Core package?

Yes a mistaken oversight which has been resolved in this commit.

Thanks for reporting, this change is available from v5.13.1+ that’s now available on MyGet.