VB.NET套接字异常仅在调试时 [英] VB.NET Socket Exception only while Debugging

查看:109
本文介绍了VB.NET套接字异常仅在调试时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近在将VB.NET解决方案从VS2005上转换为VS2010时遇到了一些相当令人困惑的行为。作为参考,该解决方案针对.NET 2.0,并且在转换之前已在调试器中正常运行。除了IDE更改之外,公司还认为可以将我的设备从Win XP(x86)刷新到Win 7(x64)。

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).

现在,我已经转换了VS2010的解决方案,调试器加载后立即收到Socket异常(详细信息如下)。这仅在调试器中发生。在发布配置中构建解决方案会产生一个MSI,它可以正确安装并运行,而不会出现错误。

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: 

真正令人困惑的部分是,此异常是在执行我的代码的一行之前生成的。 Main方法是通过VB.NET(托管代码)生成的,我无法对其进行断点处理,无法捕获其中的错误(据我所知,是由于内核/应用程序上下文切换所致),也无法对其进行符号调试。

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.

对此的一种可能的解决方法是针对另一个.NET Framework版本,但是我真的很想了解为什么会这样。我不明白为什么这样的错误只会在调试器中而不在发布的代码中显现。而且,是的,我尝试重新启动计算机以确保没有任何剩余的套接字仍在监听,从而导致绑定失败。

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.

推荐答案

经过大量的工作和对创意宣誓的大量帮助,我得以解决我的问题。原来,问题与从网络位置运行代码有关。我们公司正在迁移到ClearCase,它将所有代码存储在伪网络驱动器中。事实证明,.NET 4默认情况下取消了将目标定位于远程主机上的功能。由于我的代码似乎位于M:驱动器上,因此我猜想是运行时拒绝了特定程序集的加载。

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.

为解决此问题,我添加了以下标记到我的app.config:

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

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

这似乎已解决了该问题。但是,如果任何人都知道通过解析虚拟网络中的程序集是如何生成该特定错误消息的,我希望听到它。另外,如果要相信互联网,此安全措施是在.NET 4中引入的,尽管我明确地针对框架2.0,但它仍然引起了问题。

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-被阻止和网络托管的组件与net-4.html

无法加载文件或程序集HRESULT:0x80131515(将控制器添加到具有程序集引用的MVC项目中时在网络驱动器上)

这篇关于VB.NET套接字异常仅在调试时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