Bug 60317 - Stuck WebRequest
Summary: Stuck WebRequest
Status: VERIFIED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: unspecified
Hardware: PC All
: High critical
Target Milestone: 15.5
Assignee: Bugzilla
URL:
: 60386 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-23 10:29 UTC by Filip Navara
Modified: 2017-11-10 08:36 UTC (History)
11 users (show)

See Also:
Tags:
Is this bug a regression?: Yes
Last known good build: 3.8.0.49


Attachments
Candidate fix (684 bytes, patch)
2017-11-08 02:40 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details | Diff

Description Filip Navara 2017-10-23 10:29:16 UTC
We have a problem with the System.Net.WebRequest API getting stuck on sending POST request contents to HTTPS endpoint on Mono 5.4.0.212 when building as Xamarin.Mac Cocoa application. The problem started happening after some Mono/Xamarin.Mac update, but we couldn't pinpoint exactly at which version.

Depending on various options (buffering, specified ContentLength, etc.) the freeze happens either at Write call to a stream returned by HttpWebRequest.GetRequestStream or at HttpWebRequest.GetResponse. In every case, there is a WaitUntilComplete call like this:

System.Net.SimpleAsyncResult.WaitUntilComplete(int timeout, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.84/src/mono/mcs/class/System/System.Net/SimpleAsyncResult.cs:171
System.Net.HttpWebRequest.EndGetResponse(System.Net.WebAsyncResult asyncResult) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.84/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1023
System.Net.HttpWebRequest.GetResponse() in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.84/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1043

The problem could be easily reproduced by creating a new Cocoa App project in Visual Studio for Mac and replacing the main class with the following code:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Net;
using System.Text;
using AppKit;

namespace WebRequestTestCocoa
{
	static class MainClass
	{
		public static void SendOAuthRequest()
		{
			WebRequest request = WebRequest.Create("https://www.googleapis.com/oauth2/v4/token");
			request.Method = "POST";
			request.ContentType = "application/x-www-form-urlencoded";

			var parameters = new Dictionary<string, string>();
			parameters.Add("client_id", "000000000000-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.apps.googleusercontent.com");
			parameters.Add("grant_type", "refresh_token");
			parameters.Add("refresh_token", "1/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
			byte[] tokenRequest = Encoding.UTF8.GetBytes(String.Join("&", parameters.Select(p => p.Key + "=" + Uri.EscapeDataString(p.Value)).ToArray()));

			using (var requestStream = request.GetRequestStream())
				requestStream.Write(tokenRequest, 0, tokenRequest.Length);

			using (var response = request.GetResponse())
			{
				var tempStream = new MemoryStream();
				using (var responseStream = response.GetResponseStream())
					responseStream.CopyTo(tempStream);
			}
		}

		static void Main(string[] args)
		{			
			NSApplication.Init();
			SendOAuthRequest();
		}
	}
}
Comment 1 Filip Navara 2017-10-23 12:40:39 UTC
Apparently, it gets stuck somewhere deep in the TLS code. The same code run with the Managed TLS providers on non-Cocoa app seems to work just fine.
Comment 2 Timothy Risi 2017-10-23 19:41:56 UTC
I've been doing more testing on this.

The
Comment 3 Timothy Risi 2017-10-23 19:44:02 UTC
Whoops, apparently adding someone to the CC list saves all changes.

So after more testing, this is failing starting on Xamarin.Mac 4.0 (tested on 4.0.0.84).  It worked correctly on all of the previous versions of XM that I tested (3.0, 3.4, 3.6, up through 3.8.0.49).

It fails on XM 4.0 for both Modern and Full profiles, but works correctly for the unsupported system mono option.  It also works correctly using the same code in a Console app with Mono 5.4.0.201
Comment 4 Timothy Risi 2017-10-26 17:47:40 UTC
*** Bug 60386 has been marked as a duplicate of this bug. ***
Comment 5 Timothy Risi 2017-10-26 17:48:56 UTC
The same thing is happening on Xamarin.iOS 11.4.0.93
Comment 6 Sebastien Pouliot 2017-10-26 18:08:03 UTC
Raising importance
Comment 7 Alain 2017-10-31 18:00:09 UTC
news for this bug ?
Comment 8 Martin Baulig 2017-11-01 20:39:40 UTC
This is not a full test case and therefor not reproducible.  I played around with the OAuth APIs a bit and it's actually a 4 step process.

1.) You need to create credentials using Google's API Console.

====
const string ClientID = "XXXXX.apps.googleusercontent.com";
const string ClientSecret = "XXXX";
====

2.) Create authorization credentials:

