我正在尝试构建一个引用NuGet包的Visual Studio解决方案。我从其他人的计算机上复制了解决方案（通过Git，但我不知道复制方法在这里是否重要）。当我尝试构建解决方案时，我不断收到此命令：
Error 3 The command ""D:\Custom Work\MySolution\Project\.nuget\nuget.exe" install
"D:\Custom Work\MySolution\Project\AAIA.Model\packages.config" -source ""
-RequireConsent -o "D:\Custom Work\MySolution\Project\packages"" exited with code 5.
Please verify that you have sufficient rights to run this command.
我检查了所有文件夹的权限，它们似乎都很好。也没有共享违规; Visual Studio 2010是唯一触及这些文件和文件夹的程序。为什么会这样？
您的克隆解决方案可能无法传递nuget.exe文件的Windows'执行'权限。
如果您在cygwin中使用git clone进行克隆，然后尝试使用visual studio进行打开和构建，则不会为nuget.exe正确设置权限。它的'linux'不支持windows的可执行权限。如果使用git-extensions之类的东西进行克隆，则可以避免此问题，因为它是为windows构建的并支持可执行权限。
或者在我的情况下，<solution root>\.nuget\nuget.exe文件已损坏。
<solution root>\.nuget\nuget.exe文件可执行位问题与Cygwin，Linux或其他方面无关。
Windows和Linux（以及所有Unixen）都有可执行程序文件的概念，这些文件在文件系统上被标记。当git检出工作空间中的树时，它会将其blob写为文件，并根据存储在树对象中的“模式”设置它们的permissions。
“模式”基于Unix modes，但是more limited，可能是为了便于携带（只有三种模式：普通文件，可执行文件和符号链接）。 Windows实现可以毫无困难地使用它来相应地设置NTFS file permissions。
这应该是故事的结尾。可执行文件在git存储库中标记为可执行文件，并在所有用户系统上自动设置。
但是，VS团队显然决定自动将一些（所有？）新签出的文件设置为可执行文件，即使它们未在存储库中标记为可执行文件。在理论上听起来不错，很多人忘记或者不太了解“权限”的概念。
我说“显然”因为它似乎与继承权限有关。可能是他们没有真正的意图去做，而是忘了自己设置适当的权限。
实际上，这意味着只要他们全部使用Visual Studio来操纵存储库，就会有更多人忘记并保持不经意。使用任何其他工具（包括官方git命令）的人将无法立即执行程序，并且会被错误地告知使用Visual Studio而不是实际将文件标记为存储库中的可执行文件。
相反，当使用VS将它们从存储库中检出时，似乎没有办法将文件自动设置为可执行文件。
有一些伏都教可以防止git以这种方式设置时检测实际权限。这可能与权限继承和特殊权限有关。使用文件资源管理器的安全窗格获取文件的属性以及git的源代码，如果这是一个功能或错误，您可能能够解决问题。 （IMO，我认为工作空间中的权限应该与存储库中的权限相匹配，这是他们使用官方git命令时的权限。）
使用Windows的文件资源管理器，使用文件属性窗口及其安全窗格。使用Cygwin或任何其他Unix-y环境，使用chmod。
chmod +x .nuget/NuGet.exe
（或者使用文件资源管理器以git检测它的方式正确设置可执行权限 - 正如chmod所做的那样。）
git应检测更改并将其解释为模式更改。 git diff收益率：
diff --git a/.nuget/NuGet.exe b/.nuget/NuGet.exe
old mode 100644
new mode 100755
现在提交它并将其推送到上游，以便其他人不必这样做。
在将来，尝试使用官方的git clone命令或者更好地研究这个，以便为任何能够以理智的方式解决这个问题的人写一个正确的错误报告。可能双方都有事要做（git可能需要更聪明地了解Windows上的继承权限，并且在结帐时设置Visual Studio可能需要更加小心）。
确保您的.nuget\nuget.exe文件具有可执行权限。通过复制，您可能已更改了所有权或权限。
这里拒绝访问NuGet的是Visual Studio配置设置。