Jezz Santos - 275 - May 7, 2014

ServiceStack Swagger
1

I am having trouble using swagger. I have followed the instructions here https://github.com/ServiceStack/ServiceStack/wiki/Swagger-API to the letter. I am installing teh 4.0.15 version of the NuGet

My services and work fine at: https://127.0.0.1:4431/api
I can see the SS metadata page at https://127.0.0.1:4431/api/metadata
I can see the swagger console at https://127.0.0.1:4431/swagger-ui/index.html, and my services are summarized on this page.

My problem is that none of the links on the swagger summary page work at all (e.g. 'Show/Hide or ‘List Operations’ or ‘Expand operations’) except the ‘Raw’ link which does work. Clicking them does nothing.

The other wierd thing I see, is at the bottom of the summary page it says:
[ base url: https://127.0.0.1:4434/api ]
which is clearly a different port than the page itself!!!

I am hosting the services in IISExpress in the Azure emulator, and I know the emulator does funny stuff with ports.

Any ideas what might be going on here?

2

Did you click on the Swagger link on the metadata page? e.g. 
https://127.0.0.1:4431/api/swagger-ui/

3

If Azure is proxying through different ports you may need to explicitly set Config.WebHostUrl

4

Jezz Santos:

yep, did click the link on the metadata page. Get same result in swagger.
Ill explore the Config.WebHostUrl thing

5

Also what does ?debug=requestinfo show? 
Needs to be in DebugMode, see:
https://github.com/ServiceStack/ServiceStack/wiki/Debugging#request-info

6

Jezz Santos:

So, just discovered that the problem occurs only in the Azure emulator on the desktop. It does not occur once deployed to Azure staging environment, which smells like the emulator doing some port magic. Just not sure how to prevent that!!

?debug=requestinfo shows me the 4434 port not the 4431 port

7

Jezz Santos:

+Demis Bellot I tried to set Config.WebHostUrl hardcoded (https://127.0.0.1:4431/api) and that fixes the problem in desktop emulation mode.
I never had the problem in the Azure hosted environment (staging or prod). I don’t want this setting in those deployments, I think can manage that with Azure magic.

So now, if that is the fix for desktop mode only, Can I derive my WebHostUrl in some way in AppHost.Configure() instead of hardcoding all of it? 

8

You can’t infer the HTTP Request information outside the context of a HTTP Request which is only available at runtime (i.e. not on App_Start)

But there are several options for loading different configuration for different environments, there’s a tier option in AppSettings:
https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md#appsettings-1

You can read from an Environment variable for that OS:

SetConfig(new HostConfig {
    WebHostUrl = Environment.GetEnvironmentVariable(“WebHostUrl”)
});

You can use TextFileSettings to read from appSettings in an external file:
https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md#extract-key–value-settings-from-text-file
And then not deploy this text file with the App so the live environments fallback to the default behavior

9

Jezz Santos:

thanks, used the RoleEnvironment.IsEmulated flag to differentiate desktop Emulator from Azure hosted enviro. Then read the URL from CloudConfigurationManager settings to avoid hardcoding.