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.
Related
We converted our projects to the 'new' SDk format csproj files. To add a new WCF webservice we right-click the project and choose: Add => Connected Service. Then we choose 'Microsoft WCF Web Service Reference Provider'. That all works, but the generated code does not contain an option to pass an endpoint name to the service-client constructor (which was an option in the older csproj add service reference option) so it would do a lookup in the web.config-file to configure the service (endpoint and behaviours e.d).
It looks configuration is all hardcoded in the generated service code file (servicereference.cs). I know it's a partial class and could just add an extra constructor accepting an endpoint name as a string like ctor(string enpointname):base(endpointname){} but i'm lazy and believe it should be able to work out of the box.
I think the question (and comments) contains the answer already. The only way to use the Config-file is to add a constructor in partial class in a new file.
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.
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.
I have a scenario in which I'm going to need an arbitrary number of servers to provide the same SOAP web service. I would like to generate one set of proxy classes and be able to supply them with a location to point them at the different servers at runtime. Unfortunately, it looks as though the wsdl:port node (child of wsdl:service) requires the address of a specific server to be hardcoded. It appears that due to this the URL will be baked into my proxy classes. I know that I could potentially modify this by hand-editing the generated proxy classes, or modifying the code generation, but I'd really prefer not to resort to that. I feel like there's got to be a better way to solve this problem. I just want to decouple the interface definition from the location that the service will be residing at. I'm using VS2008 and C#.NET if that's of any help though best would be a language-agnostic (SOAP or WSDL specific) general solution to this problem.
Why don't you load balance the web servers and then create a DNS entry for the load balanced IP address....essentially creating a web farm. This will allow you to reference the hostname rather than the static IP addresses and if you ever need to change the IP address of the load balancer or the web servers it is a one time change. Plus you then have redundancy and performance control.
If you're using a WebReference (pre-WCF) to get to the web service, you can simply set the Url property on the web service proxy class after you create it.
For WCF, you can provide a different endpoint address to the proxy class constructor, rather than using the default (among other possible solutions).
No, in .NET you can change the URL at runtime.
Service svc = new Service ();
svc.url = "Value read from config. file or some such"
output = svc.method (input);
When you add a web reference to your project, it places the address of the web service into the .config file of your application / web application. You can then simply change this setting in the config file to point to a different web service location, assuming of course that the services are identical.
The easiest solution would be to use a software load balancer such as HAProxy. At more cost, you could use a hardware solution such as Big-IP.
Here's a hint on how to decide the URL of WSDL. I´m just changing the port but it´s of course possible to make it more advanced.
public class PortChangeReflector : SoapExtensionReflector
{
public override void ReflectDescription()
{
ServiceDescription description = ReflectionContext.ServiceDescription;
foreach (Service service in description.Services)
{
foreach (Port port in service.Ports)
{
foreach (ServiceDescriptionFormatExtension extension in port.Extensions)
{
SoapAddressBinding binding = extension as SoapAddressBinding;
if (binding != null && !binding.Location.Contains("8092"))
{
binding.Location = binding.Location.Replace("92", "8092");
}
}
}
}
}
}
Put that in your Add_Code and add the following reference to your web.config.
<webServices>
<soapExtensionReflectorTypes>
<add type="Dev.PortChangeReflector,App_Code"/>
</soapExtensionReflectorTypes>
</webServices>
I hope you can get new ideas of this.
Client proxies have URL property you can set at runtime. To make it simpler, wsdl.exe utility has /appsettingurlkey key. When you generate a client proxy, it's constructor will check the key in appSettings and set the service URL accordingly. I believe WCF has this feature as well.
However, I would agree with #Matt and suggest you consider load balancing as the best solution in the long run.
Is this for scaling (each server provides the same data) or
for same API different data on each server?
For 2, then you can do as above, just change the service URL in code.
For 1, you could use round-robin DNS (e.g. you see multiple servers with at the command line type nslookup www.google.com).
I have numerous Web Services in my project that share types.
For simplicity I will demonstrate with two Web Services.
WebService1 at http://MyServer/WebService.asmx
webService2 at http://MyServer/WebService.asmx
When I generate the proxy for these two services I use:
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx
/appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs
The problem is that the appsettingurlkey is the same for each Web Service
in the proxy file. I want to be able to specify multiple
appsettingurlkey parameters. How is this accomplished? I figure
since the /sharetypes parameter became available, there should be a
solution for specifying the appsettingurlkey specifically for each
Web Service identified.
If this is not possible with the wsdl.exe, what would you propose I do? I would rather not update the generated code that wsdl.exe outputs and I don't want to go through my whole application passing in the Url to each instance of the Web Services.
The proxy classes generated are partial classes, so my solution would be to add your own constructor in a different (non-generated) code file, which explicitly reads a different setting for each proxy.
To suplement Elijah's own answer, here's the email answer I gave him.
I had to blog it because the XML didn't paste well into this text box: http://www.rickdoes.net/blog/archive/2008/09/29/wsdl-shared-types-and-configuration.aspx
Ahh, instead of creating another partial class with an overloaded constructor passing in the Url, the following additional parameters to the wsdl.exe will solve my problem...
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx /appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs /appsettingurlkey:BaseSoapUrl /appsettingbaseurl:http://MyServer/
If the web.config has a BaseSoapUrl appSetting, then it will use that to replace the http://MyServer/ sub string from the MyProxy.cs. If the appSetting is not present, then it will just use the path provided in the wsdl.exe (example: {BaseSoapUrl}/WebService1.asmx when using the appSetting or http://MyServer/WebService1.asmx when not using the appSetting).
A thanks goes out to Rick Kierner for pointing me in the right direction.