====
		static string CreateToken ()
		{
			var parameters = new Dictionary<string, string> ();
			parameters.Add ("client_id", ClientID);
			parameters.Add ("redirect_uri", "urn:ietf:wg:oauth:2.0:oob");
			parameters.Add ("response_type", "code");
			parameters.Add ("scope", "https://www.googleapis.com/auth/drive");

			var queryString = string.Join ("&", parameters.Select (p => p.Key + "=" + Uri.EscapeDataString (p.Value)).ToArray ());
			var fullUri = new Uri ($"https://accounts.google.com/o/oauth2/v2/auth?{queryString}");

			Console.WriteLine (fullUri);

			var code = Console.ReadLine ();
			Console.WriteLine ($"GOT TOKEN {code}");

			// var request = WebRequest.Create (fullUri);
			// var response = request.GetResponse ();

			return code;
		}
====

This prints the full URL to the console, copy&paste it into a web browser, log in, copy&paste the authentication token to the console.

3.) Get access token:

====
		static string GetAccessToken (string code)
		{
			var request = WebRequest.Create ("https://www.googleapis.com/oauth2/v4/token");
			request.Method = "POST";
			request.ContentType = "application/x-www-form-urlencoded";

			var parameters = new Dictionary<string, string> ();
			parameters.Add ("client_id", ClientID);
			parameters.Add ("client_secret", ClientSecret);
			parameters.Add ("grant_type", "authorization_code");
			parameters.Add ("redirect_uri", "urn:ietf:wg:oauth:2.0:oob");
			parameters.Add ("code", code);
			var tokenRequest = Encoding.UTF8.GetBytes (String.Join ("&", parameters.Select (p => p.Key + "=" + Uri.EscapeDataString (p.Value)).ToArray ()));

			using (var requestStream = request.GetRequestStream ())
				requestStream.Write (tokenRequest, 0, tokenRequest.Length);

			string accessToken;
			using (var response = request.GetResponse ()) {
				var tempStream = new MemoryStream ();
				using (var responseStream = response.GetResponseStream ())
					responseStream.CopyTo (tempStream);
				accessToken = Encoding.UTF8.GetString (tempStream.GetBuffer ());
			}

			Console.WriteLine ($"GOT ACCESS TOKEN {accessToken}");

			var refreshToken = Console.ReadLine ();
			Console.WriteLine ($"GOT REFRESH TOKEN: {refreshToken}");
			return refreshToken;
		}

====

This dumps a JSON - I was too lazy to parse that, you need to manually copy&paste the refresh token.

4.) Refresh token

====
		static void RefreshToken (string token)
		{
			var request = WebRequest.Create ("https://www.googleapis.com/oauth2/v4/token");
			request.Method = "POST";
			request.ContentType = "application/x-www-form-urlencoded";

			var parameters = new Dictionary<string, string> ();
			parameters.Add ("client_id", ClientID);
			parameters.Add ("client_secret", ClientSecret);
			parameters.Add ("grant_type", "refresh_token");
			parameters.Add ("refresh_token", token);
			var tokenRequest = Encoding.UTF8.GetBytes (String.Join ("&", parameters.Select (p => p.Key + "=" + Uri.EscapeDataString (p.Value)).ToArray ()));

			using (var requestStream = request.GetRequestStream ())
				requestStream.Write (tokenRequest, 0, tokenRequest.Length);

			string accessToken;
			using (var response = request.GetResponse ()) {
				var tempStream = new MemoryStream ();
				using (var responseStream = response.GetResponseStream ())
					responseStream.CopyTo (tempStream);
				accessToken = Encoding.UTF8.GetString (tempStream.GetBuffer ());
			}

			Console.WriteLine ($"GOT REPLY {accessToken}");

			Console.WriteLine ("ALL DONE");
		}

