Verweisen auf system.management.automation.dll in Visual Studio

131

Ich beginne mich mit dem PowerShell-Modell und der Snap-In-Entwicklung zu befassen. Das erste, was mir auffällt, ist, auf System.management.automation.dll zu verweisen. In Visual Studio verfügt die Registerkarte .NET jedoch nicht über diese Assembly und kann auch nicht zu dieser Assembly navigieren

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

um eine dateibasierte Referenz zu erstellen.

Bin ich gezwungen, die Datei manuell zu kopieren, um eine einfache Referenz zu erhalten ?

visual-studio powershell

— Icelava
quelle

Könnten Sie in Betracht ziehen, die akzeptierte Antwort für diese zu ändern? Der NuGet-Paketansatz scheint der einfachste und robusteste zu sein.

— Julealgon

165

~~System.Management.Automation auf Nuget~~

System.Management.Automation.dll auf NuGet , neueres Paket von 2015, nicht wie das vorherige nicht gelistet!

Microsoft PowerShell-Teampakete un NuGet

Update: Das Paket gehört jetzt dem PowerShell-Team. Huzzah!

— skfd
quelle

2

Dies verdient mehr up

— foobarcode

5

Ich wünschte, Microsoft hätte dieses Nuget in Besitz genommen, da es heutzutage so offen ist.

— Skfd

@skfd Microsoft besitzt Nuget schon so ziemlich. Die Leute dahinter verwenden E-Mails von microsoft.com und NuGet selbst ist Teil der Microsoft .NET Foundation ( dotnetfoundation.org )

— Michael Bisbjerg

1

@ MichaelBisbjerg, ich denke, er bezog sich hauptsächlich auf dieses spezielle NuGet-Paket. Wenn es Microsoft gehört, sind sie (in einer idealen Welt) dafür verantwortlich, es auf dem neuesten Stand zu halten, neue Pakete zu veröffentlichen usw.

— Ben Randall

Letzte Aktualisierung 29.03.2013 "Der Eigentümer hat dieses Paket nicht gelistet. Dies kann bedeuten, dass das Paket veraltet ist oder nicht mehr verwendet werden sollte."

— 14.

97

Eine Kopie von System.Management.Automation.dll wird installiert, wenn Sie das Windows SDK installieren (jedenfalls eine geeignete, aktuelle Version davon). Es sollte sich in C: \ Programme \ Referenzassemblies \ Microsoft \ WindowsPowerShell \ v1.0 \ befinden

— tomasr
quelle

2

Ich habe das SDK auf 2 verschiedenen 64-Bit-Computern (mit Schwierigkeiten) installiert und die Version 6.2.8229.0, 4,66 MB DLL nur auf 1 und nur in c: \ Programme (x86) \ Referenzassemblies \ Microsoft \ Windowspowershell gefunden \ v1.0. Ich empfehle dringend, die .csproj-Datei zu bearbeiten oder die richtige DLL für die Quellcodeverwaltung einzuchecken und darauf zu verweisen. Die SDK-Installation ist einfach zu unflexibel.

— James McLachlan

@ ashes999 PowerShell 2.0 läuft tatsächlich auf der 1.0-DLL.

— Kravits88

3

2014.07.11 auf x64 ist in C: \ Programme (x86) \ Referenzassemblies \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll

— Christopher G. Lewis

