When the untrusted project location is on a local file path this usually means the files and folders were extracted from an untrusted ZIP file. Right-click on the ZIP file and choose Properties to obtain the Properties dialog. If you see an Unblock button enabled then this is the cause of your troubles. Click the Unblock button. Delete the files and folders you previously extracted and any copies you made (which will also exhibit the problem) and repeat the extraction and copying process. You should find the problem is resolved.

12/09/2007 - I just wanted to concur, this problem happened to me when I tried to load a solution from the Beta 3 Entity Samples (http://www.codeplex.com/adonetsamples/Release/ProjectReleases.aspx?ReleaseId=8858) that I had extracted from the zip file onto a Vista machine. The instructions above solved the issue.

Just FYI--I tried adding a code group at the user level rather than machine w/the proper membership condition & it looks like it did not have the desired effect. So you really do have to do it at 'machine' level.

This doesn't appear to work when the share is referenced through the Distributed File System unless the DFS root is included in machine's Intranet zone.

Also it seems that if .Net 2.0 is installed side by side with .Net 1.1, the configuration must be done using the .Net 2.0 tools.

Since the CASPOL and MSCORCFG.MSC are framework specific, it is necessary to open either a visual studio of framework specific prompt. The documentation should include this.

I just wanted to clarify Tatworths comments - thanks for them, as that helped me find the solution, but it still took a while to get there.

I have VS2003 & 2008 installed on the same machine, when I tried opening MSCORCFG.MSC, caspol.exe, or using the .net config tools in Admin Tools I always got version 1.1 tools without knowing, and still got an error with VS2008. What I eventually realised was that I needed to open command prompt, and then run vsvars32.bat from the c:|Program Files\Visual Studio\Common7\Tools Folders specific to the version of VS that I had the problem with.

After that running Caspol.exe sorted out my permissions.

Hope that helps

This problem has bugged me for 3 years now and I've finally fixed it thanks to this article. However, I wasn't specifically using a UNC share, just a local network drive mapped to a drive letter.

I chose "All Code" as the Membership condition and "Full Trust" as the permission set. It fixed my problem.

Is there a safer set of settings I should try using? Also, I spoke with someone who "changed the security settings" and didn't have this problem anymore... but can't remember what he did. Is there a setting in Visual Studio 2008 to fix this?

Does this also mean that if I simply add "file://x:/" as a trusted site in Internet Explorer I can get a similar solution?

I love .net but this kind of ill-conceived security system will kill .net desktop applications on windows pretty soon. The hackers who know how to get round your previous terrible security implementations know how to get round this stuff too. All you're doing is making it harder for people to develop and deploy software for your platform. Why not fix the buffer overflows all over your kernel first?

The issue is the unzipped data needs to be removed from the untrusted zone.

Sysinternals has a utility called streams.exe to remove the untrusted zone recursively.

http://intellects.in/2008/11/06/utility-to-recursively-unblock-files-downloaded-from-internet/

See http://www.gnegg.ch/2008/04/vmware-shared-folders-and-visual-studio/
for information on getting around problems trying to use Visual Studio in a VM (VM Fusion under MACOS) accessing the files using \\.host\Shared Folders\userfiles

Seems Microsoft treats the UNC name \\.host as an INTERNET reference and not a INTRANET reference.

Furthermore, Visual Studio will not PARSE \\.host because of the '.'; you need to use another drive name or share the folders using a different UNC name.

How I wish the world could adopt consistent rules for UNCs