Reputation: 4736
I'm trying to launch the Package Manager Console in Visual Studio 2012 Update 3 and seeing the following output when I open the window:
Package Manager Console Host Version 2.6.40627.9000
Type 'get-help NuGet' to see all available NuGet commands.
The term 'Set-Location' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I'm never given a prompt, which implies to me that the console failed to initialize properly. This did work at one point, say two weeks ago, but I'm unable to deduce what change caused it to stop working. I see the error even if I launch in safe mode. I also have Visual Studio 2010 installed, and I'm seeing the same error, which suggests Visual Studio isn't the culprit.
What script does the Package Manager Console try to run that's failing? Set-Location
is a built-in PowerShell cmdlet, which is why this error is puzzling to me. I'm not sure how to begin troubleshooting this. I uninstalled and re-installed the Package Manager extension, but the problem remains.
I discovered this issue while trying to troubleshoot the package installation failure of a Web API project. When I try to create a new Web API project, I see errors like:
EntityFramework.5.0.0 : 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.
Here's some additional info that may help. I'm running Windows 7 with .NET 4.5.50709 and PowerShell v2. My execution policy is set to Unrestricted while troubleshooting this issue.
C:\> $psversiontable.psversion
Major Minor Build Revision
----- ----- ----- --------
2 0 -1 -1
Upvotes: 2
Views: 6921
Reputation: 1
I know this is an old thread, but I just had this issue pop up after there was a cmdlet removal script baked into a module installation script I picked up. Luckily, I had a server that was using similar modules, and was able to run this on the problematic server under an Administrator Powershell window:
Get-Acl "\\goodserver\c$\program files\windowspowershell\modules\" | Set-Acl "c:\program files\windowspowershell\modules\"
What was odd is that the commands would run under my own account, but "run as another user" windows, including scheduled tasks, that were opened up under other accounts were returning the "set-location" is not the name of a cmdlet, function, etc. Pulling the ACL's from another system and applying them like this was the fix in my case.
Upvotes: 0
Reputation: 4736
I was able to resolve this error by installing PowerShell 3 via the Windows Management Framework 3 for Windows 7 SP 1 update (Windows6.1-KB2506143-x64.msu). It's unclear whether PowerShell 3 is required or the act of upgrading fixed whatever configuration issue caused this.
Upvotes: 3