Odwoływanie się do systemu.management.automation.dll w programie Visual Studio

133

Zaczynam przyglądać się modelowi PowerShell i tworzeniu przystawek. Pierwszą rzeczą, którą zauważyłem, jest odwołanie się do System.management.automation.dll. Jednak w programie Visual Studio karta .NET nie ma tego zestawu i nie można jej przeglądać

C:\windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll

aby utworzyć odniesienie do pliku.

Czy jestem zmuszony do ręcznego kopiowania pliku, aby ułatwić sobie do niego dostęp ?

visual-studio powershell

— icelava
źródło

Czy możesz rozważyć zmianę zaakceptowanej odpowiedzi na tę? Wydaje się, że podejście do pakietu NuGet jest najbardziej proste i niezawodne.

— julealgon

168

~~System.Management.Automation na Nuget~~

System.Management.Automation.dll w NuGet , nowszy pakiet z 2015 roku, nie jest zastrzeżony jak poprzedni!

Pakiety zespołu Microsoft PowerShell w NuGet

Aktualizacja: pakiet jest teraz własnością zespołu programu PowerShell. Huzzah!

— skfd
źródło

2

To zasługuje na więcej

— foobarcode

5

Chciałbym, aby Microsoft przejął na własność ten Nuget, ponieważ są one tak wilgotne w dzisiejszych czasach.

— skfd

@skfd Microsoft jest już prawie właścicielem Nugeta .. Ludzie stojący za nim używają e-maili microsoft.com, a sam NuGet jest częścią Microsofts .NET Foundation ( dotnetfoundation.org )

— Michael Bisbjerg

1

@MichaelBisbjerg, myślę, że odnosił się głównie do tego konkretnego pakietu NuGet. Gdyby był własnością Microsoftu, to (w idealnym świecie) byliby odpowiedzialni za aktualizowanie go, wydawanie nowych pakietów itp.

— Ben Randall

ostatnia aktualizacja: 29/03/2013 „Właściciel zablokował ten pakiet na liście. Może to oznaczać, że pakiet jest przestarzały lub nie powinien być już używany.”

— JuFo

97

Kopia System.Management.Automation.dll jest instalowana podczas instalacji zestawu Windows SDK (w każdym razie jego odpowiedniej, najnowszej wersji). Powinien znajdować się w C: \ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ v1.0 \

— tomasr
źródło

2

Zainstalowałem SDK na 2 różnych maszynach 64-bitowych (z trudnością) i znalazłem wersję 6.2.8229.0, dll 4.66MB tylko na 1 i tylko w c: \ program files (x86) \ reference assemblies \ microsoft \ windowspowershell \ v1.0. Zdecydowanie polecam edycję pliku .csproj lub sprawdzenie odpowiedniej biblioteki DLL do kontroli źródła i odwoływanie się do niej. Instalacja SDK jest po prostu zbyt nieelastyczna.

— James McLachlan

@ ashes999 PowerShell 2.0 faktycznie działa na 1.0 DLL.

— kravits88,

3

2014.07.11 na x64 jest w C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll

— Christopher G. Lewis

Nie wiem o SDK, ale wiem, że WMF 3.0 nie instaluje go w C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0. Chciałem zainstalować PowerShell 3.0 na Windows 7 SP1, który miał wersję 1.0 znajdującą się w C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 1.0 i użyłem Windows6.1-KB2506143-x64.msi firmy Microsoft .com / en-us / download / details.aspx? id = 34595 i działa pomyślnie. Jednak utworzył * .dll tylko w C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35.

— Alexander Samoylov

To poprawny plik * .dll, ponieważ polecenie „powershell.exe -version 3.0” przestaje działać, gdy przenoszę plik * .dll. Rozmiar * .dll różni się od tego, który jest domyślnie obecny na innym komputerze z systemem Windows 10 w folderze C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0. Mogę utworzyć folder C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 na komputerze z systemem Windows 7 SP1 i umieścić tam * .dll z C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, ale pytanie brzmi, jak to poprawnie zainstalować.

— Alexander Samoylov

86

Jeśli nie chcesz instalować zestawu Windows SDK, możesz pobrać bibliotekę dll, uruchamiając następujące polecenie w programie PowerShell:

Copy ([PSObject].Assembly.Location) C:\

— kravits88
źródło

8

Teraz to jest genialne!

— 8DH

2

Bardzo słodkie. Nie pomyślałbym o tym.

— Marius

Dzięki za to. Pakiet NuGet nie działałby dla mnie w zupełnie nowej aplikacji konsoli .NET 4.5.2. „Zainstalował” pakiet, ale odmówił dodania odniesienia. W końcu przestałem walczyć z NuGet i użyłem Twojej odpowiedzi, aby ręcznie dodać odwołanie. Dzięki!

— Lews Therin,

80

Nie udało mi się poprawnie zainstalować SDK (niektóre pliki wydawały się niepodpisane, coś w tym rodzaju). Znalazłem tutaj inne rozwiązanie i wydaje mi się, że działa dobrze. W ogóle nie wymaga instalacji nowych plików. Zasadniczo to, co robisz, to:

Edytuj plik .csproj w edytorze tekstu i dodaj:

<Reference Include="System.Management.Automation" />

do odpowiedniej sekcji.

Mam nadzieję że to pomoże.

— JP.
źródło

1

Wydaje mi się dziwne, że musimy to zrobić ręcznie (edytując plik .csproj), ale to zadziałało.

— kd7iwp

Edycja pliku projektu po prostu zmusza go do załadowania wersji z GAC (która jest wersją V2) zamiast z systemu plików (która jest wersją V1)

— Derek Evermore

Może to prowadzić do problemów, gdy aplikacja jest wdrażana na serwerze, ponieważ zestaw może nie zostać tam znaleziony.

— marsze

9

jeśli jest to wersja 64-bitowa - C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell ** 3.0 **

a wersja może być inna

— pradeep
źródło

2

Użyłem menu VS Project Reference i przejrzałem do: C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation i dodałem odniesienie do biblioteki dll i Runspaces dll.

Nie musiałem hakować pliku .csprj i dodawać wspomnianej powyżej linii odniesienia. Nie mam zainstalowanego zestawu Windows SDK.

Zrobiłem wspomnianą powyżej kopię Powershell: Copy ([PSObject] .Assembly.Location) C: \

Mój test z poleceniem Get-Process Powershell zadziałał. Użyłem przykładów z Powershell dla programistów w rozdziale 5.

— dpminusa
źródło

1

Zestaw pochodzący z Powershell SDK (C: \ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ v1.0) nie zawiera określonych typów programu Powershell 2.

Ręczna edycja pliku csproj rozwiązała mój problem.

— Radu
źródło

0

Możesz również użyć nuget: https://www.nuget.org/packages/System.Management.Automation/ To może być lepsza opcja.

— NOWAN
źródło

Miałem problem z odwołaniem się do poprawnej biblioteki DLL w projekcie, ale ponowne kompilowanie dało błąd, że nie znaleziono pakietu Automation. Użycie Nuget naprawiło to. Upewnij się, że wybrałeś właściwy „Projekt domyślny” w konsoli Menedżera pakietów podczas uruchamiania Install-Package.

— user3523091