The type initializer for 'System.Management.Automation.Runspaces.InitialSessionState' threw an exception

Question

I was working on a simple record management web app in ASP.NET MVC. The build was successful. However, when I go to Package Manager Console, I always get this error.

The type initializer for 'System.Management.Automation.Runspaces.InitialSessionState' threw an exception.

Can somebody please explain this error to me? I get it all the time and it bothers me in development. Thanks in advance.

Answer 1

The following information was gathered from this Visual Studio NuGet Console bug report ticket thread: https://github.com/NuGet/Home/issues/1638

Cause

Per this comment from Yishai Galatzer (Microsoft), the problem is caused by a stack overflow bug in a PowerShell DLL that's part of System.Management.Automation 3.0. The updated DLL with the bug evidently was distributed as part of Windows Updates sometime in the past few weeks.

Also per another comment by Yishai Galatzer, the PowerShell team will be releasing a fix for this, hopefully later this month (January 2016).

Workaround / Temporary Solution

"pete1208" posted the following workaround earlier in that same thread:

In your Visual Studio folder, make a backup copy of file devenv.exe.config.

Then, in the original devenv.exe.config file, insert the following just after the opening assemblyBinding element:

<!-- WORKAROUND START for NuGet Console error: 
  "The type initializer for 'System.Management.Automation.Runspaces.InitialSessionState' threw an exception" 
  Author: pete1208 from https://github.com/NuGet/Home/issues/1638 -->
<dependentAssembly>
        <assemblyIdentity name="System.Management.Automation" publicKeyToken="31bf3856ad364e35" />
        <publisherPolicy apply="no" />
      </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.PowerShell.Commands.Utility" publicKeyToken="31bf3856ad364e35" />
      <publisherPolicy apply="no" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.PowerShell.ConsoleHost" publicKeyToken="31bf3856ad364e35" />
      <publisherPolicy apply="no" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.PowerShell.Commands.Management" publicKeyToken="31bf3856ad364e35" />
      <publisherPolicy apply="no" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.PowerShell.Security" publicKeyToken="31bf3856ad364e35" />
      <publisherPolicy apply="no" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.PowerShell.Commands.Diagnostics" publicKeyToken="31bf3856ad364e35" />
      <publisherPolicy apply="no" />
    </dependentAssembly>
<!-- WORKAROUND END -->

(You'll probably need an admin-elevated version of your favorite text editor to save the file to your Visual Studio folder.)

Then, restart Visual Studio.

Again per Yishai Galatzer, the effect of this workaround is to use binding redirects to force loading PowerShell 1.0.

I tried the workaround, and it did work for me. My Package Manager Console in my Visual Studio 2013 is once again functional.

I'm planning to keep an eye on that NuGet bug thread, and once the announcement is made that the Windows Update with the System.Management.Automation fix is live, I'm going to back out the workaround in my devenv.exe.config file.

Update

The fix was released in the January 12, 2016 Windows Update, per Yishai Galatzer (Microsoft).