Home/ Questions/Q 8565453
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T17:25:50+00:00

I have recently encountered some rather baffling behavior while up-converting a VB.NET solution from

  • 0

I have recently encountered some rather baffling behavior while up-converting a VB.NET solution from VS2005 to VS2010. For reference, the solution targets .NET 2.0 and was running without error in the debugger prior to the conversion. In addition to the IDE change, corporate has seen it fit to refresh my device from Win XP (x86) to Win 7 (x64).

Now that I have converted the solution to VS2010, I receive a Socket exception as soon as the debugger loads (details below). This ONLY occurs in the debugger. Building the solution in its Release configuration produces a MSI that correctly installs and runs without error.

The details of the exception received are as follows:

System.Net.Sockets.SocketException was unhandled
  Message=An invalid argument was supplied
  Source=System
  ErrorCode=10022
  NativeErrorCode=10022
  StackTrace:
       at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)
       at System.Net.Sockets.TcpListener..ctor(IPAddress localaddr, Int32 port)
       at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
       at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback)
       at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider)
       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(Boolean SecureChannel)
       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
       at FSASYSTEM.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
       at System.AppDomain._nExecuteAssembly(Assembly 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.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException:

The truly confusing part is that this exception is generated before a single line of my code is executed. The Main method is generated via VB.NET (managed code) and I am not able to breakpoint it, trap errors within it (due to kernel / application context switching, as I understand it), nor symbolically debug into it.

A possible fix for this would be to target another .NET framework version, however I am really interested in understanding WHY this is happening. I fail to understand why such an error would only manifest itself in the debugger and not in the released code. And, yes, I have tried restarting the machine to ensure that there weren’t any left-over sockets still listening, causing binding failures.

Thank you in advance for your time and assistance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    After much work and a heaping helping of creative swearing, I was able to resolve my problem. Turns out that the issue had to do with running the code from a network location. Our company is moving to ClearCase, which stores all code in a pseudo-network drive. As it turns out, .NET 4 removed the ability to target assemblies on a ‘remote’ host by default. Since my code appeared to be on the M: drive, my guess is the runtime was rejecting the load of a particular assembly.

    To fix this, I added the following tag to my app.config:

    <runtime>
  <loadFromRemoteSources enabled="true"/>
</runtime>

    This appears to have fixed the issue. However, if anyone knows how that particular error message was generated as a result of resolving assemblies across a virtual network, I would love to hear it. Also, if the internet is to be believed, this security measure was introduced in .NET 4 yet it still caused problems despite the fact that I had explicitly targeted framework 2.0.

    Hopefully, this can save someone down the road a good amount of time. And, for your literary pleasure, some supplemental reading:

    http://through-the-interface.typepad.com/through_the_interface/2011/07/loading-blocked-and-network-hosted-assemblies-with-net-4.html

    Could not load file or assembly HRESULT: 0x80131515 (When adding controller to MVC project that has assembly references on network drive)

    • 0