Riferimenti a system.management.automation.dll in Visual Studio

131

Sto iniziando a esaminare il modello PowerShell e lo sviluppo degli snap-in. La prima cosa che noto è fare riferimento a System.management.automation.dll. Tuttavia, in Visual Studio, la scheda .NET non ha quell'assemblaggio e non è possibile passare a

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

per fare un riferimento basato su file.

Sono costretto a copiare il file manualmente per fare un riferimento facile ?

visual-studio powershell

— icelava
fonte

Potresti considerare di cambiare la risposta accettata per questa? L'approccio del pacchetto NuGet sembra essere il più semplice e robusto.

— julealgon,

165

~~System.Management.Automation su Nuget~~

System.Management.Automation.dll su NuGet , pacchetto più recente dal 2015, non elencato come il precedente!

Pacchetti del team di Microsoft PowerShell un NuGet

Aggiornamento: il pacchetto è ora di proprietà del team PowerShell. Huzzah!

— skfd
fonte

2

Questo merita di più

— foobarcode,

5

Vorrei che Microsoft prendesse la proprietà di questo Nuget poiché sono così umidi di apertura al giorno d'oggi.

— skfd,

@skfd Microsoft praticamente possiede già Nuget .. Le persone dietro di esso usano le e-mail microsoft.com e NuGet stesso fa parte della Microsofts .NET Foundation ( dotnetfoundation.org )

— Michael Bisbjerg,

1

@MichaelBisbjerg, penso che si riferisse principalmente a questo specifico pacchetto NuGet. Se fosse di proprietà di Microsoft, allora (in un mondo ideale) sarebbero responsabili di mantenerlo aggiornato, di rilasciare nuovi pacchetti, ecc.

— Ben Randall,

ultimo aggiornamento 29/03/2013 "Il proprietario non ha elencato questo pacchetto. Ciò potrebbe significare che il pacchetto è obsoleto o non dovrebbe più essere utilizzato."

— juFo

97

Una copia di System.Management.Automation.dll viene installata quando si installa Windows SDK (una versione adatta e recente di esso, comunque). Dovrebbe essere in C: \ Programmi \ Gruppi di riferimento \ Microsoft \ WindowsPowerShell \ v1.0 \

— tomasr
fonte

2

Ho installato l'SDK su 2 diverse macchine a 64 bit (con difficoltà) e ho trovato la versione 6.2.8229.0, 4.66 MB dll su solo 1 e solo in c: \ programmi (x86) \ assembly di riferimento \ microsoft \ windowspowershell \ v1.0. Consiglio vivamente di modificare il file .csproj o di controllare la DLL corretta per il controllo del codice sorgente e fare riferimento a esso. L'installazione dell'SDK è troppo rigida.

— James McLachlan,

@ ashes999 PowerShell 2.0 viene effettivamente eseguito sulla DLL 1.0.

— kravits88,

3

2014.07.11 su x64 è in C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll

— Christopher G. Lewis

Non conosco SDK, ma so che WMF 3.0 non lo installa in C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell \ 3.0. Volevo installare PowerShell 3.0 su Windows 7 SP1 che aveva la versione 1.0 che si trova in C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell \ 1.0 e ho usato Windows6.1-KB2506143-x64.msi da microsoft .com / it-it / download / details.aspx? id = 34595 e funziona correttamente. Tuttavia, ha creato il * .dll solo in C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35.

— Alexander Samoylov,

È un * .dll corretto, perché il comando "powershell.exe -version 3.0" smette di funzionare se sposto il * .dll. La dimensione di * .dll differisce da quella presente per impostazione predefinita su un altro computer Windows 10 in C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell \ 3.0. Posso creare la cartella C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell \ 3.0 sulla macchina Windows 7 SP1 e inserire lì * .dll da C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, ma la domanda è: come installarlo correttamente.

— Alexander Samoylov,

85

Se non si desidera installare Windows SDK, è possibile ottenere la dll eseguendo il seguente comando in PowerShell:

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

— kravits88
fonte

8

Questo è geniale!

— 1113

2

Molto dolce. Non ci avrei pensato.

— Marius,

Grazie per questo. Il pacchetto NuGet non funzionerebbe con me in una nuovissima app console .NET 4.5.2. Ha "installato" il pacchetto, ma ha rifiutato di aggiungere il riferimento. Alla fine ho smesso di combattere con NuGet e ho usato la tua risposta per aggiungere manualmente il riferimento. Grazie!

— Lews Therin,

77

Non è stato possibile installare correttamente l'SDK (alcuni file sembravano non firmati, qualcosa del genere). Ho trovato un'altra soluzione qui e sembra funzionare bene per me. Non richiede affatto l'installazione di nuovi file. Fondamentalmente, quello che fai è:

Modifica il file .csproj in un editor di testo e aggiungi:

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

alla sezione pertinente.

Spero che questo ti aiuti.

— JP.
fonte

1

Mi sembra strano che dobbiamo farlo manualmente (modificando il file .csproj) ma ha funzionato per me.

— kd7iwp,

La modifica del file di progetto costringe semplicemente a caricare la versione dal GAC (che è la versione V2) anziché dal file system (che è la versione V1)

— Derek Evermore,

Ciò può causare problemi quando l'app viene distribuita sul server perché l'assembly potrebbe non essere trovato lì.

— Marsze,

9

se è a 64 bit - C: \ Programmi (x86) \ Assembly Assembly \ Microsoft \ WindowsPowerShell ** 3.0 **

e la versione potrebbe essere diversa

— Pradeep
fonte

2

Ho usato il menu di riferimento del progetto VS e sono passato a: C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation e ho aggiunto un riferimento per la dll e la dll Runpace.

Non ho avuto bisogno di hackerare il file .csprj e aggiungere la linea di riferimento sopra menzionata. Non ho installato Windows SDK.

Ho fatto la copia di Powershell sopra menzionata: Copia ([PSObject] .Assembly.Location) C: \

Il mio test con un comando Get-Process Powershell ha funzionato. Ho usato esempi di Powershell per sviluppatori Capitolo 5.

— dpminusa
fonte

1

L'assembly fornito con Powershell SDK (C: \ Programmi \ Gruppi di riferimento \ Microsoft \ WindowsPowerShell \ v1.0) non viene fornito con tipi specifici di Powershell 2.

La modifica manuale del file csproj ha risolto il mio problema.

— Radu
fonte

0

Puoi anche usare nuget: https://www.nuget.org/packages/System.Management.Automation/ È forse un'opzione migliore.

— NOWAN
fonte

Ho avuto il problema che si riferiva alla DLL corretta nel progetto, ma la ricostruzione ha dato un errore che il pacchetto di automazione non è stato trovato. L'uso di Nuget ha risolto questo problema. Assicurati di selezionare il giusto "Progetto predefinito" nella console di Package Manager quando esegui Install-Package.

— user3523091