将 Visual Studio 项目保存在网络驱动器上
我们刚刚从本地存储所有文件转向将它们存储在网络驱动器上。 问题是我的 Visual Studio 项目现在也存储在其中（还没有版本控制系统，正在处理）。 我过去听说过这样做会出现问题，但从未听说过解决方法。 现在有解决办法吗？
Visual Studio 安装在本地。 这些文件位于网络驱动器上。 我怎样才能让它发挥作用？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
虽然我们确实使用源代码管理，但我们也从网络驱动器（不是共享目录、网络驱动器上的私有目录）运行所有项目。 网络驱动器每晚都会备份，并且还使用卷影复制，因此如果您需要恢复到进入 SC 之前的状态，那么您就可以做到。
要使项目以正确的权限正确运行，请按照 这些步骤。
基本上，您只需将共享目录映射到驱动器，然后根据该 Url 向所有代码授予权限。 假设您映射到“N:\”，然后使用“N:\*”作为您的 URL 模式。 显然您需要通配符，但您确实需要。
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.
这个问题相当笼统，所以我将回答我面临的一个问题。
我在 Mac 上使用 Parallels 虚拟机运行 Visual Studio 2010，同时通过网络共享将所有项目保留在 Mac 端。 然而，Visual Studio 不会从那里加载项目程序集文件。 尝试单独使用“caspol”设置权限对我的情况没有帮助。
最终让 Visual Studio 从网络共享加载程序集对我有用的是编辑文件
“C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config”（假设默认安装）。
在 xml“<运行时>”中 您必须添加的部分
您可能必须更改该文件的权限以允许写入访问。 保存文件。 重新启动 Visual Studio。
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
You may have to change the permissions on that file to allow write access. Save the file. Restart Visual Studio.
为了真正回答这个问题，我从 jcarle.com 复制了这条评论：
Trusting Network Shares with Visual Studio 2010 / .NET Framework v4.0
一月 20, 2011, 4:10 pm
如果您像我一样并将所有代码存储在服务器上，您可能已经了解了如何使用 CasPol.exe 信任网络共享。 但是，当从 Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) 迁移到 Visual Studio 2010 (.NET Framework 4.0) 时，您可能会发现自己摸不着头脑。
如果您习惯使用 Visual Studio 命令提示符快速访问 CasPol，您可能会发现某些项目似乎不尊重新的 FullTrust 设置。 原因是，除非您仔细注意，否则 Visual Studio 命令提示符默认会将 .NET Framework 4.0 文件夹添加到其路径中。 如果您的项目仍在 .NET Framework 2.0/3.0/3.5 下运行，则还需要为这些版本设置 CasPol。 请注意，我个人在使用 1 而不是 1.2 作为代码组方面也取得了更大的成功。
要信任 .NET Framework 所有版本的网络共享，只需使用以下完整路径为每个版本调用 CasPol：
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:
如果您有（或者即使没有）多个人正在从事该项目，我不建议您这样做。 你只是自找麻烦。
另一方面，如果你是唯一一个在这方面工作的人，你就会避免很多麻烦。 不过，性能将会被抛到九霄云外。 至于如何让它工作，你只需从 VS 打开解决方案文件即可。 您可能会遇到安全问题，但可以使用 CASPOL 纠正该问题。 但正如我所说，性能将会很糟糕。 再说一次，根本不推荐。
帮你自己和你的团队一个忙，安装 SVN 或其他形式的源代码管理，并尽快将代码放入其中。
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.
我知道这是一个较旧的线程，但这是我在寻找解决类似问题时发现的最好的线程，我在虚拟机上使用 Visual Studio 2013（使用 Win 8.1）并在主机（Win 7）上使用代码。 虽然我可以打开解决方案，但无法编译。 关于此问题的所有其他答案都与旧软件有关，因此我添加此答案，以使用对我有用的解决方案来更新这个常见问题。
这就是我所做的； 创建一个注册表项以便能够使用 UNC 路径作为当前目录。
警告：注册表编辑器使用不当可能会导致严重的系统范围问题，可能需要重新安装 Windows NT 才能纠正这些问题。 Microsoft 无法保证因使用注册表编辑器而产生的任何问题都能得到解决。 使用此工具的风险由您自行承担。
注册表路径下：
HKEY_CURRENT_USER
\软件
\微软
\命令处理器
添加值DisableUNCCheck REG_DWORD 并将该值设置为0 x 1（十六进制）。
警告：如果启用此功能并启动当前目录为 UNC 名称的控制台，从该控制台启动应用程序，然后关闭该控制台，则可能会导致从该控制台启动的应用程序出现问题。
在链接中找到此信息：http://support.microsoft.com/kb/156276
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
问题可能与管理员上下文有关； 解决此问题的一种方法是让 Visual Studio 以某种方式浏览到有问题的驱动器。 有很多方法可以做到这一点，但 VS 将神奇地能够识别映射的驱动器号。
我的解决方案是转到“项目属性”中的“调试输出位置”，单击“浏览”并转到我之前在网络驱动器上创建的输出位置。
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.
我们将其改写为一个每个人都可以回答的问题怎么样？ 我遇到了与最初的海报完全相同的问题。
我有一份 VB 2008（最近从 VB6 升级）。 如果我将解决方案存储在备份的网络驱动器上，那么它永远不会运行任何东西。 即使在程序集中设置了“allowpartiallytrustedcallers”，它也会在访问模块时给出“部分受信任的调用者”错误。 如果我将文件存储在我的（未备份的）C: 上，那么它会运行得很好，直到我将它放在共享驱动器上供每个人使用，然后我又回到了同样的问题。
这不是一个大要求。 我只是希望能够将解决方案和可执行文件放在共享驱动器上并运行它，而无需对安全性进行大量荒谬的废话。 我不应该把所有的工作都塞进表单文件中。
-编辑：我发现了为什么它忽略AllowPartialllyTrustedCallers命令的问题。 我正在尝试引用 ADODB，它不允许部分信任。 那么，没有网络可执行文件可以访问数据库吗？ 微软到底对内联网有什么抵抗力呢？
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?
我最近遇到了同样的问题，所以这个答案更多的是为了跟踪我自己的知识。 无论如何，如果有人觉得它有用，下面是问题和解决方案。
问题：
NET 4.0 项目、SVN 存储库、签出文件夹位于本地驱动器上，引用的程序集由构建服务器构建并在网络驱动器上可用。 W7 上的 Visual Studio 能够添加引用，但无法构建项目。
解决方案：
由于 NET 4.0 不再自动为网络程序集提供沙箱，因此您必须通过 machine.config 更新使这些程序集完全受信任。 http://msdn.microsoft.com/en-us/library/dd409252.aspx
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
我在网络驱动器上打开 Visual Studio 项目时遇到了类似的问题，我通过在本地 C:\ 驱动器上创建一个指向 UNC 目录的符号链接来修复该问题，
例如
那么你可以使用 C:\Users\Self\Documents\ 路径而不是 UNC 路径打开项目
（你必须小心，因为 Visual Studio 会自动将你重定向到“\\domain.net..”路径（如果您在浏览项目时双击符号链接，我必须复制粘贴“C:\Users\”路径才能使用驱动器号路径打开它）。
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.
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)
您有任何具体问题吗？
如果您允许多个人打开解决方案，您的第一个问题将是 .NCB 文件（Intellisense）将被独占锁定，并且只有一个用户能够浏览类树。 当然，一个用户的更改有可能覆盖另一用户的更改。
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.
我在尝试将 vc11 与在 mac 上运行的并行程序一起使用时发现这很有帮助：
http://social.msdn .microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1，具体来说：
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:
如果我理解正确的话，您的 Visual Studio 项目文件存储在网络驱动器上，您可以从那里运行它们。 这就是我所做的，没有任何问题。 您需要确保已设置安全策略。 您可以使用 Caspol 来执行此操作，或者通过控制面板-管理工具菜单。
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.
不要这样做。 如果您有源代码控制（版本控制），您不希望您的文件位于网络驱动器上。 它完全绕过了您想要通过使用源代码控制实现的所有目标，因为一旦您的文件位于网络驱动器上，任何人都可以修改它们......即使您当前正在构建项目。 卡-布姆！
PS：对我来说，这听起来像是过度设计的典型案例。
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.
“我怎样才能让它发挥作用？”
你有几个选择：
选择 A：
1. 将所有文件移回本地硬盘
2. 在您的计算机上安装某种类型的备份软件
3. 测试上述备份方案
4. 继续编码
选项B：
1. 获取一份免费源代码控制产品的副本并实施它。
2.确保已备份
3.测试
选项C：
使用众多可用的在线源代码控制存储库之一。 Google、SourceForge、CodePlex 等。
"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.
好吧，我的问题是你为什么问这个。 当您将其存储在网络驱动器上时它不起作用吗？ 我自己还没有尝试过这一点，我可以想象的一个问题是从网络驱动器运行的 .NET 代码（即从 bin\Debug 目录，也位于网络驱动器上）将以沙箱模式运行，除非你用 CASPOL 搞乱（或者使用 3.5 SP1，我听说它已经消除了这个障碍）。
如果您有具体问题，请询问。 永远不要问“为什么做 X 不起作用？”。
您并不是说您是一个人还是多个人访问同一远程驱动器，但我假设您只是每个网络目录的一个人。 它是否正确？ 如果没有，不，没有创可贴。 获取版本控制，将文件移回本地磁盘。
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.