【问题标题】:Why does ExecutionPolicy behavior vary across projects in Visual Studio?为什么 ExecutionPolicy 行为因 Visual Studio 中的项目而异?
【发布时间】:2012-05-04 22:41:55
【问题描述】:

我在特定 PC 上使用 NuGet 已经有一段时间了。现在,我在 VS2010 中创建了一个新项目(如果重要的话,它是一个使用单页应用程序模板的 MVC 4 Beta 项目)。当我选择

工具/库包管理器/包管理器控制台

控制台窗口打开但显示错误:

文件 C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.7.30402.9028\Modules\NuGet\profile.ps1 无法加载 因为在此系统上禁用了脚本的执行。请 有关详细信息,请参阅“get-help about_signing”。

但是,其他项目仍然可以打开和使用包管理器控制台。

在每种情况下,VS2010 都以同一用户身份运行。

如果我打开命令提示符(使用运行 VS2010 的同一帐户),启动 PowerShell,然后输入命令

获取执行策略

PowerShell 返回

受限

我基于Scott Hanselman blog 的理解是,如果 ExecutionPolicy 受到限制,则脚本根本不应该运行。

为什么现有项目能够使用包管理器控制台,而新项目却不能?

更新:将 ExecutionPolicy 更改为 AllSigned 重新启动 VS2010 解决了眼前的问题,但我的主要问题是为什么其他项目能够绕过已建立的 ExecutionPolicy。 VS2010没有以管理员身份运行。

【问题讨论】:

  • NuGet 包管理器控制台将 PowerShell 的执行策略设置为 RemoteSigned,并且范围设置为 Process,因此它只影响 Visual Studio。更改 Visual Studio 的策略不需要 Visual Studio 以管理员身份运行。您从命令行看到的执行策略不需要更改。在我的机器上,这设置为受限。但是,这些都不能解释为什么您的新项目会显示此错误而现有项目却没有。
  • 如果非管理员用户可以在每个进程的基础上更改策略,那么在机器范围内设置策略有什么意义?
  • 组策略设置可以防止您覆盖当前进程的设置,但本地计算机设置本身不能。请参阅以下 msdn 帖子中的执行策略优先级部分 - technet.microsoft.com/en-us/library/dd347641.aspx
  • 我很高兴看到这里实际上没有接受答案,就像我看到很多人在有人提供包含解决方法但实际上并没有回答问题的答案时所做的那样真正的问题。在过去的几个月里,我已经多次遇到这种情况,无法弄清楚发生了什么。在 VS2014 上,鉴于多个项目的库已过时,我会收到一些 ExecutionPolicy 错误消息,而另一些则可以成功更新。安装包在新的解决方案和项目中工作正常,但不适用于现有的。我想要一个答案,而不是“试试这个”的建议。

标签: visual-studio-2010 nuget


【解决方案1】:

我遇到了同样的问题并通过以下方式解决了:

  • 以管理员身份打开 Powershell
  • 输入以下命令“Set-ExecutionPolicy RemoteSigned”
  • 重新启动 Visual Studio,包管理器控制台按预期工作

需要注意的是,Powershell 会给你一个警告

“执行策略有助于保护您免受您不信任的脚本的侵害。更改执行策略可能会使您面临 about_Execution_Policies 帮助主题中描述的安全风险。您要更改执行策略吗?”

并且应该小心启用此功能,并应阅读有关安全风险的帮助主题中的更多信息。

【讨论】:

  • +1 哦,是的!这是 Windows。我只需要重新启动东西,直到它工作。 ;)
  • VS 不需要重启。
  • 我起初以为这是一些复杂的权限问题,但后来我意识到,我只需要关闭所有 VS2013 实例,签入 processexplorer 并杀死挂起的进程,也许稍等一下:- ) 当我重新启动第一个 VS2013 时,一切又恢复了正常。很奇怪。
  • 如果您已经以管理员身份运行 Visual Studio,您可以直接在包管理器中运行该命令,而无需重新启动 Visual Studio。
  • 为我工作!!谢谢
