为什么Visual Studio中的项目的ExecutionPolicy行为有所不同?

我在一台特定的个人电脑上使用NuGet已经有一段时间了。 现在,我在VS2010中创build了一个新项目(这是一个使用单页面应用程序模板的MVC 4 Beta项目)。 当我select

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

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

文件C:\ Program Files文件(x86)\ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ Extensions \ Microsoft公司\ NuGet包pipe理器\ 1.7.30402.9028 \ Modules \ NuGet \ profile.ps1无法加载,因为脚本的执行被禁用这个系统。 请参阅“get-help about_signing”了解更多详情。

但是,其他项目仍然可以打开并使用程序包pipe理器控制台。

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

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

GET-ExecutionPolicy

PowerShell返回

受限

基于Scott Hanselman博客的理解是,如果ExecutionPolicy被限制,脚本不应该运行。

为什么现有的项目能够使用软件包pipe理器控制台,而新的不是?

更新:更改ExecutionPolicy AllSigned 重新启动VS2010解决了眼前的问题,但我的主要问题是为什么其他项目能够绕过build立的ExecutionPolicy。 VS2010 作为pipe理员运行。

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

  • 以pipe理员身份打开PowerShell
  • input以下命令“Set-ExecutionPolicy RemoteSigned”
  • 重新启动Visual Studio和包pipe理器控制台按预期工作

不过请注意,Powershell会给你一个警告

“执行策略有助于保护您免受您不信任的脚本的影响,更改执行策略可能会使您遇到about_Execution_Policies帮助主题中描述的安全风险,您是否要更改执行策略?

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

除了Murries的回答 ,我发现jellonek的post (在另一个post上)很有帮助。 您可能必须更改不同版本的PowerShell的权限(32位和64位版本需要单独的权限)。

从如何判断PowerShell是32位还是64位 :

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

另外,这些都应该工作:

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

解决这个问题的另一种方法是将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" 

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

合并上述文件后,重新启动Visual Studio。

如果您在Visual Studio 2013中使用NuGet,并得到这个恼人的错误,请转到工具| NuGet包pipe理器| 打包pipe理器设置,然后单击“清除软件包caching”。 重新启动Visual Studio。 我知道有多种解决scheme,所以这是另一个尝试。

我也间歇性地遇到了这个问题。 我刚刚遇到它,跑过这个线程。 在我的最新案例中,我意识到我有VS 2013两次开放(通常不是问题,我一直这样做)。 由于似乎修复它的唯一共同主题与需要pipe理员权限有直接的关系,所以我给了它一个镜头,closures了VS的两个实例,并在新实例中重新打开了我的解决scheme。 运行nuget安装,它工作顺利。

基于此,我认为这是一个文件权限问题导致这个虚假的错误。 有点像在debugging会话之后,windows在bin目录中的文件上有一个锁,并且不会让您编译解决scheme。

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

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

由于我们需要在networking中的远程服务器上的一个共享上创build一个项目,并遇到类似的问题:

  • 将共享映射为一个networking驱动器,比如R:(但是我猜这样也可以在没有映射的情况下工作)
  • 打开Internet选项>安全>本地内部网>站点>高级(通过IE或控制面板)
  • 添加“R:”或“file://server.domain.xy”(一旦你重新打开对话框,前者将自动变成后者)
  • 运行x86 PowerShell可执行文件并执行“S​​et-ExecutionPolicy RemoteSigned”

一旦我做了所有的Visual Studio没有抱怨项目是在一个不受信任的位置再次打开解决scheme,并成功地运行所有的PowerShell脚本的包自动安装时创build一个新的MVC应用程序。

我现在有这个问题,我觉得我很容易的是,我只需要重新启动Visual Studio 2013,并以pipe理员身份运行…为我工作得很快。