I am building my ServiceStack 4.0.8 service using Visual Studio. On Windows everything works perfectly, but when I try to run on Mono 2.10.8.1 / Ubuntu 13.10 with NGINX 1.4.1 and fastcgi-server4.

I get an exception:

The requested feature is not implemented. at System.Web.HttpContextWrapper.GetService (System.Type serviceType) [0x00000] in :0 at ServiceStack.Host.RequestPreferences.GetWorker (System.Web.HttpContextBase context) [0x00000] in :0 at ServiceStack.Host.RequestPreferences.get_HttpWorkerRequest () [0x00000] in :0 at ServiceStack.Host.RequestPreferences.get_AcceptEncoding () [0x00000] in :0 at ServiceStack.Host.RequestPreferences.get_AcceptsDeflate () [0x00000] in :0 at ServiceStack.RequestExtensions.GetCompressionType (IRequest request) [0x00000] in :0 at ServiceStack.RequestExtensions.ToOptimizedResult[List1] (IRequest request, System.Collections.Generic.List1 dto) [0x00000] in :0 at Phase1HistoryServer.SymbolsService.Get (Phase1HistoryServer.Symbols request) [0x00000] in :0

If I return the DTO object directly I do not get errors. However if I use base.Request.ToOptimizedResult the exception occurs.

List<DataItem> data = new List<DataItem>(); 
data.Add(new dataItem { Data = "fake data" });
return base.Request.ToOptimizedResult<List<DataItem>>(data);

Update:

A commit to ServiceStack has been made, and version 4.0.16+ should no longer suffer from this exception.

ToOptimizedResult() works, this is not a shortcoming of ServiceStack but rather with Mono and fastcgi-server-4. There is a suitable workaround.

Mono incomplete, doesn't implement `System.Web.HttpContextWrapper.GetService`:

This exception is thrown because the Mono project have not yet implemented this method. As Mono is an OpenSource project they have to recreate the .NET specification themselves, and this method simply isn't done.

See here for the relevant Mono source code:

public class HttpContextWrapper : HttpContextBase
{
    ...

    [MonoTODO]
    public override object GetService (Type serviceType)
    {
        throw new NotImplementedException ();
    }
}

Mono solution, use a Self Hosted Application:

I run ServiceStack on Mono (albeit v3.2.6) and don't have any problem using ToOptimizedResult but I don't use fastcgi-server4, which will relies on System.Web.HttpContextWrapper.

Instead I use a self hosted ServiceStack application, which is based on a pool of underlying System.Net.HttpListener, which doesn't seem to be affected by the same issue. And thus works well.

Demo App:

Below is code for a working self-hosted ServiceStack application, using your test code:

using System;
using ServiceStack;
using System.Collections.Generic;

namespace Testv4
{
    class MainClass
    {
        public static void Main()
        {
            // Very basic console host
            var appHost = new AppHost(500);
            appHost.Init();
            appHost.Start("http://*:8082/");
            Console.ReadKey();
        }
    }

    public class AppHost : AppHostHttpListenerPoolBase
    {
        public AppHost(int poolSize) : base("Test Service", poolSize, typeof(TestApp).Assembly) {}

        public override void Configure(Funq.Container container)
        {
        }
    }

    public static class TestApp
    {
        public class DataItem
        {
            public string Data { get; set; }
        }

        [Route("/Test", "GET")]
        public class TestRequest {}

        public class TestController : Service
        {
            public object Get(TestRequest request)
            {
                var list = new List<DataItem> {
                    new DataItem { Data = "Fake Data" }
                };

                return base.Request.ToOptimizedResult(list);
            }
        }
    }
}

You can test the application by going to localhost:8082/Test. It shouldn't throw an exception when compressing the result.

Self Hosted App Usability:

My suggestion would be to either forward requests from NGINX using it's transparent proxying abilities onto the ServiceStack application, or simply cut out NGINX and have request go directly to the application.

The AppHostHttpListenerPoolBase works well and I have had no issue using it in production environments.