Hi,
has anyone tested and integrated ServiceStack with evhttp-sharp (https://github.com/kekekeks/evhttp-sharp)? It has a NancyFX host so it should also be possible to attach ServiceStack.
I’m building a high performance website and hope that evhttp-sharp can assist here.
Best,
Andreas
Looks like development on that project has stopped. Either way it’s not going to support ServiceStack as it’s not based on ASP.NET or HttpListener abstractions.
The future of fast, cross-platform self host is very likely going to be .NET Core and Kestrel but we need to port to .NET Core before that can happen, which will be our priority after it’s officially released.
Sounds good, and .NET Core 1.0 is not far away either.
What is the main aspect which needs to be ported? Are there currently any pain points?
.NET Core has been a constant stream of breaking changes which has only just recently decided to focus backwards compatibility and bring back a more complete API Surface as a goal. But they’ve removed System.Web and created all new HTTP Abstractions which will require a bit of effort to support. It’s going to largely depend on what API’s are missing, e.g. if they don’t support WCF’s System.ServiceModel.dll we wont be able to provide SOAP support / WSDL’s / XSD’s etc.
As a new platform, the tooling is weak and many 3rd party deps won’t be supported from the start, luckily we don’t have any for the core ServiceStack .dll and we’re in control of our own destiny. But not having full NUnit support is going to hurt us and we may have to switch to NUnitLite and isn’t clear how many tests we need to rewrite or how much effort is required.
Are you planning to open a .NET Core branch of Service Stack anytime soon, so we can contribute?
@xplicit is looking into porting the ServiceStack.Client/Text libraries now.
But for ServiceStack Server libraries we need to wait after August 1st as we’re going to be upgrading all projects to .NET 4.5, we also need VS tooling to be released and then upgrade our CI to support parallel builds, then I need to layout the architecture for how we’re going to support both .NET Fx and .NET Core, after the necessary groundwork has been laid out we can open it up to contributions then.
So it’s not going to be too soon, the client libraries and Redis client will come first (since they don’t have any dependencies and are free from deps on System.Web). Then we’ll start working on the server libs after August 1st, hopefully new VS with new VS tooling will be released by then.
Btw - I like to see @xplicit working on this, we’re using HFC productively.
I’d like to offer to jump in contributing to developing the .NET Core compatibility for the ServiceStack server components as early as possible - if possible at all.
While HFC is faster than every other Mono FastCGI implementation, we’re still not satisfied with the speed provided (in terms of rps, threading with Mono etc…). My timeline is that we want to be utilizing .NET Core with Kestrel within the next 3 months, and go productive end of the year with another project, switching over from HFC.
Any chances?
@xplicit has already started working on .NET Core support in the netcore branches of each repo. We’ll be shipping .NET Core support for the Client libraries first, followed by Redis, OrmLite and then ServiceStack core. How much of the other packages we’ll be able to port depends on whether their dependencies support .NET Core and how much of the Surface area in .NET Core is available.
.NET Core is more than likely the future for running stable / high-performance .NET on Linux so we intend to just focus on that for now. I’ll be jumping in after next release so we can accelerate the support for it, once I have a rough idea of the scope of work required I can setup the architectural class structure and official API integration to support multiple platforms and hopefully after I get a spike working I can invite you to contribute. I think it makes sense to use porting your project as a real-word test case in order to help identify any regressions, etc. So your efforts could be focused around filling in the blanks to get your existing Web App working reliably on .NET Core/Linux.
Awesome, I’m happy to hear that. I’m also on the same page thinking that .NET Core is the future on Linux. I’ll be starting to maintain .NET Core branches of multiple projects as soon as you can give a greenlight that it makes sense to do so. We’re having around 3 projects in parallel targeting a million active daily users each, so having higher performance on the backend means reduced costs (which are currently high).
We’re mainly on AWS, using their C# SDK.
Projects are diverging in used tech conventions and language features a little bit (one uses async/await, the other not, etc).
So we’ll have a good test bed with that.
I’m looking forward to be able to contribute!