So, I just updated all projects references to SS v4 via NuGet. Lets just say it didn’t go as expected - there’s not much that compiles now. Is there some information available on what has changed between the v3 and v4? Also, where has the EndpointHostConfig gone to?
Per Malmberg:
Also, Is the extension method SerializeAsJSON() a direct replacement for ToJson() ?
Please see the release notes as to what’s changed, you should be able to search the text of classes to see what they’ve been renamed to:
https://github.com/ServiceStack/ServiceStack/wiki/Release-Notes
ToJson() still exists, like most extension methods they’ve been moved to the base ‘ServiceStack’ namespace.
Per Malmberg:
Ah, there it is 
Everything compiles now, just need to test it all. Quite a few changes in v4, all to the good it seems
Per Malmberg:
About licensing; my (stand alone) application is built in a very modular way where services are loaded based on the configuration. Multiple of these services uses SS, is it then sufficient to call Licensing.RegisterLicense() once for the entire application, i.e. the ApplicationDomain, or is there something more required? Also, do you have any suggestion on how to protect the license in a stand alone application; including the license string in the .cs file makes it available to anyone who wants to extract it…obfuscation is unfortunately no guarantee it can’t be extracted.
You only need to call it once on App Startup, which applies to the entire AppDomain. There’s not much you can to obsfucate the key other than encrypt or encode it, so it’s not a simple, straight forward extraction.
Note: if they really wanted to steal it, they don’t need to extract a license key from a compiled program, they can just take the source code from the GitHub repo and compile ServiceStack themselves.
Per Malmberg:
You’re right about the licensing of course…problematic with Open Source and commercial interests.
Another question: In v3 I used a custom handler to catch calls to / in a an AppHost (inherited from AppHostHttpListenerBase) like so: CatchAllHandlers.Add( ( httpMethod, pathInfo, filePath ) => StaticFileHandler.Factory( …) ). The reason for a custom handler was to allow files added to the path {Config.WebHostPhysicalPath} to be found after the AppHost had started, thus removing the need to restarts.
I’ve adapted the handler to the new IHttpHandler interface and SS creates an instance on a http request to the service, but something fails and logs the following error message: “Error this.ProcessRequest(context): [AggregateException]: One or more errors occurred.” before the call to ProcessRequest(…) method in my custom handler.
Is there any way to get more info about the exception without compiling SS myself? I’ve redirected all logging via Logging.LogFactory already and SS logs via ErrorFormat( string format, params object[] args ), but neither of the args are Exceptions, they’re both strings.
If it’s an error in an IHttpHandler you may be able to intercept the exception by registering a handler in IAppHost.UncaughtExceptionHandlers
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/IAppHost.cs#L88
Let me know if that doesn’t work, as I’ll look at redirecting IHttpHandler exceptions to there as well if it’s possible.
Otherwise I’ll need to find the place that logs it and pass the exception instead of a string.
Per Malmberg:
Well, it seems to me the error happens before the call to my handler’s ProcessRequest() as my method never is executed (break point not halting the execution)
Nothing is reported via IAppHost.UncaughtExceptionHandlers. Can you please have a look at passing the exception instead of a string, as you suggested?
How did you register the handler?
Per Malmberg:
In the constructor of my AppHost: UncaughtExceptionHandlers.Add( new ServiceStack.Host.HandleUncaughtExceptionDelegate( UncaughtExeption ) ); Is there more than one way?
Sorry I meant registering the HttpHandler, are you registering it with IAppHost.RawHttpHandlers?
Per Malmberg:
Maybe you meant the IHttpHandler? Also in the constructor of the AppHost: CatchAllHandlers.Add( ( httpMethod, pathInfo, filePath ) => StaticFileHandler.Factory( … ) ); The Factory method returns an IHttpHandler or null if if it cannot find the requested file on disc.
Per Malmberg:
Just for the sake of it, I tried moving them to the AppHost.Configure() method, same result.
ok great it’s a catch all handler, i’ll investigate.
Per Malmberg:
If you want it, the code for the handler is here: https://dl.dropboxusercontent.com/u/9476016/StaticFileHandler.cs
ok cool, tho I was just going to throw an exception in ProcessHandler, I notice that you’re silently catching exceptions, have you tried logging them with:
private static ILog Log = LogManager.GetLogger(typeof(StaticFileHandler));
then in your exception handler:
} catch(Exception ex) {
Log.Error(ex.Message, ex);
}
Also were you able to find out where the exception is being thrown or what the StackTrace is?
Per Malmberg:
I’ve set breakpoints on those catches, but they are never hit. As I tried to explain above, the ProcessRequest() is never called in my handler. The only call to my code is done to the Factory method, after that the error is logged and nothing more is observable from my end. I was able to catch the logging of the exception but as I wrote above, in the call to ILog.ErrorFormat( string format, params object[] args ), neither of the args are Exceptions, they’re both strings.
I disabled “just my code” and now get this stacktrace:
> WebAPI.dll!BeyondMeasure.WebAPI.LoggerProxy.ErrorFormat(string format, object[] args) Line 67 C#
ServiceStack.dll!ServiceStack.Host.HttpListener.HttpListenerBase.HandleError(System.Exception ex, System.Net.HttpListenerContext context) + 0x161 bytes
ServiceStack.dll!ServiceStack.Host.HttpListener.HttpListenerBase.ListenerCallback.AnonymousMethod__0(System.Threading.Tasks.Task x) + 0x6c bytes
mscorlib.dll!System.Threading.Tasks.Task.Execute() + 0x6e bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes
mscorlib.dll!System.Threading.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task currentTaskSlot) + 0x2c5 bytes
mscorlib.dll!System.Threading.Tasks.Task.ExecuteEntry(bool bPreventDoubleExecution) + 0x85 bytes
mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x1ea bytes
ok cool, I’ve changed all error logging in HttpListenerBase to log the original exception (along with the message in) in: https://github.com/ServiceStack/ServiceStack/commit/0050cd06646d2086e4c899a06a5405328f4594b1
So you should be able to catch the exception with a custom logging adapter, available in the next version I’m hoping to push out within the next day or 2.
Per Malmberg:
Looking forward to it