How can I debug solutions in Visual Studio 2010 from a network share?
Asked Answered
G

2

7

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.

Gold answered 9/6, 2010 at 23:24 Comment(3)
@alastairs: sorry, i saw the flag prior to my answer, but didn't realize the flag was from the OP. migrating shortly.Goldarned
Have you solved your issue? I have the same problem. thxParcae
The devenv.exe.config fix in the accepted answer below seems to have resolved the problem. Thanks @Daniel Plaisted!Gold
O
4

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.

Olin answered 15/7, 2010 at 23:46 Comment(2)
Oh, this sounds interesting! Thanks for the tip, I'll be sure to check it out when I get home!Gold
That worked fine for me. But I had some major problems to be able to edit the devenv.exe.config... Access denied greated me. My workaround was to open Notepad.exe "as Administrator" then i was able to edit the file and get it to workRaid
G
0

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.
Goldarned answered 10/6, 2010 at 19:16 Comment(1)
Thanks for the answer. I've updated my question with my response, which was a bit long for a comment!Gold

© 2022 - 2024 — McMap. All rights reserved.