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.

FluentValidation

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:

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:

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.

ServiceStack.Razor

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

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:

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

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!

mythz
—
2017-10-16T15:39:00Z —
#2

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.

la2texas
—
2017-11-09T05:37:06Z —
#3

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

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=5.0.0.0, 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

mythz
—
2017-12-05T13:58:13Z —
#8

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?

connatix
—
2017-12-05T16:04:33Z —
#9

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

connatix
—
2017-12-05T16:20:01Z —
#10

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

Thanks

connatix
—
2017-12-05T17:23:51Z —
#11

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.

Thanks

mythz
—
2017-12-05T18:16:57Z —
#12

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:

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.

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

georgehemmings
—
2017-12-17T22:31:28Z —
#15

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

mythz
—
2017-12-18T00:31:48Z —
#16

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

georgehemmings
—
2017-12-18T06:55:02Z —
#17

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.

mythz
—
2017-12-18T09:10:52Z —
#18

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.

sergLo
—
2017-12-18T12:50:40Z —
#19

OK, that's interesting

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?

lsl
—
2017-12-18T13:35:43Z —
#20

sergLo:

support of NETStandard.Library and from 4.7.1 as far I understood even without the supporting lib