Versioning Confusion in System.Management.Automation.dll

The location of the path varies across different operating systems. The following paths contain the desired location but GAC paths should be avoided: C:Program FilesReference AssembliesMicrosoftWindowsPowerShellv1.0 for win2k8 r2 and C:Program Files (x86)Reference AssembliesMicrosoftWindowsPowerShellv1.0 for Win7 x64. How can I reference this assembly in a way that is compatible with multiple OS versions? Specifically, I need [poshrunner.exe] to execute a script in a PowerShell version 2.0 environment on a machine that has PowerShell version 3.0 installed.


In my project, I created a ”
core” assembly
” with PowerShell Cmdlets written in C#. To use and compile the “core” assembly, I also developed an application ”
WPF “gui
” that depends on it. To ensure PowerShell’s types are available, I added a reference to ”


” by simply including the DLL from my local machine’s GAC. The project compiles and runs smoothly on my machine with these changes.

Upon executing my “gui” on a separate device, I encounter peculiar issues, such as the following:

System.MissingMethodException: Method not found: 'System.Management.Automation.PSDataCollection`1 System.Management.Automation.PSDataStreams.get_Information()'

After conducting an investigation, I discovered that the issue is related to my “gui”. To provide more context, my “gui” involves utilizing a customized PowerShell host. The “core” is loaded and its cmdlets are executed through this host. This process is implemented in the following manner:

  Host = new MyCustomHost();
  var rs = RunspaceFactory.CreateRunspace(Host);
  PsInstance = PowerShell.Create();
  PsInstance.Runspace = rs;
  PsInstance.Streams.Information.DataAdded += delegate (object s, DataAddedEventArgs e)

It seems that the


property cannot be located at runtime.

Upon adding


as a reference to the project, I discovered that it may not be the version that is actually loaded. This is because the framework searches for a copy in the GAC and utilizes it instead if found.

The reason for the issue is that the version of
PowerShell installed
on the deployment machine is outdated and lacks the implementation of the property I am utilizing, resulting in the thrown exception.

My confusion lies in the fact that the framework is able to load the assembly from the GAC despite its incompatibility with the one I have built against.

To my understanding, the assembly is identified by the framework through its AssemblyVersion, Name, and PublicKeyToken.

My local assembly (working):

Assembly Location: C:WINDOWSMicrosoft.NetassemblyGAC_MSILSystem.Management.Automationv4.0_3.0.0.0__31bf3856ad364e35System.Management.Automation.dll
Assembly Fullname: System.Management.Automation, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
File ProductVersion: 10.0.14393.1532
File Size: 7,1MB

server assembly
(not working):

Assembly Location: C:WindowsMicrosoft.NetassemblyGAC_MSILSystem.Management.Automationv4.0_3.0.0.0__31bf3856ad364e35System.Management.Automation.dll
Assembly Fullname: System.Management.Automation, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
File ProductVersion: 6.3.9600.18728
File Size: 5,8MB

Although the two files are undoubtedly distinct, they are deemed identical by AssemblyName. Consequently, the framework will only load one of them.

Is it possible for two files with different sizes to share the same AssemblyName?

Besides the Windows Server 2012R2, I have observed the same issue on a Windows 7 machine and another Windows 2012 Server.


After facing issues, I opted for the official Powershell reference asseblies packages available on NuGet. Consequently, I now mostly rely on


to maintain compatibility, and since then, I haven’t encountered any further problems.

Frequently Asked Questions