Referenciando system.management.automation.dll no Visual Studio


131

Estou começando a analisar o modelo do PowerShell e o desenvolvimento de snap-in. A primeira coisa que noto é fazer referência ao System.management.automation.dll. No entanto, no Visual Studio, a guia .NET não possui esse assembly e nem é possível navegar para

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

para fazer uma referência baseada em arquivo.

Sou forçado a copiar o arquivo manualmente para fazer uma referência fácil ?


Você poderia considerar alterar a resposta aceita para esta? A abordagem do pacote NuGet parece ser a mais direta e robusta.
Julealgon 15/05

Respostas:


165

System.Management.Automation no Nuget

System.Management.Automation.dll no NuGet , pacote mais recente de 2015, não listado como o anterior!

A equipe do Microsoft PowerShell empacota o NuGet

Atualização: o pacote agora pertence à equipe do PowerShell. Huzzah!


2
Isso merece mais
foobarcode

5
Eu gostaria que a Microsoft tomasse posse desse Nuget, pois eles estão tão úmidos com a abertura nos dias de hoje.
Skfd 15/05

@skfd Microsoft praticamente detém Nuget já .. As pessoas por trás dela usar microsoft.com e-mails e da própria NuGet é uma parte de Microsofts .NET Foundation ( dotnetfoundation.org )
Michael Bisbjerg

1
@ MichaelBisbjerg, acho que ele estava se referindo principalmente a este pacote NuGet específico. Se fosse Microsoft propriedade, então (em um mundo ideal) que seria responsável por mantendo-o atualizado, lançando novos pacotes, etc.
Ben Randall

última atualização em 29/03/2013 "O proprietário não listou este pacote. Isso pode significar que o pacote está obsoleto ou não deve mais ser usado."
jufo

97

Uma cópia do System.Management.Automation.dll é instalada quando você instala o SDK do Windows (uma versão recente e adequada do mesmo). Ele deve estar em C: \ Arquivos de programas \ Assemblies de referência \ Microsoft \ WindowsPowerShell \ v1.0 \


2
Instalei o SDK em 2 máquinas diferentes de 64 bits (com dificuldade) e encontrei a versão 6.2.8229.0, dll de 4,66 MB em apenas 1 e apenas em c: \ arquivos de programas (x86) \ assemblies de referência \ microsoft \ windowspowershell \ v1.0. Eu recomendo editar o arquivo .csproj ou verificar a DLL correta para o controle de origem e fazer referência a ele. A instalação do SDK é muito inflexível.
James McLachlan

@ ashes999 O PowerShell 2.0 é executado na DLL 1.0.
precisa saber é o seguinte

3
2014/07/11 em x64 sua em C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll
Christopher G. Lewis

Não sei sobre o SDK, mas sei que o WMF 3.0 não o instala em C: \ Arquivos de Programas (x86) \ Assemblies de Referência \ Microsoft \ WindowsPowerShell \ 3.0. Eu queria instalar o PowerShell 3.0 em um Windows 7 SP1 com a versão 1.0 localizada em C: \ Arquivos de programas (x86) \ Assemblies de referência \ Microsoft \ WindowsPowerShell \ 1.0 e usei o Windows6.1-KB2506143-x64.msi da microsoft .com / pt-br / download / details.aspx? id = 34595 e foi executado com sucesso. No entanto, ele criou o * .dll apenas em C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35.
Alexander Samoylov

É uma * .dll adequada, porque o comando "powershell.exe -version 3.0" para de funcionar se eu mover a * .dll. O tamanho da * .dll difere daquele que está presente por padrão em outra máquina Windows 10 em C: \ Arquivos de programas (x86) \ Assemblies de referência \ Microsoft \ WindowsPowerShell \ 3.0. Posso criar a pasta C: \ Arquivos de programas (x86) \ Assemblies de referência \ Microsoft \ WindowsPowerShell \ 3.0 na máquina Windows 7 SP1 e colocar lá a * .dll em C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, mas a questão é: como instalá-lo corretamente.
Alexander Samoylov

85

Se você não quiser instalar o Windows SDK, poderá obter a dll executando o seguinte comando no powershell:

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

8
Agora isso é brilhante!
8DH

2
Muito doce. Não teria pensado nisso.
Marius

Obrigado por isso. O pacote NuGet não funcionaria para mim em um novo aplicativo de console .NET 4.5.2. Ele "instalou" o pacote, mas se recusou a adicionar a referência. Finalmente parei de brigar com o NuGet e usei sua resposta para adicionar a referência manualmente. Obrigado!
Lews Therin

77

Não consegui instalar o SDK corretamente (alguns dos arquivos pareciam não assinados, algo assim). Encontrei outra solução aqui e que parece funcionar bem para mim. Não requer a instalação de novos arquivos. Basicamente, o que você faz é:

Edite o arquivo .csproj em um editor de texto e adicione:

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

para a seção relevante.

Espero que isto ajude.


1
Parece estranho para mim que tenhamos que fazer isso manualmente (editando o arquivo .csproj), mas funcionou para mim.
Kd7iwp

Editando o arquivo de projeto apenas obriga a carregar a versão do GAC (que é a versão V2) em vez do sistema de arquivos (que é a versão V1)
Derek Evermore

Isso pode causar problemas quando o aplicativo é implantado no servidor porque o assembly pode não ser encontrado lá.
Marsze 17/08

9

se for de 64 bits - C: \ Arquivos de programas (x86) \ Assemblies de referência \ Microsoft \ WindowsPowerShell ** 3.0 **

e versão poderia ser diferente


2

Usei o menu Referência do Projeto VS e naveguei para: C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation e adicionei uma referência para a dll e a dll Runspaces.

Não precisei hackear o arquivo .csprj e adicionar a linha de referência mencionada acima. Eu não tenho o Windows SDK instalado.

Fiz a cópia do Powershell mencionada acima: Copy ([PSObject] .Assembly.Location) C: \

Meu teste com o comando Get-Process Powershell funcionou. Usei exemplos do Powershell para desenvolvedores, capítulo 5.


1

A montagem que vem com o Powershell SDK (C: \ Arquivos de Programas \ Assemblies de Referência \ Microsoft \ WindowsPowerShell \ v1.0) não vem com os tipos específicos do Powershell 2.

A edição manual do arquivo csproj resolveu meu problema.


0

Você também pode usar o nuget: https://www.nuget.org/packages/System.Management.Automation/ É talvez uma opção melhor.


Eu tive o problema de que a DLL correta foi referenciada no projeto, mas a reconstrução deu um erro que o pacote de automação não foi encontrado. Usando Nuget corrigiu isso. Certifique-se de selecionar o "Projeto padrão" correto no Package Manager Console ao executar o Install-Package.
user3523091
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.