====
Comment 9 Martin Baulig 2017-11-01 20:41:32 UTC
In my example, the token is valid for one hour, so you can run step 4.) multiple times.

It is working fine for me, can't get it to hang anywhere.
Comment 10 Chris Hamons 2017-11-01 20:44:05 UTC
So as noted in #3 this only happens with XI/XM, not system mono, so the test was insufficient.
Comment 11 Martin Baulig 2017-11-01 20:46:13 UTC
In my 4.), the "accessToken" is also a JSON string.
Comment 12 Alain 2017-11-03 10:00:13 UTC
I do not understand ! The access to the webservices is inaccessible since the version iOS 11.4 and Xamarin.MAC 4.0, always a timeout on the call of the functions of the webservices. I am in https too.

You have to change something in this version since before, there was no problem.

Alain
Comment 13 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-03 15:52:33 UTC
## Status update for any users watching this issue

This issue is under active investigation.  As hinted at in Comment 10, the results in Comment 8 and Comment 9 were indeed from desktop Mono rather than Xamarin.Mac.  Martin has now also been able to see the problem in Xamarin.Mac to allow further investigation.
Comment 14 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-04 03:27:48 UTC
## Note to the Xamarin team

I had luck with a brute-force strategy to narrow down the issue.  It appears that the following commit is the source of the problem:

https://github.com/mono/mono/commit/1b5e0f73316ee7b83c8947bc738015443fabd7af
"[System]: Correctly implement close and shutdown in SslStream."




## Background info on the makeshift testing strategy used

To see if brute-force manual testing could provide any useful results, I tried git-bisect'ing through the Mono commits between 1a9acb7 (GOOD) and c81fe5e (BAD).  This was a roll of the dice on whether I would find enough runnable Mono commits to provide useful data.  But by a bit of good luck, I was successful in testing several commits by rebuilding just System.dll and Mono.Security.dll in the `xammac` profile, and I narrowed the problem down to a single commit:

- mono commit 1b5e0f7 demonstrates the BAD behavior.

- The previous mono commit (c8863e1) demonstrates the GOOD behavior.

- If I check out mono 2017-06/38da0b3 (as in the current Beta version of Xamarin.Mac) and then revert just commit 1b5e0f7, that is sufficient to restore the GOOD behavior.




## Side-note: Testing of various normal Xamarin.Mac builds for reference

BAD:  Xamarin.Mac 4.0.0.93 (1b460cb) (Embedded Mono: 2017-06/38da0b3)
BAD:  Xamarin.Mac d15-5    (30a0627) (Embedded Mono: 2017-06/7d78877)
BAD:  Xamarin.Mac master   (8178ecc) (Embedded Mono: 2017-06/c81fe5e)
GOOD: Xamarin.Mac master   (f90655b) (Embedded Mono: 2017-04/1a9acb7)
Comment 15 Martin Baulig 2017-11-07 20:53:08 UTC
The original test case does not call NSApplication.Main().

Can you please try again with a real XM / XI application and not call blocking code from the UI thread?  I've spent some time playing around with this yesterday and the problem goes away for me when using the async API in a real XM app.
Comment 16 Sebastien Pouliot 2017-11-07 21:25:56 UTC
@Martin the code in the original description has a call to NSApplication.Main ?

@Brendan have you been testing something else ? if so let's attach it to the bug report so everyone use the same (e.g. QA for verification later).

@Alain I'll re-open your bug so it can be tracked independently (in case t's something different).
Comment 18 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-07 23:12:36 UTC
## Manual testing notes for the Xamarin team about `NSApplication.Main()` not being involved

