Référencement de system.management.automation.dll dans Visual Studio

131

Je commence à me pencher sur le modèle PowerShell et le développement de composants logiciels enfichables. La première chose que je remarque est de faire référence à System.management.automation.dll. Toutefois, dans Visual Studio, l'onglet .NET n'a pas cet assembly et il n'est pas non plus possible d'accéder à

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

pour créer une référence basée sur un fichier.

Suis-je obligé de copier le fichier manuellement pour faire une référence facile ?

visual-studio powershell

— icelava
source

Pourriez-vous envisager de changer la réponse acceptée pour celle-ci? L'approche du package NuGet semble être la plus simple et la plus robuste.

— julealgon

165

~~System.Management.Automation sur Nuget~~

System.Management.Automation.dll sur NuGet , package plus récent de 2015, non répertorié comme le précédent!

Packages de l'équipe Microsoft PowerShell un NuGet

Mise à jour: le package appartient désormais à PowerShell Team. Huzzah!

— skfd
source

2

Cela mérite plus

— foobarcode

5

J'aurais aimé que Microsoft s'approprie ce Nuget car ils sont tellement ouverts ces jours-ci.

— skfd

@skfd Microsoft possède déjà à peu près Nuget .. Les personnes derrière lui utilisent les courriels de microsoft.com et NuGet lui-même fait partie de la Fondation Microsoft .NET ( dotnetfoundation.org )

— Michael Bisbjerg

1

@MichaelBisbjerg, je pense qu'il faisait principalement référence à ce package NuGet spécifique. S'il appartenait à Microsoft, alors (dans un monde idéal), ils seraient chargés de le maintenir à jour, de publier de nouveaux packages, etc.

— Ben Randall

dernière mise à jour 29/03/2013 "Le propriétaire a désenregistré ce package. Cela pourrait signifier que le package est obsolète ou ne devrait plus être utilisé."

— juFo

97

Une copie de System.Management.Automation.dll est installée lorsque vous installez le SDK Windows (une version adaptée et récente de celui-ci, de toute façon). Il doit être dans C: \ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ v1.0 \

— Tomasr
source

2

J'ai installé le SDK sur 2 machines 64 bits différentes (avec difficulté) et j'ai trouvé la version 6.2.8229.0, 4.66MB dll sur seulement 1, et uniquement dans c: \ program files (x86) \ reference assemblies \ microsoft \ windowspowershell \ v1.0. Je recommande vivement de modifier le fichier .csproj ou de vérifier la bonne DLL pour le contrôle de code source et de le référencer. L'installation du SDK est tout simplement trop rigide.

— James McLachlan

@ ashes999 PowerShell 2.0 s'exécute en fait sur la DLL 1.0.

— kravits88

3

2014.07.11 sur x64 son dans C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 \ System.Management.Automation.dll

— Christopher G. Lewis

Je ne connais pas le SDK, mais je sais que WMF 3.0 ne l' installe pas dans C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0. Je voulais installer PowerShell 3.0 sur un Windows 7 SP1 qui avait la version 1.0 située dans C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 1.0 et j'ai utilisé le Windows6.1-KB2506143-x64.msi de Microsoft .com / en-us / download / details.aspx? id = 34595 et il s'exécute correctement Cependant, il a créé le * .dll uniquement dans C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35.

— Alexander Samoylov

C'est un * .dll approprié, car la commande "powershell.exe -version 3.0" cesse de fonctionner si je déplace le * .dll. La taille du * .dll diffère de celle qui est présente par défaut sur une autre machine Windows 10 dans le dossier C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0. Je peux créer le dossier C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ 3.0 sur la machine Windows 7 SP1 et y placer le * .dll de C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System. Management.Automation / v4.0_3.0.0.0__31bf3856ad364e35, mais la question est de savoir comment l'installer correctement.

— Alexander Samoylov

85

Si vous ne souhaitez pas installer le SDK Windows, vous pouvez obtenir la DLL en exécutant la commande suivante dans PowerShell:

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

— kravits88
source

8

Maintenant c'est génial!

— 8DH

2

Très sucré. J'aurais pas pensé à ça.

— Marius

Merci pour cela. Le package NuGet ne fonctionnerait pas pour moi dans une toute nouvelle application console .NET 4.5.2. Il a "installé" le package, mais il a refusé d'ajouter la référence. J'ai finalement arrêté de me battre avec NuGet et j'ai utilisé votre réponse pour ajouter la référence manuellement. Merci!

— Lews Therin

77

Je n'ai pas pu installer correctement le SDK (certains fichiers semblaient non signés, quelque chose comme ça). J'ai trouvé une autre solution ici et cela semble bien fonctionner pour moi. Il ne nécessite pas du tout l'installation de nouveaux fichiers. En gros, ce que vous faites est:

Modifiez le fichier .csproj dans un éditeur de texte et ajoutez:

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

à la section correspondante.

J'espère que cela t'aides.

— JP.
source

1

Il me semble étrange que nous devions faire cela manuellement (éditer le fichier .csproj) mais cela a fonctionné pour moi.

— kd7iwp

La modification du fichier de projet l'oblige simplement à charger la version du GAC (qui est la version V2) au lieu du système de fichiers (qui est la version V1)

— Derek Evermore

Cela peut entraîner des problèmes lorsque l'application est déployée sur le serveur, car l'assembly peut ne pas s'y trouver.

— marsze

9

s'il s'agit de 64 bits - C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ WindowsPowerShell ** 3.0 **

et la version pourrait être différente

— pradeep
source

2

J'ai utilisé le menu VS Project Reference et parcouru: C: \ windows \ assembly \ GAC_MSIL \ System.Management.Automation et ajouté une référence pour la dll et la dll Runspaces.

Je n'ai pas eu besoin de pirater le fichier .csprj et d'ajouter la ligne de référence mentionnée ci-dessus. Je n'ai pas installé le SDK Windows.

J'ai fait la copie Powershell mentionnée ci-dessus: Copy ([PSObject] .Assembly.Location) C: \

Mon test avec une commande Get-Process Powershell a ensuite fonctionné. J'ai utilisé des exemples de Powershell pour les développeurs Chapitre 5.

— dpminusa
source

1

L'assembly fourni avec le SDK Powershell (C: \ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ v1.0) n'est pas fourni avec les types spécifiques de Powershell 2.

L'édition manuelle du fichier csproj a résolu mon problème.

— Radu
source

0

Vous pouvez également utiliser nuget: https://www.nuget.org/packages/System.Management.Automation/ C'est peut-être une meilleure option.

— NOWAN
source

J'ai eu le problème que la DLL correcte était référencée dans le projet, mais la reconstruction a donné une erreur indiquant que le package Automation n'a pas été trouvé. L'utilisation de Nuget a résolu ce problème. Assurez-vous de sélectionner le bon "Projet par défaut" dans la console du gestionnaire de package lors de l'exécution d'Install-Package.

— user3523091