System.AggregateException

[WindowsQuery]

When the todo:TodoListBaseAddress value in app.config is changed to the web app address from default https://localhost:44321, the following error is thrown.

System.AggregateException
HResult=0x80131500
Message=One or more errors occurred.
Source=mscorlib
StackTrace:
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at TodoListDaemon.Program.Main(String[] args) in C:\gitClones\active-directory-dotnet-daemon-master\TodoListDaemon\Program.cs:line 82
Inner Exception 1:
HttpRequestException: An error occurred while sending the request.
Inner Exception 2:
WebException: The underlying connection was closed: An unexpected error occurred on a send.
Inner Exception 3:
IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Inner Exception 4:
SocketException: An existing connection was forcibly closed by the remote host

[jmprieur]

@WindowsQuery this means that your Web API is not running at teh expected address
Check that this works and is indeed at that URL.

The Aggregate Exception is only due to async calls ran synchronously.

[WindowsQuery]

The link works. It is when the same value is provided to add key="todo:TodoListBaseAddress" that it fails. And, should it not open the browser with that URL instead of http://localhost:9184/?

I am not sure if this is a working sample.

[LawrenceSmith1437]

I have also just run through the example code. As the OP reported, everything works when the service runs locally. When I deploy the service to Azure I'm also getting exception
"Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."

I successfully deployed my app to https://todoservice{omitted}.azurewebsites.net

My console app is configured correctly:
<add key="todo:TodoListBaseAddress" value="https://todoservice{omitted}.azurewebsites.net" />

[LawrenceSmith1437]

Quick follow-up: I redeployed the service as HTTP (not HTTPS!), changed the app registration reply and home page urls to http as well, and at that point the client could call the service successfully. So, the web service itself is functioning. It just is not working once the website is secured.

One thing I noticed in the steps is that one of the azure service deploy steps stated:

From the Settings -> Reply URLs menu, update the Sign-On URL, and Reply URL fields to the address of your service

I assume we're talking about the App Registration entry in Azure AD? I found the setting called "Reply Url", but there is nothing specific in there about reply or sign-on url. It's just a list of urls. So in addition to changing the Reply Url, I also set the application's Home Page. If there is a setting called Sign-On, I could not find it via the instructions.

Was this crucial, and if so, where can it be located?

[jmprieur]

Thanks for the heads-up @SgtSpamCan; things change quickly in the portal and we need to update our README.mds

@kalyankrishna1
If you have capacity, would you want to apply the new deployment steps to this sample?

[LarrySmith-1437]

@jmprieur I'm honored to have you on the thread. Quick question: Was there something I missed regarding a Sign-On url? Or is it no longer relevant? Just trying to get my sample code working :-)
(heh, @SgtSpamCan is my other sign-on...)

[romerve]

Hi, i had the same issue, fixed it with before making the post:
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Some reason TLS 1.0 is always used, and changing the min TLS version in the App Service settings doesnt seem to work.

[jmprieur]

Did you try updating the sample to work with .NET Framework 4.7.2 ? it ensure TLS 1.2 is used.

[romerve]

Did you try updating the sample to work with .NET Framework 4.7.2 ? it ensure TLS 1.2 is used.

No, i was just running it as it was. Like you mention, updating it to 4.7.2 ensures TLS is used and removes the need to explicitly declare it.