CAS not working for VS2010 mapped drive

Question

I have a project using subsonic that I developed in Visual Studio 2008 on C: drive. No problem there. I\'ve just upgraded to Visual Studio 2010 (and as my computer coincide

Answer 1

For posterity, here are some results of my investigations.

Mapped drives in VS 2010:

• there is an initial message about loading a project from an unsafe location. This is fixed using CASPOL as described. CASPOL is pretty flexible with its URLs and accepts both the shown formats. CASPOL is disabled in .NET 4 by default so the settings won't make a difference (see reasons here).
• after that there are several more problems, I didn't document them but after fixing each one, another springs up. loadFromRemoteSources fixed one message, but nothing I did could touch 'Failed to start monitoring changes ...'. As part of this, Christoph's answer is probably correct (at least for .NET 2) in that you'd probably have to set up each assembly on the drive, which is totally impractical for a VS project drive.

So, not surprisingly, I think it is just going to be too painful to store VS projects on a mapped drive. Source control and a local project are the way to go. Frankly, the lack of undo on a networked drive is a pain for dev work as well IMO.

BUT

the original issue was not so much that I needed a networked drive as that I didn't want to store the project on C: of my VM (ie. I wanted to be able to back up the data separately from the VM based drive image).

The answer staring me in the face the whole time, was to create a second virtual disk and attach it to the VM as G:. It's a local drive, so I don't get all the trust issues, but I get full data separation. I keep all the data on that drive in a Dropbox folder, giving me full realtime offsite backup as well, and that's me happy.

Answer 2

Maybe I'm wrong (I did not look this up) but I think you need to work with strong names when working on mapped drives. Like

caspol -m -q -ag My_Machine_Zone -url g:\* Nothing -n "GDrive"

caspol -m -q -ag "GDrive" -strong -file "<pathToFile>" "<assemblyStrongName>" "<assemblyVersion>" FullTrust -n "GDriveFileX" -d "Code Group for fileX"

I would always create a toplevel group so you can easily modify or remove the policy later on. I think it makes sense not to allow to give full trust to a mapped drive based on the uri e ven though this is painfull.

If possible use something more modern.