Hacer referencia a system.management.automation.dll en Visual Studio

131

Estoy empezando a analizar el modelo de PowerShell y el desarrollo de complementos. Lo primero que noto es hacer referencia a System.management.automation.dll. Sin embargo, en Visual Studio, la pestaña .NET no tiene ese ensamblado, y tampoco se puede navegar hasta

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

para hacer una referencia basada en archivos.

¿Estoy obligado a copiar el archivo manualmente para hacer una referencia fácil ?

visual-studio powershell

— icelava
fuente

¿Podría considerar cambiar la respuesta aceptada para esta? El enfoque del paquete NuGet parece ser el más sencillo y robusto.

— julealgon

165

~~System.Management.Automation en Nuget~~

System.Management.Automation.dll en NuGet , paquete más nuevo de 2015, ¡no figura como el anterior!

El equipo de Microsoft PowerShell empaqueta un NuGet

Actualización: el paquete ahora es propiedad de PowerShell Team. Huzzah!

— skfd
fuente

2

Esto merece más

— foobarcode

55

Desearía que Microsoft tomara posesión de este Nuget, ya que están muy húmedos con la apertura en estos días.

— skfd

@skfd Microsoft ya es propietario de Nuget ... La gente detrás de él usa correos electrónicos de microsoft.com y NuGet es parte de Microsofts .NET Foundation ( dotnetfoundation.org )

— Michael Bisbjerg

1

@MichaelBisbjerg, creo que se refería principalmente a este paquete NuGet específico. Si se trataba de Microsoft propiedad, entonces (en un mundo ideal) que serían responsables de mantenerla actualizada, la liberación de nuevos paquetes, etc

— Ben Randall

última actualización 29/03/2013 "El propietario no ha incluido en la lista este paquete. Esto podría significar que el paquete está en desuso o ya no debe usarse".

— juFo

97

Se instala una copia de System.Management.Automation.dll cuando instala el SDK de Windows (de todos modos, una versión reciente y adecuada del mismo). Debe estar en C: \ Archivos de programa \ Ensamblados de referencia \ Microsoft \ WindowsPowerShell \ v1.0 \

— tomasr
fuente

2

Instalé el SDK en 2 máquinas diferentes de 64 bits (con dificultad) y encontré la versión 6.2.8229.0, 4.66MB dll en solo 1, y solo en c: \ archivos de programa (x86) \ ensambles de referencia \ microsoft \ windowspowershell \ v1.0. Recomiendo editar el archivo .csproj, o verificar la DLL correcta para controlar el origen y hacer referencia a él. La instalación del SDK es demasiado inflexible.

— James McLachlan

@ ashes999 PowerShell 2.0 en realidad se ejecuta en la DLL 1.0.

— kravits88

3

2014.07.11 en x64 está en C: \ Archivos de programa (x86) \ Assemblies de referencia \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll

— Christopher G. Lewis

No sé sobre SDK, pero sé que WMF 3.0 no lo instala en C: \ Archivos de programa (x86) \ Assemblies de referencia \ Microsoft \ WindowsPowerShell \ 3.0. Quería instalar PowerShell 3.0 en Windows 7 SP1 que tenía la versión 1.0 ubicada en C: \ Archivos de programa (x86) \ Assemblies de referencia \ Microsoft \ WindowsPowerShell \ 1.0 y utilicé Windows6.1-KB2506143-x64.msi de microsoft .com / es-us / download / details.aspx? id = 34595 y se ejecuta con éxito. Sin embargo, creó el * .dll solo en C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35.

— Alexander Samoylov

Es un * .dll apropiado, porque el comando "powershell.exe -version 3.0" deja de funcionar si muevo el * .dll. El tamaño de * .dll difiere del que está presente de manera predeterminada en otra máquina con Windows 10 en C: \ Archivos de programa (x86) \ Assemblies de referencia \ Microsoft \ WindowsPowerShell \ 3.0. Puedo crear la carpeta C: \ Archivos de programa (x86) \ Assemblies de referencia \ Microsoft \ WindowsPowerShell \ 3.0 en la máquina con Windows 7 SP1 y colocar allí el * .dll desde C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, pero la pregunta es cómo instalarlo correctamente.

— Alexander Samoylov

85

Si no desea instalar el SDK de Windows, puede obtener el dll ejecutando el siguiente comando en powershell:

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

— kravits88
fuente

8

Ahora que es genial!

— 8DH

2

Muy dulce. No habría pensado en eso.

— Marius

Gracias por esto. El paquete NuGet no funcionaría para mí en una nueva aplicación de consola .NET 4.5.2. "Instaló" el paquete, pero se negó a agregar la referencia. Finalmente dejé de pelear con NuGet y usé tu respuesta para agregar la referencia manualmente. ¡Gracias!

— Lews Therin

77

No pude hacer que el SDK se instalara correctamente (algunos de los archivos parecían sin firmar, algo así). Encontré otra solución aquí y eso parece funcionar bien para mí. No requiere la instalación de nuevos archivos en absoluto. Básicamente, lo que haces es:

Edite el archivo .csproj en un editor de texto y agregue:

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

a la sección correspondiente.

Espero que esto ayude.

— JP.
fuente

1

Me parece extraño que tengamos que hacer esto manualmente (editando el archivo .csproj) pero funcionó para mí.

— kd7iwp

Editar el archivo del proyecto solo lo obliga a cargar la versión del GAC (que es la versión V2) en lugar del sistema de archivos (que es la versión V1)

— Derek Evermore

Esto puede generar problemas cuando la aplicación se implementa en el servidor porque es posible que el ensamblado no se encuentre allí.

— marsze

9

si es de 64 bits: C: \ Archivos de programa (x86) \ Ensamblados de referencia \ Microsoft \ WindowsPowerShell ** 3.0 **

y la versión podría ser diferente

— pradeep
fuente

2

Utilicé el menú de referencia del proyecto VS y busqué: C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation y agregué una referencia para el dll y el Runspaces dll.

No necesitaba hackear el archivo .csprj y agregar la línea de referencia mencionada anteriormente. No tengo instalado el SDK de Windows.

Hice la copia de Powershell mencionada anteriormente: Copia ([PSObject] .Assembly.Location) C: \

Mi prueba con un comando Get-Process Powershell funcionó. Usé ejemplos de Powershell para desarrolladores Capítulo 5.

— dpminusa
fuente

1

El ensamblado que viene con Powershell SDK (C: \ Archivos de programa \ Ensambles de referencia \ Microsoft \ WindowsPowerShell \ v1.0) no viene con los tipos específicos de Powershell 2.

La edición manual del archivo csproj resolvió mi problema.

— Radu
fuente

0

También puede usar nuget: https://www.nuget.org/packages/System.Management.Automation/ Es quizás una mejor opción.

— NOWAN
fuente

Tuve el problema de que se hizo referencia a la DLL correcta en el proyecto, pero la reconstrucción dio un error de que no se encontró el paquete de automatización. Usar Nuget solucionó esto. Asegúrese de seleccionar el "Proyecto predeterminado" correcto en la consola de Package Manager cuando ejecute Install-Package.

— user3523091