Next major v5 release

Hi,

I read in a recent topic over here about the next major v5 release. Can you:

  • tell us more on what major features your are targetting
  • are major releases included in our yearly license

Thx.

Major releases have nothing to do with Licensing, releases work as they always do by the release date of each version.

Instead a major release is a window by which we make structural changes similar to how v4.5 was when we upgraded all packages to .NET 4.5. The major changes for v5 include:

  • Upgrading to use v3 NuGet spec which allows specifying different dependencies for different builds
  • Merging the .NET Core packages into main packages so they follow the same release cadence as .NET 4.5 packages
  • Upgrade .NET Core packages to .NET Core 2 and .NET Standard 2 which looks like the first .NET Core version which will be stable and have longevity
  • Drop PCL and Silverlight builds in favor of .NET Standard
  • Remove all deprecated APIs (Except for OrmLite legacy deprecated APIs)

The timeline for v5 will be just after Microsoft release the stable (i.e. non-beta) release of .NET Core / .NET Standard 2.0. Development of ServiceStack features continue as they always have, being mostly driven by User requested features on UserVoice as well as what compelling features I believe a Services framework should have which is how ServiceStack gets unique features like Add ServiceStack Reference, Auto Query, Auto Batching and Encrypted Messaging, etc which users don’t know to ask for since they don’t exist elsewhere.

The other major change we’re considering is whether to sign all packages following the same approach as we’re doing with ServiceStack.Interfaces where we keep the AssemblyVersion fixed at 5.0.0.0 and use the Assembly File Version to report the true version number. We’d like to hear from the existing community on whether we should do this as we’re against the friction of strong naming but we’re leaning towards doing it as our ServiceStack.Interfaces approach hasn’t seen any reported issues due to strong naming since we added it in v4, Strong naming isn’t going away as I hoped (and it looked like it was going to at one stage in .NET Core), we’ll only have 1 NuGet package for all platforms that can be used in both Signed/non-Signed projects (which would’ve avoided the quick fix v4.5.12 release where Embedded Resources we’re embedded in the wrong location after moving to VS2017 new MSBuild format). If we do go with Strong naming by default we’ll be publishing our Signing key so everyone can continue to create custom builds of ServiceStack.

We’re going to create a GitHub issue to be able to measure what the preferred approach is on whether to sign all packages by default or not. But if anyone has any reason why we shouldn’t Sign all our packages I’d like to hear them in the comments below.

Thanks for the insights on features and licensing.

I still like to see a chance to bring back all the login providers as there are in .net and are in the native .net core libraries (for example Google).

That’s not really bringing back existing support since DotNetOpenAuth providers don’t run on .NET Core, that’s more developing new OAuth2 AuthProviders that will work on .NET Core, which is on our radar for after v5.

1 Like

FYI I’ve added a GitHub issue to measure interest in Signing vs non-Signing packages in v5: https://github.com/ServiceStack/Issues/issues/548

I was under the impression if a program written for stand2.0 can be directly referenced by the net4.6 program,
Here are some of my expectations:

  1. now the logic of user registration and login is too complex, and each time a new field is added to meet a requirement.
    2.can we add more common features, like email authentication, password retrieval, planning tasks, and so on(https://github.com/aspnetboilerplate/aspnetboilerplate)
  2. many third party libraries are based on asp.net, and are compatible if some of our functions are re implemented (for example, asp.net provides registered login? The third party libraries just rely on him, and we have achieved it ourselves, and that can not be compatible, right? )

We may have different cultures and ideas, and this product of yours is also famous here. I hope you will be better and better。

@lsl We strive to retain as much source compatibility between .NET 4.5 and .NET Core as possible, but our .NET Standard Server dlls (e.g. ServiceStack, ServiceStack.Server) are designed to work in .NET Core Hosts and their new Web Hosting dev model whilst the .NET Framework builds are designed work in ASP.NET or HttpListener hosts as always.

When we merge .NET Core and .NET Standard packages together there will still .NET Framework builds and .NET Standard builds in the same package, when you add a reference to the package in a .NET Framework App NuGet will add a reference to the .NET Framework .dlls whilst when you reference it in a .NET Core App NuGet will reference the .NET Standard .dlls instead. We’re going to try and only have a single .NET Standard build for all different client platforms, but if there’s functionality in .NET Standard APIs missing we may need to have concrete adapters for each client platform (e.g. Xamarin.iOS/Android, Windows Store) like we do know.

Yeah we definitely plan to rewrite our Auth docs and make them more approachable with more samples for common scenarios, etc. Which is high on our TODO list.

You should submit any new features you want on UserVoice so we can measure interest and prioritize accordingly.

If you’re referring to Custom ServiceStack AuthProviders they will be portable, if you’re referring to ASP.NET Auth Providers like in ASP.NET MVC they will not.