I assisted a co-worker today with an issue where the Package Manager Console would not start in Visual Studio 2015 or Visual Studio 2017. These are the errors that were being display on the console:
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3007) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject. The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3014) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject. The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3021) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject. The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3028) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject. The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3035) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject. The term 'Get-ExecutionPolicy' 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. 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.
It was a brand new Windows 10 machine running build 10.0.14393 version 1607. There are known bugs with Visual Studio 2015 and PowerShell running on earlier versions of Windows 10 see here. Since this was a newer version of Windows I didn’t believe that was the issue.
While searching Google I came across a number of different discussions where users were experiencing the same issue. I tried several different suggestions that didn’t fix the issue, but when I tried the solution suggested in this discussion the Package Manager Console starting working. The short answer is I fixed VS2015 and VS2017 Package Manager Console errors by adding dependent assembly references for PowerShell, along with Version Information to the Visual Studio configuration files. Here is the more detailed answer.
I modified the devenv.exe.config files for both Visual Studio 2015 and Visual Studio 2017, found at %LOCALAPPDATA%\Microsoft\VisualStudio\14.0 and %LOCALAPPDATA%\Microsoft\VisualStudio\15.0_######, using NotePad.exe.
I inserted the following dependent assembly references, with the additional specific bindingRedirect version information:
<dependentAssembly>
<assemblyIdentity name="System.Management.Automation" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Utility" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.ConsoleHost" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Management" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Security" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Diagnostics" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0"/>
<publisherPolicy apply="no" />
</dependentAssembly>
I saved the files and restarted VS2015 and VS2017. Now when I opened the Package Management Console I was able to run PowerShell commands.
Now while you were in the devenv.exe.config file you may have noticed this comment at the top:
<!-- *************************************************************************** --> <!-- ************** NOTE: This is a generated file. Do not modify.************** --> <!-- ********* Modifications will be overwritten during regeneration. ********** --> <!-- *************************************************************************** -->
Well if this file is going to be overwritten how to we make the changes permanent. Also we made these changes to a config file in the user profile. Any other user who logs on to the computer will have the same issue with the Package Management Console. So how do we fix this for all users. Luckily the solution is simple. The devenv.exe.config in the user profile is generated from the devenv.exe.config file found in %PROGRAMFILES(X86)%\Visual Studio 14\Common7\IDE for VS 2015 and %PROGRAMFILES(X86)%\Microsoft Visual Studio\2017\Enterprise\Common7\IDE for VS 2017. So to make the changes permanent and take affect for all users we need to make the same modification to both of those devenv.exe.config files.
Once I added the dependentAssembly modifications I deleted the devenv.exe.config from my user profile and restarted Visual Studio. The Package Management Console worked as expected.
Related Links
- Windows 10 release information
- Package Manager Console Documentation
- Forum discussion containing resolution
- Visual Studio 2013/15 Nuget Errors on Console
- ASPNet Core Publish fails #755
- failed to initialize powershell host on Windows 10 build 10586.xx
- Nuget can’t initialize PowerShell
- Package manager not working VS2015/VS2013 on Windows 10
- Package Manager console failed to load
Joshua Chini 
One response to “Visual Studio Package Manager Console Fails to Start”
Thank you, this was killing me.
LikeLike