Ich weiß nichts über SDK, aber ich weiß, dass WMF 3.0 es nicht in C: \ Programme (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 installiert. Ich wollte PowerShell 3.0 unter Windows 7 SP1 installieren, dessen Version 1.0 sich unter C: \ Programme (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 1.0 befindet, und habe Windows6.1-KB2506143-x64.msi von Microsoft verwendet .com / de-de / download / details.aspx? id = 34595 und es wird erfolgreich ausgeführt. Die * .dll wurde jedoch nur in C: \ Windows \ Microsoft.NET \ Assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35 erstellt.

— Alexander Samoylov

Es ist eine richtige * .dll, da der Befehl "Powershell.exe -version 3.0" nicht mehr funktioniert, wenn ich die * .dll verschiebe. Die Größe der * .dll unterscheidet sich von der Größe, die standardmäßig auf einem anderen Windows 10-Computer unter C: \ Programme (x86) \ Referenzassemblies \ Microsoft \ WindowsPowerShell \ 3.0 vorhanden ist. Ich kann den Ordner C: \ Programme (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 auf einem Windows 7 SP1-Computer erstellen und dort die * .dll aus C: \ Windows \ Microsoft.NET \ Assembly \ GAC_MSIL \ System ablegen. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, aber die Frage ist, wie man es richtig installiert.

— Alexander Samoylov

85

Wenn Sie das Windows SDK nicht installieren möchten, können Sie die DLL abrufen, indem Sie den folgenden Befehl in Powershell ausführen:

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

— kravits88
quelle

8

Das ist großartig!

— 8DH

2

Sehr süß. Daran hätte ich nicht gedacht.

— Marius

Danke dafür. Das NuGet-Paket würde in einer brandneuen .NET 4.5.2-Konsolen-App für mich nicht funktionieren. Es "installierte" das Paket, weigerte sich jedoch, die Referenz hinzuzufügen. Ich habe endlich aufgehört, mit NuGet zu kämpfen, und Ihre Antwort verwendet, um die Referenz manuell hinzuzufügen. Vielen Dank!

— Lews Therin

77

Ich konnte das SDK nicht richtig installieren (einige der Dateien schienen nicht signiert zu sein, so etwas). Ich habe hier eine andere Lösung gefunden und das scheint für mich in Ordnung zu sein. Es ist überhaupt keine Installation neuer Dateien erforderlich. Grundsätzlich tun Sie Folgendes:

Bearbeiten Sie die .csproj-Datei in einem Texteditor und fügen Sie Folgendes hinzu:

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

zum entsprechenden Abschnitt.

Hoffe das hilft.

— JP.
quelle

1

Es scheint mir seltsam, dass wir dies manuell tun müssen (Bearbeiten der .csproj-Datei), aber es hat bei mir funktioniert.

— kd7iwp

Durch das Bearbeiten der Projektdatei wird lediglich die Version aus dem GAC (der V2-Version) anstelle des Dateisystems (der V1-Version)

— geladen

Dies kann zu Problemen führen, wenn die App auf dem Server bereitgestellt wird, da die Assembly dort möglicherweise nicht gefunden wird.

— Marsze

9

Wenn es sich um 64-Bit handelt - C: \ Programme (x86) \ Referenzassemblies \ Microsoft \ WindowsPowerShell ** 3.0 **

und Version könnte unterschiedlich sein

— pradeep
quelle

2

Ich habe das VS-Projektreferenzmenü verwendet und zu C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation navigiert und eine Referenz für die DLL und die Runspaces-DLL hinzugefügt.

Ich musste die .csprj-Datei nicht hacken und die oben erwähnte Referenzzeile hinzufügen. Ich habe das Windows SDK nicht installiert.

Ich habe die oben erwähnte Powershell-Kopie erstellt: Copy ([PSObject] .Assembly.Location) C: \

Mein Test mit einem Get-Process Powershell-Befehl hat dann funktioniert. Ich habe Beispiele aus Powershell für Entwickler verwendet. Kapitel 5.

— dpminusa
quelle

1

Die mit dem Powershell SDK (C: \ Programme \ Referenzassemblies \ Microsoft \ WindowsPowerShell \ v1.0) gelieferte Assembly enthält keine Powershell 2-spezifischen Typen.

Das manuelle Bearbeiten der csproj-Datei hat mein Problem gelöst.

— Radu
quelle

0

Sie können auch nuget verwenden: https://www.nuget.org/packages/System.Management.Automation/ Dies ist möglicherweise eine bessere Option.

— NOWAN
quelle

Ich hatte das Problem, dass im Projekt auf die richtige DLL verwiesen wurde, aber die Neuerstellung ergab den Fehler, dass das Automatisierungspaket nicht gefunden wurde. Die Verwendung von Nuget hat dies behoben. Stellen Sie sicher, dass Sie in der Package Manager-Konsole das richtige "Standardprojekt" auswählen, wenn Sie Install-Package ausführen.

— user3523091