>>We’re maintaining .NET Core packages isolated from the Main NuGet packages separated with a `.Core` suffix
Please add a link on the main https://www.nuget.org/packages/ServiceStack/ page to inform that Core is a separate package.
It's confusing to install the ServiceStack package and find that it doesn't support .net Core

The MySql.Data NuGet package doesn't support .NET Core yet but looks like the next v7 major release of it will, unfortunately they went a bit high and are requiring .NET Standard 1.6, whereas all other OrmLite RDBMS providers only require .NET Standard 1.3.

Congrats. Looking forward to trying the rest (other than .Text).

Do you know what's going on with MySQL? I know they don't yet have an stable Entity Framework release yet either.

@RedRidingHood Yep we're still exploring the best ways to get started on VS.NET and VSCode, we'd like to have project templates for both.

In the meantime we've got some empty ServiceStack .NET Core project types at:
https://github.com/NetCoreApps/Hello/tree/master/src

This is great. Is it possible to update the get started pages to include getting started with VSCode?

@Demis could you give us an update?

I see 4.5.2 is released but i don't see any net.standard dependencies?

For us, having access to your wonderful Redis client for .NET core will put the finishing touches on our conversion. We are anxiously awaiting its arrival.

@Demis Thanks for the response and info

@Chris No the VS.NET tooling for MSBuild projects and CoreCLR is not available yet and we need to maintain our existing VS.NET C# projects to keep existing .NET 4.5 releases unaffected during the transition.

ServiceStack.Interfaces is a pure PCL project which doesn't require multiple targets and we already have CoreCLR support for, we've nearly completed ServiceStack.Text but there's still some regression tests that need resolving, soon after that we'll have the ServiceStack.Client release ready - which we hope to ship out soon.

After the ServiceStack.Client release we'll work on ServiceStack.Redis, hopefully by that time more RDBMS ADO.NET providers will have support for .NET Core so we can port OrmLite. Then after that we can finally start the work on the core ServiceStack .dll - which will require the most effort given the ASP.NET System.Web framework it's built on doesn't exist in CoreCLR.

Since CoreClr lets you generate for multi frameworks couldn't you at least start with your interfaces project and make it work with say CoreCLR, 4.6,4.5, 4.0? Wouldn't that let you keep your existing userbase un affected as you slowly port more to CoreCLR? At the minute some of out shared classes reference your interface project as that containes your Ignore attribute and then that means that we can't even convert our libraries over to support both existing versions and CoreCLR

@Chris .NET Core just got released last month, before last months release it was a highly volatile and radioactive platform to target where our initial porting efforts at its start had to be discarded. It now has an official release but still has several outstanding issues preventing many people from being able to port to it including not having proper VS.NET tooling support which hurts 3rd party developers like us in supporting existing code bases in parallel.

We have to support it with minimal disruption to our existing Customers where our goal is to maintain the existing code-base for multiple platforms with minimal breaking changes which we're planning to do in stages starting with the next release being our last .NET 4.0 release as announced at the start of this year: https://github.com/ServiceStack/ServiceStack/blob/master/docs/2016/v4.0.54.md#changes

After this release we'll upgrade all projects to .NET 4.5 and make .NET Core support our top priority, delivering releases in the order specified in my previous comment. But the work is still largely an unknown quantity as Microsoft has completely rewritten the ASP.NET Web Stack without regard for backwards compatibility and ServiceStack encompasses a lot of software developed over several years which is going to make it harder than a straight-forward port, but it's something we're committed to which we'll try to support with minimal disruption to existing ServiceStack Customer code-bases as .NET Core allows us.

I have to say this is affecting us as well as we were hoping to move our new apps to .NET Core now it is released but we normally use service-stack. Now i need to consider just using the libs built into .NET Core instead of Service-stack if service-stack is having trouble keeping up with .NET then it does become a risk that may prevent us from being able to use the latest technologies.

@Anonymous It's not possible to provide any kind of timeline for .NET Core which is still an unknown scope of work. We've started working on it in the netcore branches of each Repo, we plan on shipping the Client libraries first, followed by Redis, OrmLite than ServiceStack Core. We plan on making supporting .NET Core the primary focus after next release after we upgrade all projects to .NET 4.5.

How many other packages we'll be able to support will largely depend on whether the dependencies support .NET Core and how much functionality is missing.

We'll provide updates here as we go.

@demis, any idea of a timeline for this now that .net core is shipped?

Is DNX support in a roadmap? RC1 is already here with "go live" license.

Thanks. @Demin

Note ServieStack was built cross-platform where most of the Live Demos can already run on OSX/Linux with Mono including our latest release of React Desktop Apps: https://github.com/ServiceStackApps/ReactDesktopApps

But I agree the future of hosting production ASP.NET websites on Linux is DNX which will be our priority after its released.