Add a starter template showing how to get started with a Single Page App with AngularJS + Yeoman + GruntJS working together.38 votes
We’ve added a new AngularJS optimized Single Page template with integrated npm and Gulp support at: https://github.com/ServiceStack/ServiceStackVS/blob/master/docs/angular-spa.md
Add optional Strong-named Server and Client NuGet packages so they can be added in the GAC and used inside Enterprise products requiring signed dlls.12 votes
An option would be to open the access to Routes.
This would allow to separate the concerns of application workflow in services (describing next operations if required) from route resolution (which could be done in a filter or in the appconfig).13 votes
Change NuGet packages so they map 1:1 with ServiceStack projects. So 'Install-Package ServiceStack' doesn't bring in OrmLite and Redis automatically, and we can 'Install-Package ServiceStack.Interfaces' to bring in the minimum dependencies DTO's need.20 votes
The NuGet packages have been refactored in v4 which has the following deps:
Support to use @helper not only to call functions in an external assembly (which I think is already supported by SS), but also to call helper functions inside very the same .cshtml template like describied in this link:http://stackoverflow.com/questions/6531983/how-to-create-a-function-in-a-cshtml-template5 votes
Apologies for the delayed notification, this was added over a year ago, here’s an example: https://github.com/ServiceStack/ServiceStack/blob/master/tests/RazorRockstars.Web/Helper.cshtml
Much of the existing code implements IHttpRequest and IHttpResponse interfaces and writes complete code for implementing these. That was necessary before the redesign in 4.5 implemented mockable versions of the non-inheritable old HttpResponse classes.
I think it can reduce the amount of code in SS and enable use to not need to use global items like HttpContext.Current.Request which results in - non-testable controllers.
The change to help the above situation I implemented grew out of scope, but thought it worthwhile to explore for a later version.1 vote
ServiceStack’s ASP.NET wrapper classes now depend on HttpContextBase, HttpRequestBase and HttpResponseBase.
Details on latest v4 update:
One of the most enticing aspects about ServiceStack is that it is incredibly fast. I suggest that all major aspects of SS (web services, text, ormlite) get thoroughly tested in the upcoming versions just to make sure the code base is as fast as it could be.3 votes
v4.5.6 was a perf-focused release: http://docs.servicestack.net/releases/v4.5.6#performance-improvements
The benchmarks framework used to measure ServiceStack performance is at: https://github.com/NetCoreApps/Benchmarking
Potential speed increase for the Xamarin.iOS and Xamarin.Android ServiceStack clients? See here: https://github.com/paulcbetts/ModernHttpClient3 votes
Now supported with the new HttpClient-based JsonHttpClient in v4.0.42: https://github.com/ServiceStack/ServiceStack/blob/master/docs/2015/release-notes.md#new-jsonhttpclient
Instead of sharing binary dlls with client projects, provide the option for being able to generate DTO's on the client using metadata from a remote ServiceStack instance. The result to be equivalent to sharing the binary DTO dll on the client, where you can continue to use them with generic .NET Service Clients.
Add ServiceStack Reference was added in v4.0.30 which is available in ServiceStackVS VS.NET extension, full docs for this feature is at:
"In the case where you define your DTOs in a portable class library, you won't be able to use IReturn or the NewApi. Perhaps IReturn should be defined in a PCL in ServiceStack. Just a thought."8 votes
PCL Support was added in v4.06, example project at: https://github.com/ServiceStack/Hello
Upgrade all projects to .NET 4.0 and change Async APIs on the Service Clients to use .NET 4.0's Task/Future so it can work with C#'s await/async38 votes
All Async ServiceClient API’s now return Task with all tests passing.
- Don't see your idea?