How is .Net Core support coming along for the main libs like ServiceStack and OrmLite?
It’s going pretty well, we’ll be announcing it in the next v4.5.2 release. If you want to try it early, here are instructions for accessing .NET Core packages for OrmLite: http://stackoverflow.com/a/39684977/85785
If you want to test out ServiceStack on .NET Core you can check out the Live Demos we’ve ported over at: https://github.com/NetCoreApps
Awesome news Demis. How are you finding writing .Net Core stuff? Lots of changes or restrictions?
There’s a few core dependencies missing so we lose a few features, namely:
- SOAP Support (inc. WSDL, XSD)
- Mini Profiler
- MVC Html Extensions
- Markdown Razor
- OAuth2 providers (no DNOA)
The big one is
ServiceStack.Razor which we’d have to completely rewrite after the aspnet team refactor .NET Core Razor host so it can be reused - so we’re doing some R&D in the meantime on what the best way to integrate SS + MVC would look like.
But otherwise most features just work, the main difference when porting the Live Demos is that the website assets are now in the
wwwroot folder which we change the VFS FileSystem provider to point to, the other difference is that .NET Core reflection API’s have changed, e.g. from
typeof(MyService).GetTypeInfo().Assembly so to make source code compatible we’ve created a number of extensions wrappers that support both .NET 4.5 + .NET Core, e.g.
Otherwise I’m happy with the amount of code-reuse we’re able to get so migrations should be very easy, in some cases like the CustomerRestExample.cs (that’s on ServiceStack’s home page) the same source code runs on both .NET 4.5 and .NET Core which was our ultimate goal.
We also have other nice integrations with .NET Core, e.g. by default the LogFactory is configured to use .NET Core’s logging provider and we register a Container Adapter to fallback to resolve .NET Core services so any dependencies registered in .NET Core can be used in ServiceStack Services. Also ServiceStack is registered as a normal .NET Core module and works well in the pipeline where any request that’s not handled by SS is passed to the subsequent module.