Keeping Visual Studio Projects on a Network Drive

Question

We just did a move from storing all files locally to storing them on a network drive. The problem is that is where my Visual Studio projects are also stored now (no versioning system yet, working on that). I've heard of problems with doing this in the past, but never heard of a work-around. Is there a work around now?

Visual Studio is installed locally. The files are on a network drive. How can I get this to work?

Kriegspiel

What do you mean by "is there a workaround"? Workaround to what problem? – Soapstone

This IS a private share. No one but me uses it. – Kriegspiel

Answer 1

While we do use Source Control, we do also run all our projects from Network Drives (not shared directories, private directories on network drives). The network drives are backed up nightly, and also use Volume Shadow Copy, so if you need to revert to something before it made it's way to SC, then you can.

To get projects to run correctly with the right permission, follow these steps.

Basically, you've just got to map the shared directory to a drive, and then grant permission, based on that Url, to all code. Say you map to "N:\", then use "N:\*" as your Url pattern. It isn't obvious you need to wildcard, but you do.

Akeyla

you must go a long time without checking code into source control? I've never heard of someone putting into place shadow copy to enable rollback of code that isnt even committed yet. – Oberheim

We shadow copy hourly...I check in when a feature is finished. Sometimes VS crashes, and you no longer have an undo buffer. – Akeyla

VS has a recovery option now. I cant say i've ever lost any code in the past few years. that was a thing of the past – Emetine

Basically all our documents are on private network shares, with Volume Shadow Copy enabled. This is company-wide, not just for the developers. That extra safety net can come in handy. – Akeyla

I'll dig into this. As the really quick work-around I copied the project I need to the local drive. I'll see how this solution works when I am done and get back to you all. – Kriegspiel

The big thing for me is in order to keep my development projects on my physical hard drive in VirtualBox, you have to set up your shared folders as network drives. VS doesn't play nice with this, but I never set up CAS policy, so hopefully King's answer will help with that. I was having all sorts of issues building or doing regular tasks. – Fibroid

Answer 2

The question is rather generic so I'll give an answer to one issue I was facing.

I run Visual Studio 2010 using a Parallels virtual machine on my Mac while keeping all my projects on the mac side via a network share. Visual Studio however wouldn't load the projects assembly files from there. Trying to set the rights using "caspol" alone didn't help in my case.

What finally worked for me to allow Visual Studio to load assemblies from a network share was to edit the file "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" (assuming a default installation).

in the xml "<runtime>" section you have to add

<loadFromRemoteSources enabled="true"/>

You may have to change the permissions on that file to allow write access. Save the file. Restart Visual Studio.

Brusque

I also had to add this to WcfSvcHost.exe.config in order to debug a WCF service. – Bagasse

Do you know if there is an equivalent for VS2012? Or are remote sources enabled by default? – Mathewmathews

I'm in the exact situation but ur solution didn't work. I get the same errror "error occurred while creating or opening the C++ browsing database file \\192.168.56.128\export\workspace\myproject\.vs\RDPWrap\v16\Browse.VC.db." – Saddlery

Answer 3

In the interests of actually answering the question, I copied this comment from jcarle.com:

Trusting Network Shares with Visual Studio 2010 / .NET Framework v4.0

January 20, 2011, 4:10 pm If you are like me and you store all your code on a server, you will have likely learned about trusting a network share using CasPol.exe. However, when moving from Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) over to Visual Studio 2010 (.NET Framework 4.0), you may find yourself scratching your head.

If you are used to using the Visual Studio Command Prompt to quickly get to CasPol, you may find that some of your projects will not seem to respect your new FullTrust settings. The reason is that, unless you are carefully paying attention, the Visual Studio Command Prompt defaults to adding the .NET Framework 4.0 folder to its path. If your project is still running under .NET Framework 2.0/3.0/3.5, it will require setting CasPol for those versions as well. Just a note, I have also personally had more success with using 1 as a code group instead of 1.2.

To trust a network share for all versions of the .NET Framework, simply call CasPol for each version using the full path as below:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url file://YourSharePath* FullTrust
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CasPol -m -ag 1 -url file://YourSharePath* FullTrust

Taboo

Answer 4

I would not recommend doing that if you have (or even if you don't have) multiple people who are working on the projects. You're just asking for trouble.

If you're the only one working on it, on the other hand, you'll avoid much of the trouble. Performance is going to out the window, though. As far as how to get it to work, you just open the solution file from VS. You'll likely run into security issues, but can correct that using CASPOL. As I said, though, performance is going to be terrible. Again, not recommended at all.

Do yourself and your team a favor and install SVN or some other form of source control and put the code in there ASAP.

Oberheim

Answer 5

The problem is probably about the administrator context; one way to fix it is to get Visual Studio to browse to the drive in question some how. There are plenty of ways to do this but VS will magically be able to recognize mapped drive letters.

My solution is to go the the Debug Output Location in the Project Properties, click browse and go to my previously made output location on my network drive.

Chivalry

Answer 6

I understand this is an older thread, but this was the best thread I found when looking to solve a similar issue I had visual studio 2013 on a virtual box (using Win 8.1) and the code on the host machine (Win 7). Although I could open the solution, I could not compile. All of the other answers on this relate to older software, so I am adding this answer to update this frequently found question with the solution that worked for me.

Here's what I did; Made a registry entry to be able to use a UNC path as the current directory.

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Under the registry path: HKEY_CURRENT_USER \Software \Microsoft \Command Processor

add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex).

