We have a few ASP.NET and WCF applications that are continuously being migrated to latest .net framework version as it is being released. This migration was working fine until we reached .NET Framework 4.6.2 and since then we started seeing TLS connectivity error like below. When I added
<httpRuntime targetFramework="4.6.2" />
under <system.web>
in the Web.config file, the error disappeared. So as I understand, this setting is forcing the application to run under .NET Framework 4.6.2 (without this, I believe the application was running under .NET Framework 4.0), which is causing it to use underlying Operating System's default protocol for securing the connection. Please correct my understanding if I am missing something.
System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult) at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar) --- End of inner exception stack trace ---
<httpRuntime targetFramework="4.5" /> means that current project designed to use . NET 4.5 runtime assemblies without recompiling existing project assemblies in deployment machine before loading it into memory.
When you target a framework in an app or library, you're specifying the set of APIs that you'd like to make available to the app or library. You specify the target framework in your project file using a target framework moniker (TFM). An app or library can target a version of .
The ControlRenderingCompatibilityVersion setting[^] simply activates a different code path in the . NET 4.0 code, which forces certain controls to render in the same obsolete way that they did in v3. 5, ignoring the new improvements introduced in v4. It doesn't introduce a dependency on v3.
Have a look at this: https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support. TLS 1.2 is default for .NET 4.6 and above, supported but not default for 4.5 and not well supported for 4.0 and lower.
Perhaps either one of your application updates, an IIS or OS config change had disabled TLS versions < 1.2 and the client applications were unable to connect.
As for setting <httpRuntime targetFramework="4.6.2" />
, we found the same thing. Changing the target framework in the project file and the targetFramework
value in the compilation
element were not enough. It still retained < .NET 4.6 behaviour for TLS. In fact when changing the target framework, Visual Studio added the httpRuntime
element to the web.config in a commented out block.
(The recommended answer here is also helpful: What do the TargetFramework settings mean in web.config in ASP .NET MVC?)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With