Develop Reference

Increase timeout when consumed as web reference (not service reference)

There are lots of similar questions on StackOverflow. If this is a duplicate, I would appreciate a little explanation of how to apply other solution in my context please.
I have a project that is a WebAPI. This WebAPI in turn calls a web service (WSDL), processes the data and returns to the client:
[Client] ----> [My WebAPI] ----> [WSDL Server]
|
<-------- [My WebAPI] <---------
The WSDL part is a Java-based service. The only way we could consume it without issue in VS2015 was to add it as a Web Reference (2.0 in the dialog). It works perfectly, with strongly-typed values as required, but today we've seen a timeout between My WebApi and WSDL Server.
In other answers on SO, I see that the timeout period can be configured in web.config <bindings> or via a proxy, but I can't see how to wire this up given my web.config contents, which differs massively from other peoples. The code below was generated by VS2015 when the WSDL service was consumed:
<system.serviceModel>
<bindings />
<client />
</system.serviceModel>
<applicationSettings>
<MyWebAPI.Properties.Settings>
<setting name="MyWebAPIs_ThirdPartyWSDLService_GetData" serializeAs="String">
<value>https://wsdl.domain.com/webservices/services/GetData</value>
</setting>
</MyWebAPIs.Properties.Settings>
</applicationSettings>
I also can't find any mention of timeouts in the c# intellisense code. Any help or pointers would be appreciated. I've read about 12 posts on SO but still can't figure it out.

I hate to answer my own question but I think I've found the answer (I will remove if not). This is obvious, but reading too much on SO actually threw me off course and I was inspecting the wrong class in VS.
When consumed, the third-party web service client class GetData() is forced to derive from SoapHttpClientProtocol. This class derives from HttpWebClientProtocol, derived from WebClientProtocol.
WebClientProtocol has a public property Timeout, expressed in milliseconds.
Indicates the time an XML Web service client waits for the reply to a synchronous XML Web service request to arrive (in milliseconds).
The time out, in milliseconds, for synchronous calls to the XML Web service. The default is 100000 milliseconds.
Setting the Timeout property to Timeout.Infinite indicates that the request does not time out. Even though an XML Web service client can set the Timeout property to not time out, the Web server can still cause the request to time out on the server side.
Therefore the Timeout property is available directly from code when instantiated as a web service client, which I believe is due to the magic of VS:
SomeComsumedWebService wsc = new SomeComsumedWebService();
SomeComsumedWebService.Timeout = 600000; // 10 minutes
var obj = SomeComsumedWebService.MethodToGetData();

WCF: Is configuration in App.config better than in hard-coded in custom Proxy class?

first of all this is not duplicate. I have a little bit different question.
Is it good practice to get rid of WCF's config in App.config file in the client (or clients in case of cross-platform project) and replace it with injected Proxy class (from different dll, shared for all clients)?
I'm just starting so my config file is not big, but here is an example:
App.config (WCF part):
<system.serviceModel>
<client>
<endpoint address="net.tcp://localhost:8002/MyService"
binding="netTcpBinding"
contract="CallbackExample.Client.IMyService" />
</client>
</system.serviceModel>
I must have this code copy and pasted into every client I made. Working with Xamarin I can have many clients written in C# in single VS solution. So I though, why not just get rid of system.serviceModel section and do that:
MyServiceProxy.cs:
public class MyServiceProxy : ClientBase<IMyService>, IMyService
{
public MyServiceProxy()
: base(new NetTcpBinding(), new EndpointAddress("net.tcp://localhost:8002/MyService"))
{
}
public int JustAMethod()
{
return Channel.JustAMethod();
}
}
This way, I will have my configuration in single place.
So, my question is: Is it considered as a good practice? Is there a better way? I'm not sure, cause WCF is all about flexibility and easy config through App.config flie.

If there is no need for additional configuration, I always go for pure code solutions.
Back in the day WCF was slightly more complex to configure, via app.conf. With the ServiceHost you can even configure a WCF service in pure code.
The same applies to a WCF client imo; if you don't have the need to configure it via a config file for your users: I'd say go for the pure code solution.
Here another discussion of the same topic. (kind of the same reasoning, the question remains; do you need the configuration flexibility).

One potential downside to doing everything in code is that you lose the flexibility to configure not just the endpoint, but also the binding, without recompiling and redeploying. The binding includes some important network-related attributes (timeouts, transport protection levels, authorization schemes, etc) that you may want to tweak depending on the environment in which some of your client programs can run.
Note that you don't necessarily have to have a separate *.exe.config file for every client application. You can have a common .config file that each application can load explicitly. See ConfigurationManager.OpenMappedExeConfiguration

Reuse WCF contract interface, but retain use of declarative configuration

We've used the solution in this old topic ("WCF Service Reference generates its own contract interface, won't reuse mine"), but that only solves the problem of reusing interfaces. What we would like to do, if possible, is to also retain the use of config files to setup and configure various options on WCF client side using all the bells and whistles of <system.serviceModel> node.
The approach that was given forces us to do all that in code, and that already proved to be a problem at one point (we had to change a binding configuration parameter which forced us to go through an entire corporate change request approval process to alter two lines in the code base, which is a huge hassle compared to a request to change config file).
Is there a solution that combines these two worlds?

Lets say you have IService as your service contract and it is shared between the client and the server.
Then in client code you would have something like this:
ChannelFactory<IService> factory = new ChannelFactory<IService>("ServiceClient");
var channel = factory.CreateChannel();
var result = channel.GetData(1);
In Client app.cofnig you would have a section that looks like this:
<system.serviceModel>
<client>
<endpoint name="ServiceClient" address="http://localhost:51377/service.svc" binding="basicHttpBinding"
contract="Common.IService"/>
</client>
</system.serviceModel>
Briefly explained ChannelFactory creates Channel to access IService service using ServiceClient endpoint configuration in app.config.
You can expand serviceModel configuration as you wish. Just add additional code to properly close channel once operation is complete.

