views:

3141

answers:

9

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

So my VS is installed locally. The files are on a network drive. How can I get this to work?

EDIT: I know what SHOULD be done, but is there a band-aid I can put on right now to fix this and maintain the network drive?

EDIT 2: I am sure I am not understanding something, but Bob King has the right idea. I'll work with the lead web developer when he gets back into the office to figure out a temporary solution until we get some sort of version control setup. Thanks for the ideas.

+6  A: 

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.

EDIT: I'll partially retract my comments. Bob King explains below the reason they run VS projects from a network drive and it makes sense. I would say unless you're doing it for a specific reason like Bob, stay away from it. Otherwise, get your ducks in a row before setting up such a development environment.

Kilhoffer
A: 

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.

HAdes
+3  A: 

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.

steffenj
A: 

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.

Lasse V. Karlsen
A: 

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

Chris Lively
+1  A: 

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.

jmatthias
+6  A: 

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.

Bob King
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.
Kilhoffer
We shadow copy hourly...I check in when a feature is finished. Sometimes VS crashes, and you no longer have an undo buffer.
Bob King
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
I have lost hours worth of work to a hard crash of VS that took out the recovery versions as well ...
MagicKat
I guess if I kept losing code, too, I would have to implement something similar. Luckily, that hasnt happened to me yet. Gotta do what you gotta do, right? Can't fault you for that!
Kilhoffer
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.
Bob King
Makes sense, Bob. You get an upvote from me.
Kilhoffer
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.
Mike Wills
We've got that setup too, but it's a pain when the network drive goes down. Also, it seems a lot slower to open with large propjects.
Greg
A: 

You should be warned that some feature in Visual Studio will refuse to work with network drive.

For example, mdf file of SQL Express user instance must be located in local drive.

For another example, if you use UNC path, you have to make sure they are short enought.

Dennis Cheung
+1  A: 

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?

Ben