Geek Answers Handbook

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

I was working on a simple web-based recording management application in ASP.NET MVC. The assembly was successful. However, when I go to the package manager console, I always get this error.

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

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

+6
source share
1 answer

The following information was obtained from this Visual Studio NuGet Console error report bit stream: https://github.com/NuGet/Home/issues/1638

<strong> reason

Per this comment from Yishai Galatzer (Microsoft), the problem is caused by an error in the PowerShell DLL of that part of the system. Management.Automation 3.0. The updated DLL with an error has obviously been distributed as part of Windows updates over the past few weeks.

Also for another comment from Yishai Galatzer, the PowerShell team will release a fix for this, hopefully later this month (January 2016).

Workaround / Workaround

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

In your Visual Studio folder, back up the devenv.exe.config file.

Then, in the devenv.exe.config source file, paste the following immediately after opening the 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 will probably need the version of your favorite text editor added by the administrator to save the file in the Visual Studio folder.)

Then restart Visual Studio.

Again for Yishai Galatzer, the effect of this workaround is to use binding forwarding to force PowerShell 1.0 to load.

I tried a workaround and it worked for me. My package manager console in my Visual Studio 2013 is functional again.

I plan to monitor this NuGet error, and after announcing that the Windows update with the System.Management.Automation fix is ​​live, I'm going to undo the workaround in my devenv.exe.config .

Update

The hotfix was released on January 12, 2016 by Windows Update , for Yishai Galatzer (Microsoft).

+4
source

More articles:


All Articles