65

I have been using NuGet for quite some time on a particular PC. Now, I created a new project in VS2010 (it's an MVC 4 Beta project using the Single Page App template if that matters). When I select

Tools / Library Package Manager / Package Manager Console

The console window opens but displays the error:

File 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 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

However, other projects can still open and use Package Manager Console.

In each case, VS2010 is running as the same user.

If I open a command prompt (using the same account under which VS2010 is running), start PowerShell, and enter the command

Get-ExecutionPolicy

PowerShell returns

Restricted

My understanding based on a Scott Hanselman blog is that scripts should not run at all if the ExecutionPolicy is restricted.

Why are existing projects able to use the Package Manager Console while a new one is not?

Update: Changing the ExecutionPolicy to AllSigned and restarting VS2010 solves the immediate problem, but my main question is why the other projects were able to bypass the established ExecutionPolicy. VS2010 is not running as an administrator.

Derek Greer
  • 15,454
  • 5
  • 45
  • 52
Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • The NuGet Package Manager console sets PowerShell's execution policy to RemoteSigned and the scope is set to Process so it only affects Visual Studio. Changing the policy for Visual Studio does not require Visual Studio to run as an administrator. The execution policy you see from the command line should not need to be changed. On my machine this is set to Restricted. However none of this explains why your new project shows this error and the existing ones do not. – Matt Ward May 05 '12 at 10:31
  • What's the point of setting the policy machine-wide, if a non-administrative user can change the policy on a per-process basis anyhow? – Eric J. May 05 '12 at 23:07
  • Group policy settings can prevent you from overridding the settings for the current process, but local machine settings on their own do not. See the execution policy precedence section in the msdn post following - http://technet.microsoft.com/en-us/library/dd347641.aspx – Matt Ward May 06 '12 at 09:24
  • 2
    I'm glad to see that an answer hasn't actually be accepted here like I've seen so many people do when someone provides an answer containing a work-around which doesn't actually answer the real question. I've run into this several times over the past few months and can't figure out what's going on. On VS2014, given multiple projects with an out of date library, I'll get the ExecutionPolicy error message for some while others can successfully update. Installing a package works fine in a new solution & project, but doesn't for an existing one. I'd like an answer, not a "try this" suggestion. – Derek Greer Sep 23 '14 at 14:28

8 Answers8

123

I experienced the same problem and solved it by:

  • Opening Powershell as an Administrator
  • Entering the following command "Set-ExecutionPolicy RemoteSigned"
  • Restart Visual Studio and the Package Manager Console worked as expected

It is important to note however that Powershell will give you a warning

"The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution policy?"

And should be careful of enabling this feature and should read more information in the help topics about the security risks.

Steve Dunn
  • 21,044
  • 11
  • 62
  • 87
Mura Nhekairo
  • 1,346
  • 1
  • 9
  • 4
  • 8
    +1 Oh yeah! This is Windows. I just need to reboot stuff until it works. ;) – Nick Nov 04 '14 at 17:12
  • No reboot needed on my side for VS. – Valamas Jan 28 '15 at 23:38
  • I first thought it was some complicated permissions issue, but I then realized, that I just had to close all the VS2013 instances, check in processexplorer and kill the hung up processes, maybe wait a little :-) and when I restarted the first VS2013 everything was back to normal again. Weird. – Xan-Kun Clark-Davis Nov 14 '15 at 12:31
  • If you already run Visual Studio as Administrator you can run the command direct in the Package Manager without having to restart Visual Studio. – user692942 Sep 08 '16 at 15:45
  • Worked for me!! Thanks – Naibedya Kar Nov 07 '17 at 06:38
31

In addition to Murries' answer, I found jellonek's post (on another thread) helpful. You might have to change the permissions on a different version of PowerShell (32-bit and 64-bit versions require separate permissions).

From How to Tell if PowerShell is 32-bit or 64-bit:

  • 64-bit PowerShell Path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • 32-bit PowerShell Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

Also, BOTH of these should work:

  • Set-ExecutionPolicy RemoteSigned
  • Set-ExecutionPolicy Unrestricted
Community
  • 1
  • 1
cat5dev
  • 1,317
  • 15
  • 12
  • 1
    I tried to run just the "Set-ExecutionPolicy RemoteSigned" and that did not work. I can confirm that I also had to run "Set-ExecutionPolicy Unrestricted". – Bill Christenson Jul 26 '14 at 20:34
  • 2
    +1 I encountered this error today for the first time ever, I apparently only had my powershell policy set on one of the 2 powershells... Something I just noticed do you have 32bit & 64bit flipped in your post? You have 32bit with SysWow64 and 64bit with System32. That seems backwards. – Chris Marisic Sep 22 '14 at 17:31
  • Thanks Chris. I copied it from the linked article, which has them flip-flopped. This has been updated. – cat5dev Sep 23 '14 at 22:37
8

Another way to fix this is by merging a Regedit file with the following content:

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"

(Create a text file called NuGetPowerShellFix.txt, copy paste the above into it, rename to NuGetPowerShellFix.reg, then run.)


After merging the above file, restart Visual Studio.

Danny Varod
  • 17,324
  • 5
  • 69
  • 111
6

If you're using NuGet in Visual Studio 2013 and get this annoying error, go to Tools | NuGet Package Manager | Package Manager Settings and click "Clear Package Cache." Restart Visual Studio. I know there are multiple solutions to this, so this is yet another to try.

john c
  • 89
  • 1
  • 1
3

I have had this problem intermittently as well. I just came across it again and ran across this thread. In my latest case, I realized I had VS 2013 open twice (which normally is not an issue, I do it all the time). Since the only common theme of others that seemed to fix it was circumstantially related to requiring administrator privileges I gave it a shot and closed both instances of VS and reopened my solution in a new instance. Ran the nuget install and it worked without a hitch.

Based on this, I am thinking that it is a file permission issue causing this spurious error. Sort of like when windows has a lock on a file in the bin directory after a debug session and will not let you compile the solution.

Gustyn
  • 2,024
  • 1
  • 15
  • 14
2

You may be able to resolve this by not running Visual Studio as Administrator.

Different cause, same error message; might be helpful for someone who runs into this one.

Taryn
  • 242,637
  • 56
  • 362
  • 405
sargeMonkey
  • 606
  • 1
  • 7
  • 23
  • It seems that it does provide an answer to my question. The answer could be rephrased as "You may be able to resolve this by not running Visual Studio as Administrator." – Eric J. Sep 08 '14 at 21:28
1

Since we needed to create a project on a share on a remote server in our network and ran into similar problems here's what worked:

  • map the share as a network drive, say R: (but I guess it would also work without this mapping)
  • open Internet options > Security > Local intranet > Sites > Advanced (via IE or control panel)
  • add either "R:" or "file://server.domain.xy" (the former will automatically turn into the latter once you reopen the dialog)
  • run the x86 PowerShell executable and do "Set-ExecutionPolicy RemoteSigned"

Once I did all that Visual Studio didn't complain that the project was in an untrusted location upon opening the solution again, and it successfully ran all the PowerShell scripts for the packages that get auto-installed when creating a new MVC application.

Leak
  • 175
  • 2
  • 6
0

I'm having this issue now, i think what worked for me easy was that i just had to restart visual studio 2013 and run it as administrator...worked fast for me.

Alexander Burias
  • 333
  • 3
  • 8