Bug 19697 - WCF SendTimeout not working in Xamarin
Summary: WCF SendTimeout not working in Xamarin
Alias: None
Product: Class Libraries
Classification: Mono
Component: WCF assemblies ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
: 5676 25251 ()
Depends on:
Reported: 2014-05-12 17:56 UTC by Jon Goldberger [MSFT]
Modified: 2017-09-06 16:55 UTC (History)
12 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Comment 1 Jon Goldberger [MSFT] 2014-05-12 17:57:17 UTC
Taking reference of article http://docs.xamarin.com/guides/cross-platform/application_fundamentals/web_services/walkthrough_working_with_WCF/ , I am developing one cross platform mobile application.

I have assigned SendTimeout to 10 seconds, but it is not working.
It is working perfectly in my test Web application.

My code is as below

EndpointAddress endPoint = new EndpointAddress("API URL");
BasicHttpBinding binding = new BasicHttpBinding
Name = "basicHttpBinding",
MaxBufferSize = 2147483647,
MaxReceivedMessageSize = 2147483647
if (endPoint.Uri.Scheme == Uri.UriSchemeHttps)
binding.Security.Mode = BasicHttpSecurityMode.Transport;

TimeSpan timeout = new TimeSpan(0, 0, 10);
binding.SendTimeout = timeout;

I have also checked example project attached with that article. SendTimeout also not working in that too.
Comment 3 Jon Goldberger [MSFT] 2014-05-12 17:58:54 UTC
Version info:

OS Name Microsoft Windows 7 Professional
Version 6.1.7601 Service Pack 1 Build 7601
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Manufacturer Hewlett-Packard
System Model HP Compaq Elite 8300 SFF
System Type x64-based PC
Processor Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 4 Logical Processor(s)
BIOS Version/Date Hewlett-Packard K01 v02.05, 07-May-2012
SMBIOS Version 2.7
Hardware Abstraction Layer Version = "6.1.7601.17514"

=== Xamarin Studio ===

Version 4.2.3 (build 60)
Installation UUID: d6fd15a3-441b-4057-87d1-bfd6025a3e09
Microsoft .NET 4.0.30319.18444
GTK+ 2.24.22 theme: MS-Windows
GTK# (

=== Xamarin.Android ===

Version: 4.12.3 (Business Edition)
Android SDK: C:\Users\nidhi.thakrar\AppData\Local\Android\android-sdk
Supported Android versions:
1.6 (API level 4)
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: C:\Program Files (x86)\Java\jdk1.6.0_39
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 402030060
Build date: 2014-03-05 16:53:54Z
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044

=== Operating System ===

Windows 6.1.7601.65536 (64-bit)
Comment 4 andrewt 2014-06-19 10:55:17 UTC
I have this issue as well.  I ended up having to revert to using the SOAP client.  I was using PCL profile 136 when I encountered this issue.

It seems that the OperationTimeout in the System.ServiceModel.ClientRuntimeChannel class is not getting defaulted by the SendTimeout from the binding as it should.  The OperationTimeout cannot be set manually due to access modifiers, but it can be seen in the debugger and will always be 60 seconds no matter what you set the SendTimeout to.

Comment 5 Mehmet Kartalbas 2014-12-30 02:56:56 UTC
short questin, when will this issue be resolved? I'm waiting since months. For long calculation reason my services need more than 60 seconds until it will answer. I already achieved my goal with workarounds but I would like to delete them after this issue is solved. Please update the status of this bug, this is for some others an important bug. Thanks.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2015-01-05 07:59:03 UTC
*** Bug 25251 has been marked as a duplicate of this bug. ***
Comment 7 Joe Pro 2015-05-07 11:05:20 UTC
I'm also hitting this bug.  I can appreciate the workaround, but would rather be able to set individual timeout values.  In my case, the WCF code is shared across platforms (iOS, Android and windows) and having to use this workaround is a major pain.

This issue has been opened for some time now.  Is it eventually going to be addressed?
Comment 8 Neal 2015-05-07 11:07:11 UTC
I was hoping this was resolved in unified and wasn't sure of the status - sad to hear it's NOT fixed.  Miguel & Co. - please fix this ASAP...

Comment 9 Atsushi Eno 2015-05-21 04:11:36 UTC
fixed in mono master.
Comment 10 Miguel de Icaza [MSFT] 2015-05-21 08:27:40 UTC
Thanks Atsushi.

Atsushi also researched a few options that you could attempt as a workaround until we get binaries out:

1) client.ChannelFactory.Endpoint.Binding.SendTimeout =
TimeSpan.FromMilliseconds (1000);
2) client.InnerChannel.OperationTimeout = TimeSpan.FromMilliseconds (1000);
Comment 11 Atsushi Eno 2015-05-21 10:12:01 UTC
Well, actually those options don't work without my fix. You'll have to wait.
Comment 12 Atsushi Eno 2015-05-21 10:15:20 UTC
A workaround is: create a custom Binding with custom BindingElement that you implement a working HTTP stack (HttpRequestChannel) that makes sure to give Timeout value.
Comment 13 Atsushi Eno 2015-05-21 13:24:48 UTC
Actually mobiles have different issue which is caused by Silverlight limitation. 

The latest master removes that #if !NET_2_1 condition.

[master 63a8b86]
Comment 14 lukasz 2015-07-27 11:17:08 UTC
Atsushi Eno 
I assumed, that you have resolved "MONO SendTimeout bug".
Could you tell me how can I install your solution in my mono?
Thank you for your time :)
Comment 15 Rolf Bjarne Kvinge [MSFT] 2016-02-15 16:19:52 UTC
*** Bug 5676 has been marked as a duplicate of this bug. ***