Servicestack-client update will set BaseUrl empty

Clients Add ServiceStack Reference
1

if update the file, if the BaseUrl is http://127.0.0.1:5004 or http://localhost:5004 it will set the BaseUrl to empty , if the BaseUrl is a domain url , it will retain
I have tried used the servicestackVS(version:1.0.36) and servicestack-client (version:0.0.38), all get the wrong, is it a bug?

/* Options:
Date: 2017-07-15 10:45:51
Version: 4.513
Tip: To override a DTO option, remove "//" prefix before updating
BaseUrl: http://127.0.0.1:5004

GlobalNamespace: Entities
//MakePartial: True
//MakeVirtual: True
//MakeInternal: False
//MakeDataContractsExtensible: False
//AddReturnMarker: True
AddDescriptionAsComments: True
//AddDataContractAttributes: False
//AddIndexesToDataMembers: False
//AddGeneratedCodeAttributes: False
//AddResponseStatus: False
//AddImplicitVersion: 
//InitializeCollections: True
//ExportValueTypes: False
//IncludeTypes: 
//ExcludeTypes: 
//AddNamespaces: 
//AddDefaultXmlNamespace: http://schemas.servicestack.net/types
*/
2

I don’t understand exactly what you’re asking but I’ll state the importance of BaseUrl as it relates to the native types feature:

First read the overview on how Add ServiceStack Reference works to understand how Native Types are generated, basically the significance of BaseUrl is to tell the ServiceStack “DTO downloaders” (i.e. ServiceStackVS VS.NET Extension or servicestack-cli which fetches the latest dtos) where to download the DTOs from. Where all it’s really doing is appending /types/{language} to the base url to download the generated DTOs. With that said the Native Types Feature is more dependent on the ServiceStack Version of the remote Server which does the actual DTO generation, than it is the version of ServiceStackVS. So for example if an issue with the Native Types Feature is resolved, the remote ServiceStack Server needs to be updated in order to gain the fix, it’s not dependent on the version of ServiceStackVS.

Unlike all other variables, BaseUrl does not customize ServiceStack Native Types feature’s behavior, it’s only purpose is to specify where to fetch the generated DTOs from. After it successfully fetches the DTOs what BaseUrl returns is what the Server believes its BaseUrl to be, which is normally inferred but can be customized by specifying Config.WebHostUrl or by overriding GetBaseUrl() in your AppHost.

So there can be no bug with BaseUrl, its purpose is to specify where to download the generated DTOs from and if it’s valid it will return the generated DTOs with the BaseUrl that the remote server believes it has. Now there can be an issue with BaseUrl inference, which there was for IIS Virtual Hosts in the latest v4.5.12 release which has been since been resolved in the latest v4.5.13 Release that’s on MyGet.

3

You are right, I changed the WebHostUrl to empty. I have fixed it , thanks!