Inicjator typu dla "System.Management.Automation.Runspaces.InitialSessionState" rzucił wyjątek

Question

Pracowałem nad prostą aplikacją do zarządzania rekordami w ASP.NET MVC. Budowa była udana. Jednak, gdy przejdę do konsoli menedżera pakietów, zawsze otrzymuję ten błąd.

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

Czy ktoś może mi wyjaśnić ten błąd? Dostaję to cały czas i przeszkadza mi to w rozwoju. Z góry dziękuję.

Answer 1

Poniższe informacje zostały zebrane z tego programu Visual wątku biletów raport o błędzie Studio Nuget konsoli: https://github.com/NuGet/Home/issues/1638

Przyczyna

Per this comment z Yishai Galatzer (Microsoft), problem jest spowodowany przez błąd przepełnienia stosu w bibliotece DLL PowerShell, która jest częścią System.Management.Automation 3.0. Zaktualizowana biblioteka DLL z błędem ewidentnie była rozpowszechniana w ramach Aktualizacji Windows w ciągu kilku ostatnich tygodni.

Również za another comment przez Yishai Galatzer, zespół PowerShell wyda poprawkę na to, mam nadzieję, że jeszcze w tym miesiącu (styczeń 2016).

Obejście/rozwiązanie tymczasowe

"pete1208" posted następujące obejście wcześniej w tym samym wątku:

w folderze Visual Studio, zrób kopię zapasową pliku devenv.exe.config.

Następnie w oryginalnym pliku devenv.exe.config, wstawić następujący tuż po otwarciu 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 --> 

(będzie potrzebne wersję administratora-podwyższony o swoim ulubionym edytorze tekstowym zapisz plik w folderze Visual Studio.)

Następnie uruchom ponownie program Visual Studio.

Ponownie per Yishai Galatzer, efekt tego obejścia polega na użyciu wiążących przekierowań w celu wymuszenia ładowania programu PowerShell 1.0.

Próbowałem obejścia problemu i zadziałało to dla mnie. Moja konsola menedżera pakietów w moim Visual Studio 2013 znów działa.

Mam zamiar pilnować tego wątku błędów NuGet, a gdy pojawi się komunikat, że aktualizacja Windows Update z poprawką System.Management.Automation jest już dostępna, wycofam obejście tego problemu devenv.exe.config plik.

Aktualizacja

poprawka została wydana w January 12, 2016 Windows Update, za Yishai Galatzer (Microsoft).