Don't hard-code endpoint URL, allow to provide that form web.config

[trailmax]

Is there a way to provide endpoint URL from app.config (or other config method) rather than hard-coding the value?

Here is the scenario: I'm developing API and a client for that API. API will be deployed to Azure API Apps, Client will be a WebApp (MVC application). I would like to be able to run both API and a client locally for development phase. Not a problem, I run API locally, point code generator to the local endpoint, get the models created for me - bang! Then I publish API to Azure, I need to update the URL in the generated code on the client. But if I forget to change the endpoint URL on the client, I get into trouble for using http://localhost:5555 when the client app is deployed in Azure. So it would be good if I could specify a way to store the endpoint URL in web.config and on publish stage I could overwrite it for the real endpoint.

I can always change the URL myself and take it from web.config, but it'll be overwritten on the next code generation...

[matt-gibbs]

The generated client constructor takes a baseUri parameter to override the value used during code generation. You could use ConfigurationManager to have different values for development and production.

[pnemere]

This is not an acceptable answer.

Yes, you can call the constructor, but if you have a pile of microservices, what ensures they are all calling the version of client constructors that takes a baseuri?? Let me tell you - nothing! Either provide a parameter to the code generator to not generate the parameter-less constructor... so you're forced to provide a baseuri OR make it always take a string which is the name of the AppSetting required to read the baseuri from ConfigurationManager always.

There is simply no point in providing parameterless constructor with a hard-coded uri as you generate now, except in the absolute most trivial "hello world" tutorial cases. Realistically people will always be deploying these in multiple situations, locally, multiple azure accounts, etc...

[devigned]

@pnemere would you consider making the constructors internal via the internalConstructors = true generator setting (see: https://github.com/Azure/autorest/blob/master/Documentation/swagger-extensions.md#x-ms-code-generation-settings)? I believe that would help you with your issue of exposing public parameterized constructors that don't fit the way you'd like to instantiate the client.

[devigned]

Also, @pnemere if the internalConstructors option is not sufficient, please submit a pull request for the functionality and we'll gladly review the change set.

[pnemere]

@devigned Thanks for getting back to me! I'm assuming this the same REST client generator that is included in the Azure install for Visual Studio? It was previously named "Add API App Client" or similar, but is now "REST API client"... is it possible to specify parameters to it as you suggested?

[devigned]

@pnemere, anytime. Working with developers using our software is the best part of the job! Depending on the version of AutoRest, you can add code generator setting as an x-ms-code-generation-setting into your swagger file. It's an extension that AutoRest will recognize and use as command line'ish settings.

@bradygaster, what version of AutoRest is currently shipping in VS? Also, I don't think we have a way to specify the input parameters to AutoRest via VS as of yet, please confirm or deny.

[bradygaster-zz]

@devigned we're shipping the .9 version. Will be updating once we can get some help to change the contracts to match your new signatures.

[devigned]

@pnemere VS doesn't support the code generator extension as of yet. I'd recommend using the latest release of AutoRest.

@sphibbs we should work with @bradygaster and @mlorbetske to update the VS support for AutoRest.

[pnemere]

Thanks for all the answers, good to see this new OSS side of MS is buzzing and helpful :)

So I've switched my project to use autorest directly, lots of differences relating to DateTime (the original "API App Client" generator generated string types for some of my calls)... new one seems to prefer DateTime. I don't like the fact that they're just raw DateTimes, I think DateTimeOffset would be a better choice.

I'll try the extension settings next. It's actually a lot more fluid to use autorest and set it up as part of the build, than to use the visual studio menu option for generating... it wasn't clear to me initially that there was the option to use autorest, and that it's on github - I wonder if it would make sense to point this out to users somehow, so they know of all the new OSS options to fine tune the tools that come packaged into visual studio?

[devigned]

I think DateTimeOffset would be a better choice

Please create an issue and request the enhancement. It sounds like a good idea and one I'd like to get the rest of the team's feedback on.

I'll try the extension settings next. It's actually a lot more fluid to use autorest and set it up as part of the build, than to use the visual studio menu option for generating...

@bradygaster and @mlorbetske, any thoughts on this?

[stankovski]

You can pass -useDateTimeOffset flag to AutoRest.exe or even specify it in x-ms-code-generation-setting extension.