【解决方案2】:

除了Murries' answer,我发现jellonek's post(在另一个线程上)很有帮助。您可能需要更改不同版本 PowerShell 的权限(32 位和 64 位版本需要不同的权限)。

来自How to Tell if PowerShell is 32-bit or 64-bit

  • 64 位 PowerShell 路径:C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • 32 位 PowerShell 路径:C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

另外,BOTH 应该可以工作:

  • Set-ExecutionPolicy RemoteSigned
  • Set-ExecutionPolicy 不受限制

【讨论】:

  • 我尝试只运行“Set-ExecutionPolicy RemoteSigned”,但没有成功。我可以确认我还必须运行“Set-ExecutionPolicy Unrestricted”。
  • +1 我今天第一次遇到这个错误,我显然只在两个 powershell 之一上设置了我的 powershell 策略......我刚刚注意到你有 32 位和 64 位翻转你的帖子?你有 SysWow64 的 32 位和 System32 的 64 位。这似乎倒退了。
  • 谢谢克里斯。我从链接的文章中复制了它,它们被翻转了。这已更新。
【解决方案3】:

解决此问题的另一种方法是将 Regedit 文件与以下内容合并:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"

(创建一个名为 NuGetPowerShellFix.txt 的文本文件,将上面的内容复制粘贴到其中,重命名为 NuGetPowerShellFix.reg,然后运行。)


合并以上文件后,重启Visual Studio。

【讨论】:

    【解决方案4】:

    如果您在 Visual Studio 2013 中使用 NuGet 并遇到这个烦人的错误,请转到工具 | NuGet 包管理器 |包管理器设置并单击“清除包缓存”。重新启动 Visual Studio。我知道有多种解决方案,所以这是另一个尝试。

    【讨论】:

      【解决方案5】:

      我也间歇性地遇到过这个问题。我刚刚再次遇到它并遇到了这个线程。在我最近的案例中,我意识到我打开了两次 VS 2013(这通常不是问题,我一直都这样做)。由于其他似乎解决它的唯一共同主题在环境上与要求管理员权限有关,因此我试了一下并关闭了 VS 的两个实例并在新实例中重新打开了我的解决方案。运行 nuget 安装,它运行顺利。

      基于此,我认为这是导致此虚假错误的文件权限问题。有点像Windows在调试会话后锁定了bin目录中的文件并且不允许您编译解决方案。

      【讨论】:

        【解决方案6】:

        您可以通过不以管理员身份运行 Visual Studio 来解决此问题。

        不同的原因,相同的错误信息;可能对遇到这个问题的人有所帮助。

        【讨论】:

        • 看来它确实为我的问题提供了答案。答案可以改写为“您可以通过不以管理员身份运行 Visual Studio 来解决此问题。”
        【解决方案7】:

        由于我们需要在我们网络中的远程服务器上的共享上创建一个项目并遇到类似的问题,这就是有效的方法:

        • 将共享映射为网络驱动器,例如 R:(但我想如果没有此映射,它也可以工作)
        • 打开 Internet 选项 > 安全 > 本地 Intranet > 站点 > 高级(通过 IE 或控制面板)
        • 添加“R:”或“file://server.domain.xy”(重新打开对话框后,前者会自动变为后者)
        • 运行 x86 PowerShell 可执行文件并执行“S​​et-ExecutionPolicy RemoteSigned”

        一旦我做了所有这些,Visual Studio 并没有在再次打开解决方案时抱怨项目位于不受信任的位置,并且它成功地为创建新 MVC 应用程序时自动安装的包运行了所有 PowerShell 脚本.

        【讨论】:

          【解决方案8】:

          我现在遇到了这个问题,我认为对我有用的是我只需要重新启动 Visual Studio 2013 并以管理员身份运行它...对我来说工作得很快。

          【讨论】:

            猜你喜欢
            • 2011-05-31
            • 2018-04-07
            • 2016-05-02
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多