Best way to manage multiple client endpoint configurations (IP address, etc.) In app.config

Question

Best way to manage multiple client endpoint configurations (IP address, etc.) In app.config

We are developing a system in which the client application is a .NET client interacting with the server using web services. We should be able to deploy a client with various configuration options, for example. IP address etc. So far, we have succeeded, mainly commenting / not commenting on various configurations in app.config, for example:

<!--<client> <endpoint address="https://localhost/services/service1" binding="customBinding" bindingConfiguration="ServiceSoapBinding" contract="ServiceReference.Service1" name="ServiceImplPort" /> <endpoint address="https://localhost/services/service2" binding="customBinding" bindingConfiguration="ServiceSoapBinding" contract="ServiceReference.Service2" name="ServiceImplPort" /> ... .. </client>--> <client> <endpoint address="https://prod.example.com/services/service1" binding="customBinding" bindingConfiguration="ServiceSoapBinding" contract="ServiceReference.Service1" name="ServiceImplPort" /> <endpoint address="https://prod.example.com/services/service2" binding="customBinding" bindingConfiguration="ServiceSoapBinding" contract="ServiceReference.Service2" name="ServiceImplPort" /> ... .. </client>

But it seems obvious that this is not the best solution to the problem, it becomes a little unmanageable as the number of configuration alternatives grows. Any suggestions for improving this are welcome.

Regards, Ola

+4

.net web-services

Ola theander Jun 07 '12 at 12:00

source share

3 answers

We are very pleased with the use of the MSI package to deploy our applications (built using WiX) and the custom action that invokes the XMLPreprocess executable that we pack with our product. It mainly uses XPath and some of the XML files that we support with Excel to handle the reconfigured app / web.config files. We used it for a long time and did not experience any problems with the product.

Here's the link: http://xmlpreprocess.codeplex.com/

It would be helpful if you developed a deployment strategy to give specific answers to your situation.

Edit: maybe I should add that this is only for the internal product, you would not want to use this approach if you were issuing MSI from the outside.

+1

Jeff winn Jun 07 '12 at 16:52

source share

We tried using a wal approach that almost solved the problem, but we ran into problems with a one-click deployment, see my comment on wal's answer.

We are currently using the conditional compilation proposed in this publication:

http://www.codeproject.com/Articles/451734/Visual-Studio-Use-Conditional-Compilation-to-Contr

The advantage is that in addition to working flawlessly with a click once, you do not need to configure the VS project file or use third-party components. The downside is that you need to update the source code if you want to add / change the endpoint.

We did to add a new .setttings file to the project. This is not necessary, but we, although it was a good idea to save the endpoint configuration in a separate settings file, as this file should be slightly modified. It is configured to use conditional compilation to enable the correct endpoint based on the configuration included for compilation:

  public ServiceSettings() { // // To add event handlers for saving and changing settings, uncomment the lines below: // // this.SettingChanging += this.SettingChangingEventHandler; // // this.SettingsSaving += this.SettingsSavingEventHandler; // // Each method corrsponds to a build version. We call all four methods, because // the conditional compilation will only compile the one indicated: this.SetLocalApplicationSettings(); this.SetAS12ApplicationSettings(); } [Conditional("LOCAL")] private void SetLocalApplicationSettings() { this["LoginAddress"] = "https://localhost/services/loginservice"; this["SettingsAddress"] = "https://localhost/services/settingsservice"; } [Conditional("EXAMPLE")] private void SetAS12ApplicationSettings() { this["LoginAddress"] = "https://example.com/services/loginservice"; this["SettingsAddress"] = "https://example.com/services/settingsservice"; }

In VS, we created one configuration per endpoint and determined the correct conditional compilation symbol in the Build tab, i.e. LOCAL or EXAMPLE.

We also updated the code using the WS client classes created by VS to use the endpoint defined in the settings file:

 var client = new SettingsServiceClient("SettingsServiceImplPort", ServiceSettings.Default.SettingsAddress);

In app.config, we just saved the default configuration (localhost) and the binding configuration to keep VS happy:

 <system.serviceModel> <bindings> <customBinding> <binding name="SettingsServiceImplServiceSoapBinding"> <textMessageEncoding messageVersion="Soap12" /> <httpsTransport /> </binding> <binding name="LoginServiceImplServiceSoapBinding"> <textMessageEncoding messageVersion="Soap12" /> <httpsTransport /> </binding> </customBinding> </bindings> <client> <endpoint address="https://localhost/services/settingsservice" binding="customBinding" bindingConfiguration="SettingsServiceImplServiceSoapBinding" contract="SettingsServiceReference.SettingsService" name="SettingsServiceImplPort" /> <endpoint address="https://localhost/services/loginservice" binding="customBinding" bindingConfiguration="LoginServiceImplServiceSoapBinding" contract="LoginServiceReference.LoginService" name="LoginServiceImplPort" /> </client> </system.serviceModel> <applicationSettings> <ConfigurationTest.ServiceSettings> <setting name="SettingsAddress" serializeAs="String"> <value>https://localhost/services/settingsservice</value> </setting> <setting name="LoginAddress" serializeAs="String"> <value>https://localhost/services/loginservice</value> </setting> </ConfigurationTest.ServiceSettings> </applicationSettings>