WARNING: If you enable this feature and start a Console that has a current directory of an UNC name, start applications from that Console, and then close the Console, it could cause problems in the applications started from that Console.

Found this information at link: http://support.microsoft.com/kb/156276

Ankylosis

Interesting. I have a #include issue with current directory seeming to change with network share builds vs local builds on a repository. Also seeing issues with /MP and /FS warnings with *.pdb files where /MP triggers warnings to use /FS switch although /MP should be setting /FS. – Favin

Answer 7

How about we rephrase this into a question that everyone can answer? I have the exact same problem as the initial poster.

I have a copy of VB 2008 (recently upgraded from VB6). If I store my solutions on the backed up network drive, then it won't run a single thing ever. It gives "partially trusted caller" errors for accessing a module, even when "allowpartiallytrustedcallers" is set in the assembly. If I store the files on my (not backed up) C:, then it will run wonderfully, until I put it on the share drive for everyone to use, and I'm back to my same problem.

This isn't a big request. I just want to be able to put a solution and executable on the share drive and run it without an absurd amount of nonsense about security. I shouldn't have to cram all my work into form files.

-Edit: I found the problem with why it was ignoring the AllowPartialllyTrustedCallers command. I'm trying to reference ADODB, which doesn't allow partially trusted. So, no network executable can access a database? What does Microsoft have against intranets anyway?

Zenger

Answer 8

I was facing the same issue just recently so this answer is more for the sake of keeping track of my own knowledge. Anyway, should soumeone find it useful, below is the issue and the solution.

Issue: NET 4.0 projects, SVN repo, checkout folders are on local drives, referenced assemblies are build by build server and available on a network drive. Visual studio on W7 is is able to add the reference but unable to build projects.

Solution: Since NET 4.0 does not automatically provide a sandbox anymore for network assemblies, you have to make those full-trusted via machine.config update. http://msdn.microsoft.com/en-us/library/dd409252.aspx

Beatrice

Answer 9

I had a similar problem with opening Visual Studio projects on a network drive, and I fixed it by creating a symbolic link on my local C:\ drive that points to the UNC directory

e.g.

mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"

then you can just open the project using the C:\Users\Self\Documents\ path, instead of the UNC path

(You have to be careful, because Visual Studio will automatically redirect you to the '\\domain.net..' path if you double click the symlink when you're browsing for the project. I had to copy paste the 'C:\Users\' path to get it to open with the drive letter path)

Jesuitism

Where I work, we all get our own private 'Documents' folder mapped to the network drive, so we aren't really using it as a shared version control solution, just an extra backup copy. (You can never be too careful) – Jesuitism

Answer 10

Are you having any specific problems?

If you allow more than one person to open the solution, your first problem will be that the .NCB file (Intellisense) will be locked exclusively and only one user will be able to browse the class tree. And of course you have the potential for one user's changes to overwrite the other user's changes.

Softwood

Answer 11

i found this helpful while trying use vc11 with parallels which run on mac: http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1, and specifically:

1) You can switch from local debugging to remote debugging and set the machine name as 'localhost'. This will do a remote deployment on your local machine (thus not using the project's directory). You don't need to install the Remote Debugger tools, nor start msvsmon for this to work on localhost.

Aldercy

Answer 12

If i understand you correctly, your Visual Studio project files are stored on the network drive and you are running them from there. This is what I do and don't have any problems. You will need to make sure that you have set the security policy. You can use Caspol to do this, or via the control panel-admin tools menu.

Soapstone

Answer 13

Don't do it. If you have source control (versioning), you do not want your files on a network drive. It totally bypasses all you want to achieve by using source control, because once your files are on a network drive, anyone can modify them .... even while you're currently building your project. Ka-boooom!

PS: this sounds like a typical case of over-engineering to me.

Aggrade

If using a Mac with a VM like parallels or VMWare, this isn't practical. You don't want to really have two code bases on a single dev machine. – Delladelle

Answer 14

"How can I get this to work?" You have a couple choices:

Choice A: 1. Move all files back to your local hard drive 2. Implement some type of backup software on your machine 3. Test said backup solution 4. keep on coding

Choice B: 1. Get a copy of one of the FREE source control products and implement it. 2. Make sure it's being backed up 3. Test it

Choice C: Use one of the many ONLINE source control repositories available. Google, SourceForge, CodePlex, something.

Publias

Answer 15

Well, my question would be why you are asking this. Is it not working when you are storing it on a network drive? I haven't tried this myself, and one problem I could envision would be that .NET code running from a network drive (ie. from the bin\Debug directory, also located on the network drive) would be running in a sandbox mode, unless you mess around with CASPOL (or use 3.5 SP1 which I hear has removed that obstacle).

If you have specific problems, ask about them. Never ask "Why is doing X not working?".

You're not saying if you're just one person or multiple persons accessing the same remote drive, but I'm assuming you're just one for each network directory. Is this correct? If not, no, there is no band-aid. Get version control, move the files back to a local disk.

Slapbang