MyGet pre-release packages upgraded to v5

A quick announcement for anyone using the pre-release MyGet NuGet packages that we’ve now upgraded the major version to v5.0.0.

Currently the major structural changes include:

  • All NuGet packages have a 5.0.0 Version
  • All .Core packages are merged into the main ServiceStack NuGet packages and share the same v5 version number
  • All .NET Standard or PCL builds have been upgraded to .NET Standard 2.0
  • All .NET 4.5 .dll versions are now strong named with the servicestack.snk key that’s in the /src of each repo. ServiceStack.Logging.Elmah is the only .NET 4.5 dll that’s not signed because its elmah.corelibrary dep is unsigned.

We’ve rewritten the PCL client builds to use the .NET Standard 2.0 APIs which now supports Xamarin iOS/Android. v5 also support UWP but .NET Standard 2.0 but this requires upgrading to Windows 10 Fall Creators Update. There’s no longer any Silverlight or Windows Phone builds which end at v4.5.14 on NuGet, v5 is still wire-compatible so if you’re still maintaining legacy Silverlight or Windows Phone Apps your v4.5.14 clients can consume v5 Services as before.

Currently if you’re using the MyGet builds:

  • You’ll need to upgrade your ServiceStack dependencies to the major 5.0.0 version or use a 5.* wildcard.
  • If you were using the Signed packages you’ll need to remove the .Signed suffix
  • If you’re using .NET Core you’ll need to remove the .Core suffix on each package.


We’ve upgraded our internal implementation to use the latest version FluentValidation 7.2

.NET Core IAppSettings Adapter

You can use the new NetCoreAppSettings adapter to utilize .NET Core’s new IConfiguration config model in ServiceStack by injecting .NET Core’s pre-configured IConfiguration injected into the Startup constructor when you register your AppHost, e.g:

