Why does ExecutionPolicy behavior vary across projects in Visual Studio?

Question

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 th

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.