> The original test case does not call `NSApplication.Main()`.
It turns out the lack of `NSApplication.Main()` is _not_ involved in the behavior for the test case from Comment 0.  So at this time it seems the key aspect of the test case is that it calls the _synchronous_ method `WebRequest.GetResponse()` on the UI thread. (I will add a follow-up comment with other test results that highlight the involvement of the synchronous method and the UI thread.)




## Steps followed to test involvement of `NSApplication.Main()`

1. Create a new "Mac > App > Cocoa App".

2. Add the static `SendOAuthRequest` method definition from Comment 0 to the `ViewController` class in ViewController.cs.

3. Add a call to `SendOAuthRequest()` in the `ViewDidLoad()` override.

4. Build and run the app in the Debug configuration.

(This test application now calls calls both `NSApplication.Init()` and `NSApplication.Main(args)` as normal for a Xamarin.Mac app.)




## BAD Results with Xamarin.Mac 4.0.0.93 (1b460cb)

The application starts launching, but the application icon continues bouncing in the dock for over 60 seconds.  If I choose "Run > Pause" during this time, I see the following call stack:

> System.Threading.WaitHandle.WaitOne_internal() in 
> System.Threading.WaitHandle.WaitOneNative(Microsoft.Win32.SafeHandles.SafeWaitHandle waitableSafeHandle, uint millisecondsTimeout, bool hasThreadAffinity, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/corlib/System.Threading/WaitHandle.cs:104
> System.Threading.WaitHandle.InternalWaitOne(Microsoft.Win32.SafeHandles.SafeWaitHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/referencesource/mscorlib/system/threading/waithandle.cs:250
> System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/referencesource/mscorlib/system/threading/waithandle.cs:239
> System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/referencesource/mscorlib/system/threading/waithandle.cs:206
> System.Net.SimpleAsyncResult.WaitUntilComplete(int timeout, bool exitContext) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/System/System.Net/SimpleAsyncResult.cs:171
> System.Net.HttpWebRequest.EndGetResponse(System.Net.WebAsyncResult asyncResult) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1023
> System.Net.HttpWebRequest.GetResponse() in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1043
> SingleViewMacApp1.ViewController.SendOAuthRequest() in /Users/macuser/Projects/SingleViewMacApp1/SingleViewMacApp1/ViewController.cs:54
> System.Runtime.CompilerServices.AsyncVoidMethodBuilder.Start<SingleViewMacApp1.ViewController.<SendOAuthRequest>d__5>(SingleViewMacApp1.ViewController stateMachine) in /Library/Frameworks/Xamarin.Mac.framework/Versions/4.0.0.98/src/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:84
> SingleViewMacApp1.ViewController.SendOAuthRequest() in 
> SingleViewMacApp1.ViewController.ViewDidLoad() in /Users/macuser/Projects/SingleViewMacApp1/SingleViewMacApp1/ViewController.cs:22

Eventually the web request throws an exception when it times out.




## GOOD Results after changing to "good" versions of the System.dll and Mono.Security.dll as described in Comment 14

The application launches, and then an _expected_ System.Net.WebExecption is thrown (almost immediately) because the request is unauthorized: "The remote server returned an error: (401) Unauthorized."

This is the correct expected output when using the test steps as I have described them because I have _not_ completed the additional steps in Comment 8 to set up the server-side authentication.  (It is not strictly required to set up that server-side authentication to observe the timeout or no-timeout behavior in this scenario.)
Comment 19 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-08 00:28:44 UTC
Manual testing notes for the Xamarin team about the UI thread




## Steps followed to test the involvement of running the request on the UI thread


1. Start with the test case as described in Comment 0 or Comment 18. (I tested step 2 for both scenarios with the same results.)


2. Change the call to `SendOAuthRequest()` to run it in a background thread:

(new Thread(() => SendOAuthRequest())).Start();

And build and run the application in the Debug configuration.


3. If you use the scenario from Comment 18, then for "fun" you can also now try changing the call to force the execution back to the UI thread:

(new Thread(() => InvokeOnMainThread(SendOAuthRequest))).Start();

And again build and run the application in the Debug configuration.




## GOOD Results at step 2

The expected exception is thrown almost immediately after the app launches because the request is unauthorized: "The remote server returned an error: (401) Unauthorized."




## BAD Results at step 3

The application launches, but then nothing happens for over 60 seconds until the web request times out.
Comment 20 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-08 00:39:48 UTC
Manual testing notes for the Xamarin team, comparing `WebRequest.GetResponse()` to `WebRequest.GetResponseAsync()`




## Steps followed to test the behavior of the asynchronous `WebRequest.GetResponseAsync()` API

1. Start with the test scenario from Comment 18.

2. Change `SendOAuthRequest()` to use async/await with the `WebRequest.GetResponseAsync()` API:

public async override void ViewDidLoad()
{
    base.ViewDidLoad();
    var stream = await SendOAuthRequest();
}

public async Task<Stream> SendOAuthRequest()
{
    WebRequest request = WebRequest.Create("https://www.googleapis.com/oauth2/v4/token");
    request.Method = "POST";
    request.ContentType = "application/x-www-form-urlencoded";

    var parameters = new Dictionary<string, string>();
    parameters.Add("client_id", "000000000000-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.apps.googleusercontent.com");
    parameters.Add("grant_type", "refresh_token");
    parameters.Add("refresh_token", "1/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
    byte[] tokenRequest = Encoding.UTF8.GetBytes(String.Join("&", parameters.Select(p => p.Key + "=" + Uri.EscapeDataString(p.Value)).ToArray()));

    using (var requestStream = request.GetRequestStream())
        requestStream.Write(tokenRequest, 0, tokenRequest.Length);

    using (var response = await request.GetResponseAsync())
    {
        var tempStream = new MemoryStream();
        using (var responseStream = response.GetResponseStream())
        {
            responseStream.CopyTo(tempStream);
            return tempStream;
        }
    }
}




## GOOD Results

The expected exception is thrown almost immediately after the app launches because the request is unauthorized: "The remote server returned an error: (401) Unauthorized."




## Additional background information and hunches

Martin was telling me about how part of https://github.com/mono/mono/commit/1b5e0f73316ee7b83c8947bc738015443fabd7af was to async-ify `Mono.Net.Security.MobileAuthenticatedStream.InnerWrite()` and have it call `InnerStream.WriteAsync()` when running asynchronously.  As I understand it, this change was aimed at apps that consume `SslStream` directly, to allow those apps to get the expected asynchronous write behaviors for the streams.  But this appears to have introduced a side-effect for apps that call the synchronous APIs of HttpWebRequest on the UI thread.

Given those clues, this problem feels suspiciously similar to me to the general deadlock problem that happens for example for `Task.Result` on the UI thread [1, 2].  I will plan to try a few more tests to explore that idea.

[1] https://blogs.msdn.microsoft.com/pfxteam/2011/01/13/await-and-ui-and-deadlocks-oh-my/
[2] https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
Comment 21 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-08 02:40:40 UTC
Created attachment 25598 [details]
Candidate fix

The attached one-line patch adds `ConfigureAwait (false)` to one of the new `await` statements in mcs/class/System/Mono.Net.Security/AsyncProtocolRequest.cs that was added as part of mono commit 1b5e0f7.

I have also submitted this candidate change as a pull request:
https://github.com/mono/mono/pull/5963




## GOOD Results after this patch

If I make just this _one_ change to the "BAD" 2017-06/38da0b3 Mono, rebuild System.dll in the `xammac` profile, and then overwrite that file in the MonoBundle directory of my test app, then I restore the GOOD behavior.

I believe this confirms my hunch from Comment 20 that the problem was indeed the usual deadlocking issue when awaiting Tasks on the UI thread.  As discussed on [2], if any Tasks awaited anywhere up the call stack are missing `ConfigureAwait (false)`, then you can run into trouble on the UI thread.

[2] https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html




## Follow-up notes

1. Do the other `await` statements in commit 1b5e0f7 all look OK?  Yes, it looks like this was the only `await` statement that was missing `ConfigureAwait (false)`:

> $ git show 1b5e0f73316ee7b83c8947bc738015443fabd7af | grep await
> +				await ProcessOperation (cancellationToken).ConfigureAwait (false);
> +				var ret = await InnerRead (cancellationToken).ConfigureAwait (false);
> +					await Parent.InnerWrite (RunSynchronously, cancellationToken);
> +				var ret = await Parent.InnerRead (RunSynchronously, requestedSize, cancellationToken).ConfigureAwait (false);
> +					result = await asyncRequest.StartOperation (CancellationToken.None).ConfigureAwait (false);
> +				result = await asyncRequest.StartOperation (cancellationToken).ConfigureAwait (false);
> +			var ret = await task.ConfigureAwait (false);
> +			await task.ConfigureAwait (false);

2. Is it a concern that mcs/class/System did not contain any calls to `ConfigureAwait ()` until commit 1b5e0f7:
> $ git grep ConfigureAwait 1b5e0f73316ee7b83c8947bc738015443fabd7af^ -- mcs/class/System || echo 'None' 
> None
I do not think this is a concern.  For example, System.Net.Http.HttpClient has been using `ConfigureAwait (false)` for several years, so as I understand it, it is fine to introduce a new usage of it in AsyncProtocolRequest.
Comment 22 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-08 18:27:56 UTC
## Commit tracking notes for the Xamarin team

The candidate fix has now been merged into the d15-5-2017-06 branch:
mono/d15-5-2017-06 commit: 950ea65c3ba571cd139dc34b48d7101a2e894993

Pull requests have also been set up for the master and 2017-10 branches to keep those branches in sync:
mono/2017-10: https://github.com/mono/mono/pull/5968
mono/master:  https://github.com/mono/mono/pull/5969




## Follow-up Mono reference updates for xamarin-macios and xamarin-android

This issue affects Xamarin.iOS and Xamarin.Mac via Mono.AppleTls and Xamarin.Android when using the BoringSSL implementation ("Project Options > Android Build > SSL/TLS implementation > Native TLS 1.2+" in the IDE).


### xamarin-macios

Pull request for xamarin-macios/d15-5:
https://github.com/xamarin/xamarin-macios/pull/2975


### xamarin-android

xamarin-android/d15-5 commit: 785f820c3693b6497175413176faaebbf6bff3a1
Comment 23 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-08 22:39:21 UTC
*** Bug 60386 has been marked as a duplicate of this bug. ***
Comment 24 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-09 22:05:46 UTC
## Commit tracking notes for xamarin-macios, xamarin-android, and Visual Studio Tools for Xamarin

> xamarin-macios/d15-5       commit: dc96ae565e3d650c33942e3bb4febc5c2938555f
> 
> xamarin-android/d15-5      commit: 785f820c3693b6497175413176faaebbf6bff3a1
> monodroid/d15-5            commit: f65f87747a4639fe378abfbbe1f6b3365af89113
> xamarin/VisualStudio/d15-5 commit: c72989c091dd28bc4dc9d56add158b3856054436
> Visual Studio 2017         commit: 065f069d5f3d562b3b0c5f47326be9b7ac5a8a8c
Comment 25 Brendan Zagaeski (Xamarin Team, assistant) 2017-11-09 22:18:48 UTC
## Verification of development builds: verified fixed

I have locally verified that the development builds for the commits from Comment 24 successfully resolve the issue as described in Comment 0 and Comment 18.

GOOD: Xamarin.Android d15-5 (f65f877)
GOOD: Xamarin.iOS     d15-5 (dc96ae5)

Barring any unexpected complications, these fixes will also be included in the next public Xamarin 15.5 Preview and Visual Studio 2017 version 15.5 Preview.  If any complications do arise, I will update the bug report accordingly.
Comment 26 Alain 2017-11-10 08:36:53 UTC
I downloaded the following versions:

Xamarin.Mac 4.0.0.214
Xamarin.IOS 11.4.0.214

I tried my application and the problem seems solved. The webservices work again.

Thank you

Alain

Note You need to log in before you can comment on or make changes to this bug.