Moving data and logic classes to new assembly causes `ServiceStackHost.Instance has already been set`

ServiceStack
1

We’re having a weird problem with ServiceStack, and we cannot really comprehend what’s going on.

The error I’m going to describe only happens on Mono, not on Dotnet. We tested on Mono 4.2.1, Mono 4.2.2 and Debian 7, and we’re using ServiceStack 4.0.50. We’re also using Hyperfastcgi in the lastet version. Haven’t tested with the mono fastcgi server as Hyperfastcgi was quite reliable in the past.

###Description
We’re in the process of refactoring our single assembly servicestack project into multiple assemblies.

We want to move several classes to a shared project. Those classes include simple POCOs and also business logic which is talking to AWS services like DynamoDB.

The newly created shared lib has references to another already existing shared lib, and also to AWS and to Servistack related assemblies.

So, as soon as we deploy the project setup, which includes the newly created lib, to the server, we’re experiencing the exception ServiceStackHost.Instance has already been set upon load.

See https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/ServiceStackHost.cs#L138.

The stacktrace of the exception page looks like this, which is not very telling:

System.IO.InvalidDataException
ServiceStackHost.Instance has already been set

Description: HTTP 500.Error processing request.
Details: Non-web exception. Exception origin (name of application or object): ServiceStack.
Exception stack trace:

 at ServiceStack.ServiceStackHost.Init () <0x41c2a2c0 + 0x003b3> in <filename unknown>:0 
  at XServer.Global.InitAppHost () <0x41bc9700 + 0x0009b> in <filename unknown>:0 
  at XServer.Global.Application_Start (System.Object sender, System.EventArgs e) <0x41b824e0 + 0x00113> in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x41a40ec0 + 0x000b7> in <filename unknown>:0

We did not change or add any code or logic, we just moved the classes into a new project and added the new dependency to the base project where the apphost resides in. It’s compiling and working fine with Visual Studio on Windows.

We do not have any Servicestack web services in the new library project, nor do we have (at least as far I can see) any attributes generating code like with the webactivator.

We also do not have ServiceStack.Host.Mvc installed and thus no App_Start/ServiceStackFramework.cs as described here http://stackoverflow.com/questions/8954622/service-stack-mvc-apphostbase-instance-has-already-been-set-error-but-cant (if that’s still valid. I also checked other stackoverflow questions and answers but didn’t find anything that seems apply to our setup).

To debug, I created a class derived from AppHostBase to track it’s constructor calls, and if there are more than one, to output the StackTrace.
Basically each StackTrace looks like if Global.asax' Application_Start method is called for the first time, out of Hyperfastcgi.

###Assumption
So, at second glance, it does not necessarily look like a Servicestack issue itself. Yet all we did was moving classes to another assembly, so maybe there’s some ServiceStack magic involved nevertheless.

Does anyone has a clue what’s going on here?
Do you need more information from me to be able to help me tracking this down?

###Help! :slight_smile:
Thanks,
Andreas

2

This error:

ServiceStackHost.Instance has already been set

Happens when you try to initialize the AppHost multiple times within the same AppDomain, i.e:

new AppHost().Init();
new AppHost().Init();

The shouldn’t happen as the AppHost should only be initialized once on App Startup.

This can happen in Unit tests if you forget to dispose the AppHost,e .g:

private ServiceStackHost appHost;

[TestFixtureSetUp]
public void TestFixtureSetUp() {
    appHost = new AppHost().Init();
}

[TestFixtureTearDown]
public void TestFixtureTearDown() {
    //appHost.Dispose(); //required
}

If you don’t dispose the AppHost the next test fixture that starts an AppHost will fail with this error (since tests are run within the same AppDomain).

As this shouldn’t happen, my recommendation is to focus and add debugging/logging around AppHost().Init().

3

I am experiencing this when running two services from a single test harness. (During development only, the services are deployed independently in production).

Is there any way I can get around this without having to implement a test harness per service? I have many so that would not be practical. e.g. can I create an artificial app domain for each service to run in?

4

There can only be a single AppHost Instance initialized at any one time, you will get an error if you try to initialize another AppHost whilst a prior instance hasn’t been disposed. Our Integration Tests show how to setup a Test Fixture that creates and disposes of a AppHost after each fixture is run.

An alternative option is creating a consolidated AppHost for development combining the Services in multiple Assemblies. Otherwise I’d personally be running them in separate processes (e.g. using Process.Start()), but running them in different App Domains should also work.