Referencing system.management.automation.dll in Visual Studio

Question

I am beginning to look into the PowerShell model and snap-in development. The first thing I notice is to reference System.management.automation.dll. However in Visual Studio, the .NET tab does not have that assembly, and nor is one able browse to

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

to make a file-based reference.

Am i forced to copy the file out manually to make an easy reference?

Could you consider changing the accepted answer for this one? The NuGet package approach seems to be the most straightforward and robust. — julealgon, May 15 '15 at 16:23

score 179 · Accepted Answer · edited Jun 14 '18 at 15:16

179

~~System.Management.Automation on Nuget~~

System.Management.Automation.dll on NuGet, newer package from 2015, not unlisted as the previous one!

Microsoft PowerShell team packages un NuGet

Update: package is now owned by PowerShell Team. Huzzah!

edited Jun 14 '18 at 15:16

juFo

17,849
10
105
142

answered Mar 29 '13 at 17:03

skfd

2,528
1
19
29

3

This deserves more up – foobarcode Feb 10 '15 at 15:27
5

I wish Microsoft took ownership of this Nuget since they are so dank with openness this days. – skfd May 15 '15 at 16:33
@skfd Microsoft pretty much owns Nuget already.. The people behind it use microsoft.com emails and NuGet itself is a part of Microsofts .NET Foundation (http://www.dotnetfoundation.org/) – Michael Bisbjerg Feb 02 '16 at 23:11
1

@MichaelBisbjerg, I think he was mostly referring to this specific NuGet package. If it was Microsoft owned, then (in an ideal world) they would be responsible for keeping it updated, releasing new packages, etc. – Ben Randall Feb 05 '16 at 19:24
last updated 29/03/2013 " The owner has unlisted this package. This could mean that the package is deprecated or shouldn't be used anymore." – juFo Jun 14 '18 at 15:13
3

2nd item is now also unlisted, and the 3rd item relies on .net 5.0 or core. warhgarbl how are we supposed to handle this for .net 4.X applications – Tim Sparkles Jun 17 '21 at 19:39

score 98 · Answer 2 · answered Jul 27 '09 at 12:46

98

A copy of System.Management.Automation.dll is installed when you install the windows SDK (a suitable, recent version of it, anyway). It should be in C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\

answered Jul 27 '09 at 12:46

tomasr

13,683
3
38
30

2

I've installed the SDK on 2 different 64-bit machines (with difficulty) and found the version 6.2.8229.0, 4.66MB dll on only 1, and only in c:\program files (x86)\reference assemblies\microsoft\windowspowershell\v1.0. I highly recommend editing the .csproj file, or checking in the right DLL to source control and referencing it. The SDK install is just too inflexible. – James McLachlan May 08 '12 at 15:11
@ashes999 PowerShell 2.0 actually runs on the 1.0 DLL. – kravits88 Sep 23 '13 at 12:16
4

2014.07.11 on x64 its in C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0\System.Management.Automation.dll – Christopher G. Lewis Jul 11 '14 at 23:50
I don't know about SDK, but I know that WMF 3.0 *does not* install it into C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0. I wanted to install PowerShell 3.0 on a Windows 7 SP1 which had the version 1.0 located in C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\1.0 and I used the Windows6.1-KB2506143-x64.msi from https://www.microsoft.com/en-us/download/details.aspx?id=34595 and it run successfully. However it created the *.dll only in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation/v4.0_3.0.0.0__31bf3856ad364e35. – Alexander Samoylov Apr 08 '19 at 13:41
It's a proper *.dll, because the command "powershell.exe -version 3.0" stops working if I move the *.dll. The size of the *.dll differs from the one which is present by default on another Windows 10 machine in the C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0. I can create the folder C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0 on Windows 7 SP1 machine and put there the *.dll from C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation/v4.0_3.0.0.0__31bf3856ad364e35, but the question is, how to install it properly. – Alexander Samoylov Apr 08 '19 at 13:44

score 93 · Answer 3 · answered Nov 21 '12 at 03:34

93

If you don't want to install the Windows SDK you can get the dll by running the following command in powershell:

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

answered Nov 21 '12 at 03:34

kravits88

12,431
1
51
53

3

Very sweet. Would not have thought of that. – Marius May 08 '13 at 12:10
Thanks for this. The NuGet package would not work for me in a brand new .NET 4.5.2 console app. It "installed" the package, but it refused to add the reference. I finally stopped fighting with NuGet and used your answer to add the reference manually. Thanks! – Lews Therin Feb 05 '19 at 20:40
9+ years after and this is the only relevant answer, because it smartly pulls the location at runtime - definitely should be the accepted one. – Ohad Schneider Jan 04 '22 at 16:45

score 90 · Answer 4 · edited Dec 26 '22 at 23:51

90

I couldn't get the SDK to install properly (some of the files seemed unsigned, something like that). I found another solution here and that seems to work okay for me. It doesn't require installation of new files at all. Basically, what you do is:

Edit the .csproj file in a text editor, and add:

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

to the relevant section.

edited Dec 26 '22 at 23:51

starball

20,030
7
43
238

answered Sep 03 '09 at 08:11

JP.

987
6
2

1

It seems odd to me that we have to do this manually (editing the .csproj file) but it worked for me. – kd7iwp Jul 30 '12 at 21:57
Editing the project file just forces it to load the version from the GAC (which is the V2 version) instead of the file system (which is the V1 version) – Derek Evermore Jul 26 '13 at 14:56
1

This can lead to problems when the app is deployed to the server because the assembly might not be found there. – marsze Aug 03 '17 at 16:10
Still an elegant approach. It worked for me too. – J.Tribbiani Aug 12 '21 at 17:28

score 9 · Answer 5 · answered Nov 15 '13 at 18:59

9

if it is 64bit them - C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell**3.0**

and version could be different

answered Nov 15 '13 at 18:59

pradeep

91
1
1

score 3 · Answer 6 · answered Aug 27 '13 at 19:20

I used the VS Project Reference menu and browsed to: C:\windows\assembly\GAC_MSIL\System.Management.Automation and added a reference for the dll and the Runspaces dll.

I did not need to hack the .csprj file and add the reference line mentioned above. I do not have the Windows SDK installed.

I did do the Powershell copy mentioned above: Copy ([PSObject].Assembly.Location) C:\

My test with a Get-Process Powershell command then worked. I used examples from Powershell for developers Chapter 5.

score 3 · Answer 7 · answered Jan 05 '22 at 08:07

As @skfd alludes to above, the System.Management.Automation.dll package is available on NuGet if you are targeting .Net 4.8 or earlier, but is now delisted, so you need to install it manually. eg:

PM >Install-Package System.Management.Automation.dll -Version 10.0.10586

The System.Management.Automation package is also available if you are targeting .Net Core or Framework 5/6 and seems to be the supported package moving forward. You could also try installing this package and adding the reference manually, but YMMV.

score 2 · Answer 8 · answered Oct 29 '10 at 10:02

2

The assembly coming with Powershell SDK (C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0) does not come with Powershell 2 specific types.

Manually editing the csproj file solved my problem.

answered Oct 29 '10 at 10:02

Radu

631
1
5
6

score 0 · Answer 9 · answered Jan 10 '15 at 12:19

0

You can also use nuget: https://www.nuget.org/packages/System.Management.Automation/ It is maybe a better option.

answered Jan 10 '15 at 12:19

NOWAN

57
3

I had the problem that the correct DLL was referenced in the project, but rebuild gave an error that the Automation package was not found. Using Nuget fixed this. Make sure you select the right "Default project" in the Package Manager Console when running Install-Package. – user3523091 Nov 28 '15 at 08:22
1

This won't work for PowerShell 5.1. That package is only for PS 6/7. – cbeckner Jan 07 '21 at 14:23
2

Requires .NET 5.0. – Mike Lowery Feb 19 '21 at 19:04

Referencing system.management.automation.dll in Visual Studio

9 Answers9

Linked