What exactly is it that you're trying to achieve? Seems like you're trying to reuse contracts, but have SVCUTIL/VS generate the ClientBase<T>-derived class and modify the .config file?
If so, I don't think that's a supported scenario, really. Honestly, if you need to reuse your service contract interfaces, you might as well implement the ClientBase<T>-based proxy class by hand. It's only a little bit of additional work, and will make your life easier in the long run.
There isn't a supported option in SVCUTIL/VS to only import the binding configuration rather than the entire thing, though, so you'd likely need to write your config file by hand as well (or copy it from a manual run of SVCUTIL).

Getting Error "This collection already contains an address with scheme http" with WCF on local machine

I'm trying out WCF for the first time and getting the following error when I try to instantiate the host:
This collection already contains an address with scheme http...
I have found a lot of other references to this and tried some of the solution to no avail. One fairly common thread that does not apply to me is that the problem is on a web server of some sort. I'm just running everything from my local machine.
One interesting symptom I found is that I'm developing a c# Forms app. Originally my top level form object inherited my service interface instead of a separate Service class. When I implement this way, there is no error on the host side but I have been having trouble on the client side.
Based on this solution:
How to solve "The ChannelDispatcher is unable to open its IChannelListener" error?
...I decided to separate the service host into a separate object. That's when I start seeing the problem.
The ServiceContract is simple enough:
[ServiceContract]
public interface ISSAService
{
[OperationContract]
void CreateSpaMonitor();
}
I instantiate the service like this:
Uri baseAddr = new Uri("http://localhost:8000/SSAService");
ServiceHost localHost = new ServiceHost(typeof(SSAService), baseAddr);
Where SSAService is the implementation of the Service interface.
If I change the second line to the following (and implement the interface...) the error goes away:
Uri baseAddr = new Uri("http://localhost:8000/SSAService");
ServiceHost localHost = new ServiceHost(typeof(SSAManager), baseAddr);
Where SSAManager is my top level Forms class...
Then I run into a client side problem which is where I started....
I have tried changing the port number and that doesn't seem to affect anything.
I'm new to WCF so maybe I'm missing something obvious.
Thanks.

I was getting this error:
This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item
I resolved it by doing the following to my web.config. Perhaps something changed in the .NET Framework 4 which is requiring this line, since I didn't need it before:
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<!-- Rest of the system.serviceModel content omitted for brevity--->
<system.serviceModel>

This can also occur if you have multiple bindings on the same IIS site with different domain names/ports. I resolved the issue by removing the extra named binding.

One of the solution I found previously was to add something like this:
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://localhost:8000"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
And then specifying the endpoint address absolutely. This didn't seem to have an effect but I was still using baseAddr in the constructor as shown above.
The solution for me was to remove baseAddr from the constructor.

How to test a WCF Webservice with JMeter?

I have a WCF Webservice hosted on IIS which exposes a single method that takes three integer parameters. I have a simple, console based client which can call this method.
int InsertNewOrder(short quantity, int custID, int productID);
If my understanding is correct, I need to provide JMeter a SOAP envelope with the details of the method to be called and parameters to be passed. I have seen many examples similar to below:
<soapenv:Envelope xmlns:soapenv="schemas.xmlsoap.org/soap/envelope/">;
<soapenv:Body>
<ns2:InsertNewOrder xmlns:ns2="?????">
<ns2:Param1>${1}</ns2:Param1>
<ns2:Param1>${1}</ns2:Param1>
<ns2:Param1>${1}</ns2:Param1>
</ns2:InsertNewOrder>
</soapenv:Body>
</soapenv:Envelope>
However, from looking at my WSDL doc, I don't see where it refers to any of the parameters needed to pass to the method. I've also used Fiddler to examine the client's soap messages to the service. Again, I don't see where it's passing the parameters. As a result, I don't know how to create a simple SOAP envelope I can use with JMeter to test this service.
Can anyone advise as to why the WSDL doc does not provide any details of the method parameters, or explain how I can create the necessary SOAP envelope for use with JMeter?
I am coding in C# using VS 2010, JMeter 2.4, IIS v6, wsHttpBinding.

Disclaimer: I'm not a WSDL expert, so i can't tell you why the doc doesn't provide detail.
To generate the SOAP envelope for JMeter, I've used the free version of soapUI.
Steps
Import WSDL into soap
Create a default request for the method
Set the request view to RAW, and copy into JMeter
This provides me all the information I need for jmeter, including parameters, user-agent, endpoint, etc.

Use JMeter's "HTTP Proxy Server" to record the WCF calls with your normal testclient, and then play them back later when testing. This is what I have experienced to be fastest, and gives the best test-cases (because you record them with your normal client, or test client of choice).
Set up JMeters HTTP Proxy Server as per instructions. Then, make sure the WCF (or any SOAP) client use that proxy. The important part of the WCF client configuation is (replace my ... with normal config):
<system.serviceModel>
<bindings>
...
<wsHttpBinding>
<binding ... proxyAddress="http://proxyServerName:8080" useDefaultWebProxy="false" ...>
...
<security mode="None">
<message establishSecurityContext="false"/>
<transport clientCredentialType="None"/>
</security>
proxyServerName is localhost, if the WCF client runs on the same machine as JMeter (normal when creating the test cases).
Also, I got an error message using HTTP Proxy, if I did not turn off security as shown above. The same security settings must also be at the WCF service server.
Happy testing! :-)