1

I'm using a WebForms Report viewer control successfully, so I was a bit surprised to find that trying to do the exact same thing in a WinForm report viewer control is failing...

I'm getting a Sytem.Net.WebException "Unable to connect to the remote server" within an inner exception of System.Net.Sockets.SocketException "An attempt was made to access a socket in a way forbidden by its access permissions (ip_address):80". (Where "(IP_address)" is the address I'm trying to use.)

Google searches on the socket exception tend to land on Stack Exchange questions, with results including things like:

  • Firewall blocking
  • Must run as Admin (to do some things with sockets)

( From results Such as an attempt was made to access a socket in a way forbbiden by it's access permissions. why? )

This gives me a clue. Particularly, I'm interesting in the Firewall blocking concept. What I'm wondering is, could the SSRS Report Viewer control, or the underlying soap layer, actually be trying to redirect my request from HTTP/port-80 to HTTPS/port-443?

I am certain that port 443/HTTPS isn't hitting the site for me, when I try in a browser. I'm going from one network to another, and I'm guessing that port is closed at that level, but regardless, I'm pretty certain the SSRS report server isn't configured for SSL/HTTPS.

I want to again state that I can successfully use a web forms report viewer control to access and show reports.

Only the windows report viewer control is showing this issue. It's a couple pieces from the stack trace that make me wonder if the cause is an attempt to use SSL instead of what I've given it to use. Notice the parts about SetConnectionSSLForMethod and similar.

System.Net.WebException was unhandled
  HResult=-2146233079
  Message=Unable to connect to the remote server
  Source=Microsoft.ReportViewer.WinForms
  StackTrace:
       at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.GetSecureMethods()
       at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.IsSecureMethod(String methodname)
       at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.SetConnectionSSLForMethod(String methodname)
       at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.ProxyMethodInvocation.Execute[TReturn](RSExecutionConnection connection, ProxyMethod`1 initialMethod, ProxyMethod`1 retryMethod)
       at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.LoadReport(String Report, String HistoryID)
       at Microsoft.Reporting.WinForms.SoapReportExecutionService.LoadReport(String report, String historyId)
       at Microsoft.Reporting.WinForms.ServerReport.EnsureExecutionSession()
       at Microsoft.Reporting.WinForms.ServerReport.GetParameters()
       at ScheduleRunner.ReportHelper.GetParameters(String reportServerUrl, String reportPath) in C:\VS\Projects\Web\ScheduleRunner\ReportHelper.cs:line 27
       at ScheduleRunner.ScheduleRunner.Start() in C:\VS\Projects\Web\ScheduleRunner\ScheduleRunner.cs:line 75
       at ScheduleRunner.Program.Main(String[] args) in C:\VS\Projects\Web\ScheduleRunner\Program.cs:line 14
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 
       ErrorCode=10013
       HResult=-2147467259
       Message=An attempt was made to access a socket in a way forbidden by its access permissions (ip_address):80
       NativeErrorCode=10013
       Source=System
       StackTrace:
            at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
            at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
       InnerException: 

If this is indeed forcing SSL, then how can I prevent that? I'm using HTTP, and the soap layer appears out of my control with just using the viewer itself.

All I was wanting to do was just to get the report parameters and particularly look at their defaults, as those may contain be calculated and ever changing by an expression.

I was was actually going to use these as part of calling into the url based access pattern for getting an exported report.

On another topic, I might also need to check if a report has certain hidden parameters, as I might want to supply them, but only if they are present. But I'm not even at that part yet, since I can't get the winforms viewer to connect, even when the web forms viewer connects fine, both running locally from my machine for development.

UPDATE 1/10/2017 I started noticing other problems with simpler code. It would seem like there is an inability, for example, to use webclient to connect to anything...

Community
  • 1
  • 1
Greg
  • 2,410
  • 21
  • 26

1 Answers1

0

I simplified my attempts and found that even a very simple webclient request was also failing with the same error.

After plenty of troubleshooting I started wondering what could I shutdown or uninstall to simplify my issue even further. Antivirus is always a nice target for problems.

I indeed found that killing Kaperski did fix my problem, even though it wasn't running a firewall or various other components. And even though other developers running Windows 10, Visual Studio 2015, and Kaperski don't seem to be having this same problem.

Greg
  • 2,410
  • 21
  • 26
  • For whoever may be concerned, it wasn't seemingly a firewall, nor did I need to run with Administrator access. – Greg Jan 11 '17 at 14:05