public class Startup
    public IConfiguration Configuration { get; }
    public Startup(IConfiguration configuration) => Configuration = configuration;

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        app.UseServiceStack(new AppHost
            AppSettings = new NetCoreAppSettings(Configuration)

This will let you use appsettings.json and .NET Core’s other Configuration Sources in ServiceStack under the IAppSettings API which works as you’d expect where you can get both primitive values and complex Types with Get<T>, e.g:

bool debug = AppSettings.Get<bool>("DebugMode", false);
MyConfig myConfig = AppSettings.Get<MyConfig>();

We’ve switched all our .NET Core 2.0 SPA projects to use the above .NET Core configuration model, e.g. here’s the react-spa source code.

New Password Hashing implementation

We’re now using the same PBKDF2 password hashing algorithm ASP.NET Identity v3 uses to hash passwords by default for both new users and successful authentication logins where their password will be re-hashed with the new implementation automatically. You can revert to using the existing SaltedHash implementation with:

SetConfig(new HostConfig { 
    UseSaltedHash = true

This also supports “downgrading” passwords that were hashed with the new IPasswordHasher provider where it will revert to using the older/weaker SaltedHash implementation on successful authentication.

Digest Auth Hashes only created when needed

We’re also only maintaining Digest Auth Hashes if the DigestAuthProvider is registered. If you ever intend to support Digest access authentication in future but don’t want to register the DigestAuthProvider just yet, you can force ServiceStack to maintain Digest Auth Hashes with:

new AuthFeature {
    CreateDigestAuthHashes = true

Users that don’t have Digest Auth Hashes will require logging in again in order to populate it. If you don’t intend to use Digest Auth you can clear the DigestHa1Hash column in your UserAuth table which is otherwise unused.

Features that need to be explicitly registered

SOAP Support is now opt-in, if you need it you’ll need to register:

Plugins.Add(new SoapFormat());

Markdown Razor and MiniProfiler are also opt-in and have been moved to different projects below:

Separate NuGet package for .NET Framework specific features

We’re aiming to make the primary ServiceStack.dll and NuGet Package containing core functionality that’s applicable to all Hosts, i.e. ASP.NET, HttpListener and .NET Core so we’ve started moving ASP.NET/HttpListener specific features to different packages but we’re keeping the same namespaces/type names to ensure maximum source compatibility.


The HTML Helpers for ServiceStack Razor has been moved to the ServiceStack.Razor project. This should be a transparent change as you needed ServiceStack.Razor to make use of them.

MarkdownFormat and Markdown Razor has also been moved to ServiceStack.Razor. Since this was built on Code DOM it can’t run on .NET Core and was stripped down to bare Markdown functionality. This was previously pre-registered by default, if you were using it you’ll now need to explicitly register it, e.g:

Plugins.Add(new MarkdownFormat());

Also ServiceStack Templates is a much superior, cleaner, faster and more flexible alternative to Markdown Razor where its most redeeming feature of being able to mix .NET in Markdown can be easily be achieved using Transformers.


ServiceStack.NetFramework is a new project/NuGet package where we’re maintaining .NET Framework only features. This currently contains MiniProfiler which now needs to be explicitly registered with:

Plugins.Add(new MiniProfilerFeature());

And SmartThreadPool which is an internal ThreadPool to provide a faster alternative to .NET’s built-in ThreadPool. The fastest self-hosting option is now to use a .NET Core App instead of HttpListener which also runs flawlessly cross-platform so it’s our recommended option for new projects if you don’t have any requirements requiring use of the .NET Framework. The primary result of this is that now AppSelfHostBase is implemented using AppHostHttpListenerPoolBase. If you want to revert your HttpListener AppHost back to using a SmartThreadPool impl, change your AppHost to inherit either SmartThreadPool.AppSelfHostBase or AppHostHttpListenerSmartPoolBase, e.g:

public class AppHost : SmartThreadPool.AppSelfHostBase {}
public class AppHost : AppHostHttpListenerSmartPoolBase {}

New .NET Core 2.0 SPA Templates

We’ve developed new Webpack-powered .NET Core 2.0 SPA Templates which uses the pre-release version of ServiceStack v5 which are available from:

You can use the dotnet-new script included as part of @servicestack/cli project to create projects from the different templates.

You’ll need to have the latest @servicestack/cli v1.0.0 installed. If you had a previous version you’ll need to remove it:

npm uninstall -g @servicestack/cli
npm uninstall -g servicestack-cli  # old npm package name

Before installing it again to get the latest version:

npm install -g @servicestack/cli

This will make the dotnet-new script available which you can use to view all the available templates by running it without any arguments:

$ dotnet-new

Which at this time displays:

You can then create a project from one of the templates, e.g:

$ dotnet-new vue-spa Acme

Which will generate a new project with the folder names and source files replaced with your project name, e.g:

You can run then run the Acme.sln in VS2017 which will automatically restore and install both the .NET and npm packages when first loaded. This can take a bit of time to install everything, once it’s finished you’ll see the wwwroot folder populated with your generated Webpack app which includes a dist folder and index.html page. After these are generated you can run your App with F5 as normal.

If you’re using JetBrains Rider you can install npm packages by opening package.json and run the “npm install” tooltip on the bottom right. In VS Code you’ll need to run npm install from the command-line.

To develop your App, our preference would be to run Webpack watch on the command-line with:

$ npm run dev

Which will watch and re-compile your App for any changes. These new templates also include a new hot-reload feature which works similar to ServiceStack Templates hot-reloading where in DebugMode it will long poll the server every 60s for any modified files in wwwroot and automatically refresh the page. This provides a hot-reload alternative to npm run dev-server to run a Webpack Dev Server proxy on port http://localhost:3000

The new Templates is similar to ServiceStack’s .NET 4.5 Webpack SPA Templates except it’s been modified to use Webpack’s DllPlugin for faster build times.

For publishing / deployments we just make use of .NET Core’s dotnet publish feature which you can run with:

$ npm run publish

Which will generate a production optimized build and dotnet Release build in the bin/Release/netcoreapp2.0/publish output folder, which you can then xcopy/rsync to any deployment server similar to deploying .NET Core 2.0 Web Apps.

All the template features are available as both npm scripts and gulp scripts (which just call the npm scripts), which you can run with:

npm run <script-name>

Which currently includes:

npm run watch
npm run build
npm run build-prod
npm run build-vendor
npm run publish
npm run test
npm run test-watch
npm run typescript-ref
npm run dev

That should get you up an running. If you find any issues with ServiceStack v5 of the new Templates please let us know!


This topic is now pinned globally. It will appear at the top of its category and all topic lists until it is unpinned by staff for everyone, or by individual users for themselves.

1 Like

How does adding TemplatePagesFeature in the React Startup.cs give you server side rendering out of the box?

It’s configured to handle .html by default where the generated wwwroot/index.html page Webpack generates from the index.template.ejs contains Template Expressions which are evaluated whenever the home page is returned.

Where might one disable the 1 second poll to refresh the app?

The hot-reloading is no longer a 1s poll in the latest v5, it’s now a 60s long poll which you can get by clearing your NuGet cache:

$ nuget locals all -clear

and restoring again. The code that does the poll is in the index.template.ejs page:

{{ ifDebug | select: <script>{ '/js/hot-fileloader.js' | includeFile }</script> }}

Which only runs in DebugMode so you can set Config.DebugMode=false, remove the line above, or just comment it out:

{{* ifDebug | select: <script>{ '/js/hot-fileloader.js' | includeFile }</script> *}}
1 Like

We tried using now v5 but unfortunately it fails on .NET Framework with the following exception:

Could not load file or assembly 'ServiceStack.Text, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

We have a solution with some .net framework apps targeted to .NET Framework 4.6 and some shared libraries targeting .NET Standard 2.0 and the exception is being thrown from the .NET Standard projects. Any ideas?

Thank you

Are you using the ServiceStack.Text NuGet Package on MyGet? Can you first try clearing your NuGet cache to see if that helps:

$ nuget locals all -clear

Also you won’t be able to share .dll’s between .NET Framework and .NET Standard projects, but for .NET v4.6.1 client projects you can reference ServiceStack.Client.Core package to force it to use .NET Standard version which you will be able to share with other .NET Standard and .NET Core projects.

If it’s still an issue can you put together a stand-alone project where this fails?

Hi @mythz. I have cleared the cache and also tried a new solution but with the same outcome. Below is also a link to the new solution and if you build it you’ll see that the output contains the .NET Framework library which will be an issue when the netstandard class library will try to load and an exception is thrown.

BTW, should I use the ServiceStack.Text.Core that has only .NET Standard targeting?

Thank you

If I use in both projects the Core package everything is working fine. Is this the desired behaviour?


Unfortunately there is no way to solve this because ServiceStack has a dependency on ServiceStack.Text and we can’t have both Text and Text.Core referenced at the same time. This is becoming a huge issue for us because we spent a lot of time upgrading our whole architecture to NetStandard and now we are blocked on this. Any help would be really appreciated.


You can’t mix .NET Standard only project referencing ServiceStack dependencies with a .NET Framework ServiceStack project, this was never supported. Why did you upgrade to .NET Standard if you’re not going to use .NET Core?

A .NET Framework project uses the .NET Framework dependencies whilst .NET Standard and .NET Core projects use the .NET Standard builds. You can go the other way around have a .NET Core Server sharing .NET Standard only projects with a .NET Framework .NET v4.6.1+ client by getting them to reference the .NET Standard builds in the ServiceStack.Client.Core packages, so they’re all only referencing .NET Standard dependencies.

Not sure what you’re trying to achieve with this hybrid mix of projects but if you want to maintain both .NET Standard and .NET Framework projects you can change your .csproj dependency project to create both .NET Standard 2.0 and .NET Framework .NET v4.6 builds with:


Which will let you reference this project in both ServiceStack .NET Framework and a ServiceStack .NET Core projects.


looks like I’m also running more or less in the same problem in V5.
We moving torward netstandard but we have some services/projects that rely on FullNet because of some external dependencies.

Short description:

[BaseLib | netstandard | used by all others projects | depends on: SS.Core]
[Service1 | netcoreapp | business | depends on: BaseLib ]
[Service2 | net462 | business | depends on: BaseLib and some external dependencies ]

Service1 and Service2 have no direct dependencies on SS.Core packages because they are resolved by hierachy. Both are working fine.

Since V5:
Service2 complains now that ServiceStack.dll is missing when trying to access e.g. a property from UserAuth.

I created a servicestack.core.nuspec with only targetFramework=".netstandard2.0" (so no net45) without
any other changes and everything was working fine again after referencing in BaseLib. Looks like if targetFramework=“net45”> exists, resolving of hierachy dependencies is not working - even if I add ServiceStack nuget package to the Service2 the problem exists.

I would like to avoid to target netstandard2.0 and net46 for all the base libs because this introduce other problems. For example Newtonsoft.Json is also added in the BaseLib and its working fine in all projects/services.

Any suggestions? Can SS behave like Newtonsoft.Json? Can we bring *.Core packages back with V5? Looks like its only a problem with resolving so only nuspecs need to be added.


.NET Standard Server libraries = .NET Core builds, they cannot be used in .NET Framework projects.

Only the .NET Standard client libraries can be used in .NET Framework clients which from v5 are:

  • ServiceStack.Text.Core
  • ServiceStack.Interfaces.Core
  • ServiceStack.Client.Core
  • ServiceStack.HttpClient.Core

And from the latest v5.0.1 on MyGet we’ve also added:

  • ServiceStack.MsgPack.Core
  • ServiceStack.ProtoBuf.Core

Hey @mythz is there a reason these packages were suffixed with .Core instead of . Standard (or similar)? Just interested and checking my understanding.

The .NET Standard packages are for .NET Core with .Core being the shortest suffix which conveys that.

I just find that a bit confusing, as the .Core packages can also be be used with .NET Framework clients, they are not exclusively for use with .NET core. I’ll get used to it. I get that they are named from the server perspective.

The purpose of the .Core packages was to only work with .NET Core. For v5 we dropped PCL builds and converted everything to .NET Standard 2.0 which we wanted to ensure had the broadest compatibility which supports .NET Core, iOS, Android, latest UWP and .NET Framework. We’re specifically continuing ti publish the .Core packages to support the additional use-case of allowing .NET Framework v4.6.1+ clients to be able to have binary coupling with .NET Core Server .dlls.

But the server libraries like ServiceStack.Core can’t be used on the .NET Framework, the .NET Standard builds was designed specifically to create a version of ServiceStack that runs on .NET Core. ServiceStack’s single code-base and implementation strives for max source code compatibility where essentially the same ServiceStack App can run on both .NET Framework and .NET Core. It was never planned or supported to run a ASP.NET Core ServiceStack App using the .NET Standard builds of ServiceStack on the .NET Framework.

It’s not a supported use-case but I expect the .NET Standard builds of Redis to be able to run on .NET Framework since it has no external dependencies and very little added support was needed to support .NET Core.

The .NET Standard builds of OrmLite is less likely to be able to run in .NET Framework since some RDBMS’s reference different packages depending of if it’s for .NET Core or .NET Framework and given the existence separate packages it’s unlikely the version that works on .NET Core will be able to run on .NET Framework.

Either way the only supported use-case we want the broadest support for are the Service Clients libraries which we’d like to be able to run on any popular client platform that supports .NET Standard 2.0.


OK, that’s interesting :smile:

Maybe I’m missing something. What I did now is to copy all netstandard libs (NuGet//lib/netstandard2.0/) to one large package and referenced it in the BaseLib so hierachy resolving of dependencies is working now and all services are runing without any problems (netcoreapp2.0 and net462). We are using AspNetCore (2.0.3) with netcoreapp and net462 as TargetFramework . So all services using WebHostBuilder etc. and the only one difference is the TargetFramework. If I use the official package than I’m getting compile errors like “ServiceStack.dll” is missing for net462 projects - if the package only contains netstandard2.0 everything works fine. Ofc we are using the lowest feature set of ServiceStack for netstandard and not everything thats available for .Net Framework. But this setup worked befor out-of-the-box and now I have to create my own package with only netstandard bits. netstandard2.0 libs can be used by .Net Framework (with support of NETStandard.Library and from 4.7.1 as far I understood even without the supporting lib). So the behaviour should be the same independently of the TargetFramework, or?

Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.

1 Like