Environment
ServiceStack.Core v1.0.43
ServiceStack.Kestrel v1.0.43
Visual Studio 2017 v15.3 Preview 2.1
.NET Standard 2.0
.NET Framework 4.6.1
Problem
Working in the environment described above we are encountering a version mismatch of the Microsoft.Extensions.Primitives library. ServiceStack.Text is expecting v1.1.1 while ServiceStack.Kestrel has a dependency which expects v1.1.0 of the microsoft dll. The stack traces below outline these exception we are seeing.
Intent
Our goal is to run as a Windows service (.NET Framework) using .NET Core libraries. Our .NET Core libraries are planned to be shared between our .NET Framework project and future Linux executable.
Stack Traces Source: Microsoft.Extensions.Configuration Message: Could not load file or assembly ‘Microsoft.Extensions.Primitives, Version=1.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) StackTrace:
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at Microsoft.AspNetCore.Hosting.WebHostBuilder…ctor()
at ServiceStack.AppSelfHostBase.Start(String[] urlBases)
at ServiceStack.AppSelfHostBase.Start(String urlBase)
Source: ServiceStack.Text Message: The type initializer for ‘ServiceStack.Text.JsConfig’ threw an exception. StackTrace:
at ServiceStack.Text.JsConfig.InitStatics()
at ServiceStack.ServiceStackHost…ctor(String serviceName, Assembly[] assembliesWithServices)
at ServiceStack.AppHostHttpListenerBase…ctor(String serviceName, Assembly[] assembliesWithServices) INNTER EXCEPTION: Source: ServiceStack.Text Message: Could not load file or assembly ‘Microsoft.Extensions.Primitives, Version=1.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) StackTrace:
at ServiceStack.Text.JsConfig…cctor()
All ServiceStack.Kestrel deps are now referencing 1.1.1 so hopefully that makes a difference, but I don’t see how, maybe you’ve got an explicit reference to Microsoft.Extensions.Primitives 1.1.0 somewhere in your projects or other deps?
Anyway the latest v1.0.44 with the updated deps is now available on MyGet. Please let me know if that makes a difference?
I pulled down the latest version of ServiceStack.Kestrel from MyGet to try these changes and it was unable to resolve the exception we’re seeing.
We do not have an explicit reference to Microsoft.Extensions.Primitives v1.1.0 in our code and following the stack trace above we can identify where the difference in versions arise from. Listed below is a top to bottom dependency list to show where one of ServiceStack.Kestrel’s dependency has a dependency on v1.1.0. Whereas other ServiceStack libs have a dependency on v1.1.1, causing this conflict.
I’ve also created an example solution to help provide additional insight to what we are seeing. The solution will build successfully after restoring the NuGet packages and will fail at runtime looking for the Microsoft.Extensions.Primitives v1.1.0 dll. The version of Visual Studio used is VS2017 v15.3.0 Preview 2.1, .NET Framework 4.6.1 and .NET Standard 2.0.
The sample solution can be downloaded from GitHub at:
This project mixes .NET Framework with .NET Standard libraries, if you’re developing .NET Framework you should be referencing the main .NET Framework ServiceStack NuGet packages, if you’re developing a .NET Core App you should be referencing the .Core ServiceStack NuGet packages instead.
We don’t support .NET Framework App using .NET Core / .NET Standard libraries.
We would like to be using a .NET Framework executable to run as a Windows service. The executable will invoke the AppHost, which resides in a separate assembly, and the .NET Framework project will not be referencing any ServiceStack libs. Only the assemblies which implement the ServiceStack base classes will have references to ServiceStack libs and will all be .NET Core class libraries.
I attempted to illustrate with the example, a .NET Framework project (without ServiceStack references) which invokes the AppHost in a separate assembly (.NET Core class library) that has the .Core ServiceStack NuGet dependencies.
To clarify the scenario described above is not supported?
If you want to develop a .NET Framework Windows Service it needs to reference the main .NET Framework NuGet packages. The ServiceStack .NET Standard builds are designed to be used in .NET Core Apps so you can’t have binary coupling to the .Core packages from a .NET Framework host but you can do something like start a .NET Core Console App Process from a .NET Framework Windows Service as that wouldn’t have any binary coupling.