Opening Package Manager Console produces the message:
"Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy"."
But no PowerShell prompt ever appears. Similarly, attempting to install a package produces the same message on attempting to execute the script file from the package, followed by:
Install failed. Rolling back...
Attempting to upgrade an existing package instead produces:
Failed to initialize the PowerShell host. If your PowerShell execution policy setting is set to AllSigned, open the Package Manager Console to initialize the host first.
To help us investigate the issue, could you tell us:
Set-ExecutionPolicy -Scope Process ByPass
? Sure, whatever helps.
Build is the latest - 10240.
Output is:
Execution Policy Change
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 at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y
set-executionpolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by
a policy defined at a more specific scope. Due to the override, your shell will retain its current effective
execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more
information please see "Get-Help Set-ExecutionPolicy".
At line:1 char:1
(Execution policy is set to Unrestricted here by group policy on all the development machines; if it'll help, I can disable that for debugging purposes.)
Hi
I have the same issue here (Win7-64bit, VS2015RTM).
Our corporate domain policy are set to "RemoteSigned".
If i try to bypass with "Set-ExecutionPolicy -Scope Process ByPass" i get the same security exception as cerebrate.
This error prevents VS to install some nuget packages like EntityFramework, JsonNet.
In VS2013 (Update 4) there are no issues with the package manager.
Same issue here, on Win 8.1.
Both VS2015RTM (14.0.23107.0) and VS2013-5 (12.0.40629.00) are showing this problem. (I installed VS2013 update 5 yesterday. Before that, Nuget PMC was working just fine on VS2013-4.)
Same issue here getting the error message Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy"
Unable to install/update packages in solution
Same issue on Win 7-64bit, VS2013 Update 5). Nuget PMC was working before I ran Update 5.
Same here. Anybody find a fix?
Same configuration as joswalt and experiencing the problem. It also occurs in Visual Studio 2015 RTM.
Here is the output of my Get-ExecutionPolicy -list
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
Are those of you experiencing this on computers that are joined to a domain? It seems as though the GPO setting for ExecutionPolicy might be affecting this. Output on my machine (joined to a domain):
Scope ExecutionPolicy
----- ---------------
MachinePolicy Unrestricted
UserPolicy Unrestricted
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
@rossipedia Yes I am joined to a domain. This all worked prior to Update 5 being installed in VS2013. I have coworkers who are joined to the same domain who have not installed the update and are able to load NuGet package manager just fine.
@rossipedia - Same here (I am on a domain, and it worked fine prior to VS2013-5)
Same as @pbar and @JaredShaver. I did the temp fix/delete from here to get back up and running. https://powershellpanda.wordpress.com/2013/12/01/override-gpo-for-powershell-execution-policy/ No telling when/if it will come back.
@RHayes990 hooray! That worked, thanks!
Thanks @RHayes990, that temp fix works for me too. Here's a quick like regedit script to do it.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=-
I am on a domain as well. Here is my listing:
Get-ExecutionPolicy -list
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
Also, why would this change with Update 5. These settings have not changed.
MachinePolicy apparently takes the highest precedence. Not exactly sure what VS 2015 is doing differently from VS 2013.
Also, I'm pretty sure this isn't restricted to Windows 10, as a co-worker on Windows 8 encountered the same thing.
@rossipedia Yes, also joined to a domain. @RHayes990 's fix works for me, too, when also expanded to cover the HKCU: equivalent of that key.
Removing the entry for the MachinePolicy fixed the issue for me for now. I'm not sure what else that may impact that needed the MachinePolicy to be RemoteSigned.
Get-ExecutionPolicy -list
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
Removing the value for the MachinePolicy fixed for me as well.
E.g:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=
Setting the milestone only to 3.2.0 seems to underestimate this bug. As far I can see this affects many users in enterprises (all in a domain?) and nuget is not operational without a workaround. Without nuget it is not possible to create a new Web Project. So this is the first impression of the VS2015 RTM for this users.
There is also a stack overflow thread with this problem: Nuget PMC policy settings
This is definitely a bug with the VS2013 2.8.6 version (2.8.60610.756). Reverting back to NuGet Package Manager 2.8.5 on VS2013 fixes the issue for me, right now. In my case, there were domain GPOs that enforced the use of RemoteSigned for the execution policy.
This issue was not present in whatever version of NuGet package manager I was using in VS2015 RC edition, but the latest 3.0.60624.657 version that came with the VS2015 RTM is definitely affected by this same issue. I'll be investigating the registry settings overrides, next...
This is _definitely_ a show stopper for developers in security-conscious domains.
Editing HKLM is not an option for developers who are not administrators.
We have done some research and have acknowledged this issue as being introduced as part of a bug fix that was submitted for the 2.8.6 and 3.0 RTM. The issue listed with the known issues on our blog post announcing the 3.0 and 2.8.6 releases We are going to recommend users follow the workarounds that have already been suggested and a fix is scheduled for the 3.2 release.
@csharpfritz What is the timeline on 3.2? This affects every domain-joined developer in many companies (including here at Stack Overflow). If 3.2 is more than a week away I think your team needs to re-evaluate and release a fix much sooner. This is a critical issue and needs to be treated as such.
I have to concur with @NickCraver and @damiarnold. While I can use the workaround temporarily, long-term use of it risks breaking other things that depend on the domain policy being set. I don't think it can be prioritized too highly under the circumstances - maybe even to the point of its own interim release.
+1 This is also an issue for me. Joined to a domain, and receive this issue. VS2015 Pro. Win7. 64bit.
Also issue of using workaround and going against corporate IT policy.
I have same issue and avoid with not using temporary/ permanent method mentioned https://github.com/NuGet/Home/issues/974#issuecomment-123411598
Because issue is relates to GPO MachinePolicy blocks Set-ExecutionPolicy. Also, even you delete registry key but GPO will roll back in few hours. So the temporary workaround https://github.com/NuGet/Home/issues/974#issuecomment-123411598 is not prefer in many cases.
Therefore I took, and working fine, is "overwrite registry key where Set-ExecutionPolicy exactly doing in background".
Step 1. Turn off GPO for Computer Configuration > Administrative Templates > Windows Components > Windows > PowerShell > Script Execution setting to be "Not Configured". (This is as default. And you must turn off it to prevent GPO blocking Set-ExecutionPolicy.)
Step 2. Create Registry Key by User Configuration > Preferences > Windows Settings > Registry > Add following keys.
HKEY_LOCAL_MACHINE\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
and
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
Key Name for
ExeuctionPolicy
Key type for
REG_SZ
Key Value for
RemoteSigned
(or any other executionpolicy you want)
Hope this helps both Admin and Developers until fix is released.
We are having the same issue and are unable to work around due to corporate policies/restrictions - yet to try the above work around.
Since the title of this thread only states Windows 10 and Visual Studio 2015, I also wanted to make sure that it is known that this bug is affecting more than just Visual Studio 2015 and Windows 10.
It is affecting Windows 7 and Windows 8. Visual Studio 2013 Update 5 is affected as well.
I would agree that this issue should be escalated higher if the 3.2 release is not scheduled to be released soon.
We have identified the root cause of this issue and are discussing options
to deploy a fix. The same update was applied to both 2.8.6 and 3.0RTM, and
we believe we can issue a 2.8.6 fix sooner than the 3.0 fix. There are
discussions going on about how to package the fix for VS2015. We'll let
you know as soon as we have approval to bundle and deploy.
On Thu, Jul 23, 2015 at 10:50 AM, John Oswalt [email protected]
wrote:
Since the title of this thread only states Windows 10 and Visual Studio
2015, I also wanted to make sure that it is know that this bug is affecting
more than just Visual Studio 2015 and Windows 10.It is affecting Windows 7 and Windows 8. Visual Studio 2013 Update 5 is
affected as well.I would agree that this issue should be escalated higher if the 3.2
release is not scheduled to be released soon.—
Reply to this email directly or view it on GitHub
https://github.com/NuGet/Home/issues/974#issuecomment-124130411.
Easiest/correct fix in my opinion is the swap out the PSAuthorizationManager for a default "null" AuthorizationManager in the NuGet managed runspace when you initialize the host. This will not affect ISE or powershell.exe hosts. I blogged about this a couple of years ago:
http://www.nivot.org/blog/post/2012/02/10/Bypassing-Restricted-Execution-Policy-in-Code-or-in-Script
``` c#
InitialSessionState initial = InitialSessionState.CreateDefault();
// Replace PSAuthorizationManager with a null manager
// which ignores execution policy
initial.AuthorizationManager = new
System.Management.Automation.AuthorizationManager("NuGet");
// Extract psm1 from resource, save locally
// ...
// load my extracted module with my commands
initial.ImportPSModule(new[] {
// open runspace
Runspace runspace = RunspaceFactory.CreateRunspace(initial);
runspace.Open();
RunspaceInvoke invoker = new RunspaceInvoke(runspace);
// execute a command from my module
Collection
// or run a ps1 script
Collection
For the moment, you can probably get away with running the following script once in the nuget host via the interactive window and it will henceforth ignore group policy enforced polices (and every other scope too.)
``` powershell
function Disable-ExecutionPolicy {
($ctx = $executioncontext.gettype().getfield(
"_context","nonpublic,instance").getvalue(
$executioncontext)).gettype().getfield(
"_authorizationManager","nonpublic,instance").setvalue(
$ctx, (new-object System.Management.Automation.AuthorizationManager `
"Microsoft.PowerShell"))
}
Disable-ExecutionPolicy
The above function does invoke reflection, yes, but it works in powershell v3, v4 and v5. It does not require administrative rights.
This worked for me on a domain joined machine without having to futz around with registry or GPO settings:
Set-ExecutionPolicy -Scope LocalMacine ByPass
@abpatel that solution is only applicable if you don't already have a LocalPolicy or GroupPolicy setting for ExecutionPolicy. What is your output for Get-ExecutionPolicy -List
?
We are planning a fix to be released next week that will address this issue. Please watch this space for updates.
A hotfix is now available to install and we are confident it will unblock you. Please grab the install from one of these locations appropriately:
2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix
3.1.1 for VS 2015:
https://github.com/NuGet/Home/releases/download/3.1.1/NuGet.Tools.vsix
We will publish these to the Visual Studio gallery next week.
FWIW I updated to Visual Studio 2013 Update 5 on Friday evening and it pulled down the troublesome version of NuGet so it wasn't working this morning with the same errors as above.
However when I installed 2.8.7 from the links above the problem went away and all seems to be behaving itself :).
Thanks guys for getting a patch out so quickly!
Owh~, the hotfix is very helpful. It works for me.
I was stuck in this issue for a whole day.
Well I've installed VS2015, package manager console 3.1.1.0 and Powershell 4.0. But NuGet is stuck at "Initializing Power Shell Host" for ever.
3.1.1 for VS 2015 fixed it for me.
But I had to go to GitHub and download it instead of the link in this conversation for some reason.
https://github.com/NuGet/Home/releases/
I had to run the install as admin so it would not hang;
Otherwise, NuGet is stuck at "Initializing Power Shell Host" forever.
Yeah it does work, turns out my issue was that I was using posh-git and had the following script configured:
. 'C:\Users\govind.mukundan\Documents\WindowsPowerShell\Modules\posh-git\profile.example.ps1'
if ($host.Name -eq 'ConsoleHost')
{
Import-Module PSReadline
}
Removing the script, solved the hang issue.
FWIW SQL Server Agent has the same bug when running PowerShell agent steps, and it's taken me about 6 months working with Microsoft Premiere Support to get them to admit it's a bug, whereas you guys _fixed_ it in a matter of _days_. Admittedly it's a more critical issue for you guys, but still, credit where credit's due.
This did work for me. I had a reinstall of VS2013 update 5 and package manage stopped working, after the hotfix above it does. Great :)
It worked for me as well:) thank you!
This version worked for me :) Thank you so much.
2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix
Joswalt and Satish's steps worked for me.
Removing the value for the MachinePolicy fixed for me as well.
E.g:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=
csharpfritz 2015 Patch worked for me. Thanks a bunch. Cheers.
Win8 VS 2015 V.14.0.
3.1.1 for VS 2015 (Posted By: csharpfritz ):
https://github.com/NuGet/Home/releases/download/3.1.1/NuGet.Tools.vsix
Excellent csharpfritz. Worked for me. Thank you so much for sharing this.
I'm was having the same problem as you.
If you have using some scripts in powershell that changes the prompt, will have problems.
In my case, I was using posh-hg, and sometimes Enumerator-Prompt
2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix
works.
@RHayes990 your link worked for me as well. Thanks!
I have installed the latest NuGet VSIX for VS 2015 and I am still unable to create a simple ASP.NET WebAPi project :( I'm on a corporate dev environment where LocalMachine and UserPolicy settings are locked. How can I get around this?
I was experiencing the same issue. Below is how I resolved it.
Open Visual Studio > Tools > Extensions and Update > Updates -
In my case it was asking to update "Nuget Package Manager for Visual Studio 2013".
After update and restart, the issue got resolved.
@csharpfritz thanks for the fix link!
Most helpful comment
A hotfix is now available to install and we are confident it will unblock you. Please grab the install from one of these locations appropriately:
2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix
3.1.1 for VS 2015:
https://github.com/NuGet/Home/releases/download/3.1.1/NuGet.Tools.vsix
We will publish these to the Visual Studio gallery next week.