如何从网络共享调试 Visual Studio 2010 中的解决方案?

发布于 2024-09-05 05:04:29 字数 1631 浏览 2 评论 0 原文

我最近购买了一台新的 Mac 笔记本电脑,并在 Parallels 虚拟机中运行 VS2010。它对我来说基本上运行良好,但我在调试特定项目类型时遇到了一些问题,这与项目是通过网络共享访问的事实有关。测试项目无法运行,因为测试运行程序无法加载测试的 DLL。 Web 项目无法在 Visual Studio 迷你 Web 服务器中运行,引发以下异常:

“加载配置文件时发生错误:无法开始监视对 path\to\web.config 的更改”。

I我花了一个晚上在网上搜寻,但运气不佳。阅读这些 两篇 帖子,我尝试了通常的 CasPol 更改,但随后发现 这篇文章来自早期 VS2010 测试版之一,表明 CasPol 是.NET 4.0 和 VS2010 中不再需要/支持。

网络共享可通过映射驱动器和 UNC 路径访问。 UNC 路径的主机是 .pfs;根据 这篇文章 Windows 对待主机名以点开头表示源自 Internet 区域。

虚拟机在管理员帐户下运行其应用程序,该帐户似乎拥有网络共享上创建、读取、写入和删除文件和文件夹的所有必要权限。我说“似乎有”,因为我无法通过资源管理器查看相应文件夹的安全属性:“安全”选项卡不存在。

有没有人成功地从 VS2010 中的网络共享加载和调试 Web 和测试项目?

更新:我尝试使用 MacBook 的 IP 地址在单独的本机 Windows 计算机上加载 VS2010 中的解决方案,结果好坏参半。测试项目再次无法运行,并出现错误:

加载 \\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll 时出错:无法加载文件或程序集 'file://\\192.168 .0.4\alastair\Code\project\bin\Debug\Tests.dll' 或其依赖项之一。不支持操作。 (HRESULT 异常:0x80131515)

但是,ASP.NET MVC 项目在此设置中按预期正确运行,并且如果我使用 MacBook 的 NETBIOS 名称,我会得到完全相同的结果。

当然,为了做到这一点,我必须在 Snow Leopard 中启用 SMB 共享,这不需要访问我的 Parallels VM 中的位置。也许我需要调整 Parallels 中的某些设置才能更改共享权限?

我还向版主标记了这个问题,要求将其移至 StackOverflow;我认为这可能是一个比 SuperUser 更合适的论坛。

I've recently got a new Mac laptop and am running VS2010 in a Parallels virtual machine. It's mostly working out well for me, but I'm having some problems with debugging specific project types, related to the fact that the projects are being accessed via a network share. Test projects don't run because the test runner can't load the tests' DLL. Web projects fail to run in the Visual Studio mini web server, throwing the following exception:

'An error occurred loading a configuration file: Failed to start monitoring changes to path\to\web.config'.

I've spent the evening trawling the web with little luck on this. After reading these two posts, I tried out the usual CasPol changes, but then found this post from one of the early VS2010 betas indicating that CasPol is no longer needed/supported in .NET 4.0 and VS2010.

The network share is accessible via both a mapped drive and the UNC path. The host for the UNC path is .pfs; according to this post Windows treats host names starting with a dot as originating in the Internet Zone.

The virtual machine runs its applications under the administrator account, which appears to have all the necessary permissions on the network share to create, read, write and delete files and folders. I say "appears to have" as I can't view the Security Properties of the appropriate folder via Explorer: the Security tab just isn't present.

Has anyone managed to successfully load and debug web and test projects from a network share in VS2010?

UPDATE: I tried loading the solutions in VS2010 on a separate native Windows machine using the IP address of my MacBook, with mixed results. The test project again failed to run with the error:

Error loading \\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll: Could not load file or assembly 'file://\\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

However, the ASP.NET MVC project runs correctly as expected in this setting, and I get exactly the same results here if I use the NETBIOS name of the MacBook.

Of course, in order to do this, I had to enable SMB sharing in Snow Leopard, which wasn't required to access the location in my Parallels VM. Maybe there's some setting in Parallels that I need to tweak to change permissions on the share?

I've also flagged this question for the moderators to request it be moved to StackOverflow; I think it might be a more appropriate forum than SuperUser.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

在巴黎塔顶看东京樱花 2024-09-12 05:04:29

尝试在 devenv.exe.config 的运行时元素下设置 ,如 这个问题。它为我解决了这个问题...从共享加载项目时,Visual Studio 仍然会警告我,但现在可以运行测试。

Try setting <loadFromRemoteSources enabled="true"/> under the runtime element of devenv.exe.config, as suggested in the answer to this question. It fixed the issue for me... Visual Studio still warns me when loading a project from the share, but running tests now works.

假扮的天使 2024-09-12 05:04:29

这假设问题实际上是 Windows“将以点开头的主机名视为源自 Internet 区域”。可能是别的东西,但下面的选项(3)应该是证明(反)证明这一点是问题的一部分的快速方法。


句点 (.) 不是 DNS 主机名中常用的字符;它通常被解释为主机名和域名之间的分隔符(例如,localhost.localdomain)。 DNS 主机名通常仅限于“LDH”——字母、数字和连字符。

UNC 路径和 Windows 网络 (NetBIOS) 名称可能会遇到类似的问题。根据 RFC3696,句点是合法的,但您需要转义主机名中使用的句点根据 RFC1035。如果我正确阅读 RFC1035,您的主机名应该是 \.pfs 而不是 .pfs

我想知道如果您

  1. 将主机名(在共享服务器上)更改为不包含点的名称(并相应更新客户端),
  2. 更改共享的 UNC 路径(在客户端上)使用正确的句点转义序列,或
  3. 更改共享的 UNC 路径(在客户端上)以使用 IP 地址而不是主机名。

This assumes the issue is really with Windows "treat[ing] host names starting with a dot as originating in the Internet Zone". It may be something else, but option (3) below should be a quick means of (dis)proving this as part of the problem.


The period (.) is not an oft-used character in a DNS hostname; it's usually interpreted as a separator between hostname and domainname (eg, localhost.localdomain). DNS hostnames are generally restricted to "LDH" -- Letters, Digits, and Hyphens.

UNC paths and Windows Networking (NetBIOS) names may suffer from similar problems. According to RFC3696, periods are legal, but you need to escape periods used within a hostname according to RFC1035. If I'm reading RFC1035 correctly, your hostname should be \.pfs instead of .pfs.

I'd wonder if your issues would work OK if you

  1. changed the hostname (on the share server) to something not including a dot (and updated the client accordingly),
  2. changed the UNC path to the share (on the client) to use the proper escape sequence for periods, or
  3. changed the UNC path to the share (on the client) to use the IP address instead of the hostname.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文