I have WCF Client initialized like this
MyServiceClient client = new MyServiceClient();
so it uses the app.config to read the endPoints.
I would like to dynamically change the default config file to a file I define.
I know I can open a configuration file like this:
Configuration myConfig = ConfigurationManager.OpenExeConfiguration
but how can I set myConfig to replace the default configuration?
Check out this article here: Read WCF Configuration from a Custom Location.
It basically involves creating a custom ServiceHost that will read the configuration from a different file which you can specify, rather than from web.config or app.config.
Here's another excellent article on using custom config files for WCF services hosted in IIS:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/22/custom-service-config-file-for-a-wcf-service-hosted-in-iis.aspx
Marc
I've seen something similar done by just reading values out of a custom config file (that was just opened and read with a standard XML parser). Then the values were plugged into the WCF configuration entries programmatically.
This was done because multiple projects in the same solution all read their WCF configuration entries out of the same file. I'm not sure why they went with that architecture, but in the end it worked just fine.
Related
I have next scenario:
One Class Library (For example called Utilities) using one app.config
One General Site Web application using web.config and applications with web.config each one.
I need to insert an appsettings called "XXX". obviouslly should set in the Site web.config.
The Utilities library is called in all application that I have inside the Site, then I should set the appsettings key in each web.config (something confusing).
How can I set the key inside app.config and read it? ConfigurationManager only read from Web.Config and I would like to read app.config keys inside Utilites.
Is it possible?
Hi I found the solution:
if yu want to get the properties of app.config you can use:
var value = Properties.Settings.Default.keyName
We use WCF client in our project which is an Azure functions app, to communicate with an external web service. We need to change the xmlSerializer's tempFilesLocation because of the permission issue. I searched online and found the following configuration that we can use in our web.config which will solve the problem.
<system.xml.serialization>
<xmlSerializer tempFilesLocation="an absolute path of your choice"/>
</system.xml.serialization>
But in Azure Functions app, we don't have access to web.config, so we need to find a way to do it in the code. Is there any way to change tempFilesLocation in the code?
It's not possible to modify the web.config for functions running on the dynamic sku (where you pay-per-invocation).
However, if you create your function on the non-dynamic/classic sku (where you pay per vm, the pricing model for regular web apps) then you can modify the web.config settings via an applicationHost.xdt file. More details on how to work with xdt file here: https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples
Scenario:
I am consuming a web service in my class library project and it generates a binding name and end point in app.config. If I reference the class library in my UI project, I also have to include the same configuration in web.config. My problem is I don't want to include this configuration in web.config because of the dependency. I want to use assembly as it own with out any dependency.
My solution approach:
When I create the instance of proxy class in the class library project it shows me constructor to pass binding and endpoint.
Example
wsProxy proxyClass = new wsProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.Endpoint endpoint)
I was wondering if I can pass the same binding and endpoint that I have in app.config so that I don't have to include either in app.config and web.config.
Yes, you can create these classes without having matching configuration in the main .config file. Where you get that configuration is up to you; it could be App.config, a YML configuration file, a database, etc. As long as your code satisfies the constructor requirements for the classes you're instantiating, you'll be fine.
With WCF, everything defined in your configuration file can be done programmatically.
You just need to create the objects needed to instantiate your client. Depending on the WCF features you want your application to be leveraging, you'll need classes like EndpointAddress, AddressHeaderCollection, Uri, EndpointIdentity (DnsEndpointIdentity or SpnEndpointIdentity), Binding (WSHttpBinding, NetTcpBinding etc.). And you might want to have these objects populated from a decoupled, centralized configuration store such as a database.
I have a project that has a web service reference. I also have an app.config file that contains the binding information and endpoint. In one of my classes I'm invoking the the soap client object generated by the web service reference. I can initialize the soap client object to one of the endpoint I created in the app.config file. My confusion is with the constructor that takes in two strings. One is for the endpoint name in the app.config file and the other is the remote address. Why would I want to provide a remote address when I could just specifie it in the app.config file under the endpoint element?
And what if you'd like this address to be dynamic?
You surely DO wish to have an constructor taking the remote address as a parameter rather than sticking only with a static configuration.
The constructor which takes both the binding and the endpoint address gives you most flexibility. We often delete the static configuration from the configuration files and create the proxy instances using this particular, two-argument constructor.
This way, it's easiest to dynamically relocate your application without the need to touch anything.
It's an overload if you for some reason don't want to specify your configuration in the app.config file, it could be that you are storing it in a database or some other configuration mechanism.
it looks like I am not able to succesfully move my WCF proxy code into a separate DLL (as opposed to an EXE as I can see in all the examples I have run into).
The reason I am trying to do this is that I would like my proxy code to be invoked by different clients (possibly unmanaged code), which might not know anything about WCF but just need to access to the services (through a Facade exposed by the proxy maybe?).
Whenever I move the following code that creates a new proxy to a different VS project within the same solution, I get the dreaded "Could not find default endpoint element that references contract 'localhost.IRemoteCommandService' in the ServiceModel client configuration section" exception.
localhost.RemoteCommandServiceClient proxy =
new localhost.RemoteCommandServiceClient();
The same code works smoothly whenever used within a Main method in the same project where the proxy code is (auto-generated from Visual Studio).
Any idea? I hope that the client code of my proxy does not need to have the service model XML configuration as the proxy, because that would defeat the purpose I am moving the WCF proxy code into a DLL in the first place.
Thanks,
Stefano
The endpoints are indeed normally specified in the configuration file. You must look at the serviceModel data in the config file, and copy it into your calling app.config - or you need to use the more verbose way of creating the proxies in your code (i.e. specifying the address, binding, configuration etc through code to the constructors).
If you don't want to have to endpoint configuration on the client, you'll have to embed it into your proxy dll by specifying everything in code.
Another option would be to use a dynamic proxy, like this one, which would allow you to not have the serviceModel in your client apps.