How do I trust network shares under visual studio 2010 / .NET 4.0 beta 1? RRS feed

  • General discussion

  • From my reading, I understand that Caspol is no longer used to trust network drives, and that they are trusted by default. Only problem is... they aren't!

    I have folder redirection enabled for "My Documents" under Windows 7 / Vista to a UNC path (\\<server>\Users\<name>\Documents). When I try to open any projects stored there, I get "this location is not trusted" error which is familiar to me from setting up VS2008. I tried running Caspol.exe anyway, and it didn't work. This occurs even when creating new projects (none of the executables are from the internet zone or anything).

    This server share is included in the IE intranet zone, for what it is worth. I'm working off local storage for now but it isn't ideal. Any tips?
    Tuesday, September 8, 2009 1:41 AM

All replies

  • Also tried changing the paths in visual studio to use a mounted drive letter... still throws the error on starting visual studio, and still won't compile my projects unless I move them to local storage.
    Tuesday, September 8, 2009 4:40 PM
  • http://msdn.microsoft.com/en-us/library/bs2bkwxc(VS.100).aspx Says you need to run CasPol.exe, but I think it is just a copy/paste from the documentation on previous versions (it also recommends using MsCorCFG.msc, which hasn't been provided since what, the .NET 2.0 SDK?). Anyway, the instructions don't work (but work great for VS 2008, which is installed on the same machine).
    Tuesday, September 8, 2009 5:03 PM
  • Hi Jeremy

    Thanks for dogfooding Dev10.

    If you accept the changes by selecting the "Load project normally" option, it won't bother you again, for the same project that is. You can also disable the dialog from Tools - Options - Project and Solutions - "Warn user when the project location is not trusted".

    The "project load security dialog" has suffered major changes during the Beta2 milestone, you'll find about them soon.

    Visual Studio: Project and Build
    Friday, September 11, 2009 11:49 PM
  • unfortunately this doesn't seem to work... the solution says something about how i can't load the assemblies I have linked (multiple projects) unless I move it to local storage. I can provide the exact message if you would like, but I do not have it with me right now.
    Thursday, September 17, 2009 8:52 PM
  • I am having the same problem, however I am able to compile all my code just fine when it is in Debug mode.

    When I change to release mode I get

    Error 35 Could not load file or assembly 'file:///Y:\Bibliofile\Source\trunk\Bibliofile\obj\Release\Bibliofile.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) Y:\Bibliofile\Source\trunk\Bibliofile\SGEN Bibliofile

    I also tried caspol, (which worked when I had this problem with VS2008) and it did not work.

    Sunday, October 18, 2009 10:08 PM
  • This isn't a policy issue. As noted. CAS Policy isn't normally enabled in 4.0 so code running in the default host should have access to any network share that windows policy or ACLs allow.

    These issues are either from the VS Shell or Project system - or there is some issue with Windows permissions on the shares. Please verify that you have permissions to create/delete files and folders on these shares outside of VS.

    Can you supply us with a project that reproduces the issue? A connect bug with the project attached would be great or you can email me the project (shorne is my email and the domain is microsoft.com).


    Steve Horne
    Microsoft CLR Beta Support

    Friday, October 23, 2009 10:25 PM
  • oy! i'm having the same problem!! my project is on a network drive, and i'm trying to run the tests, but it won't load the test.dll!!
    Sunday, January 17, 2010 7:24 AM
  • The original question didn't say anything about DLL which won't load. This is likely different issue.
    Please start a new thread and add full description and (all) steps to reproduce your problem.

    Sunday, January 17, 2010 8:27 AM