Powershell: Binary module compiled with PowerShellStandard.Library 3.0.0-preview-01 fails to run in Windows PowerShell

[rkeithhill]

Steps to reproduce

Download and install the .NET Core 2.0 SDK.

dotnet new classlib --name psmodule
cd psmodule
dotnet add package PowerShellStandard.Library --version 3.0.0-preview-01
Remove-Item .\Class1.cs
@'
using System.Management.Automation;

namespace PSCmdlet3
{
    [Cmdlet("Get", "Foo")]
    public class GetFooCommand : PSCmdlet
    {
        [Parameter]
        public string Name { get; set; } = string.Empty;

        protected override void EndProcessing()
        {
            this.WriteObject("Foo is " + this.Name);
            base.EndProcessing();
        }
    }
}
'@ | Out-File GetFooCommand.cs -Encoding UTF8
dotnet build
cd .\bin\Debug\netstandard2.0\
ipmo .\psmodule.dll
get-foo

Expected behavior

This should work in PowerShell Core and in Windows PowerShell 5.1.

Actual behavior

The binary module loads into Windows PowerShell but fails when executed with this error:

get-foo : Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
At line:1 char:1
+ get-foo
+ ~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], FileNotFoundException
    + FullyQualifiedErrorId : System.IO.FileNotFoundException

I guess I missing a shim assembly. Could this be packaged with PSStandard.Lib? If not, we need to make sure we document any other required pkgs.

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.15063.608
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.608
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PSRemotingProtocolVersion      2.3

[rkeithhill]

If I execute the following, the error goes away:

Add-Type -Path "c:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0\net
standard.dll"

[iSazonov]

It seems related https://github.com/dotnet/standard/issues/328

[rkeithhill]

Yeah, but the solution mentioned in that issue is that the .NET Framework app i.e. Windows PowerShell 5.1, has to be compiled with the package NETStandard.Library. That's a problem. :-(

[SteveL-MSFT]

I believe dotnet 4.7.1 will fix this https://blogs.msdn.microsoft.com/dotnet/2017/09/28/net-framework-4-7-1-runtime-and-compiler-features/

[joeyaiello]

@rkeithhill looks like you're right about needing a reference to NETStandard.Library in your .NET Framework project. For now, we need to doc this scenario end-to-end (including the need for that reference), and talk to @terrajobst about the best we should handle this more generally (whether that's shipping a module to the Gallery wrapping those DLLs for folks to depend on, or something else).

[terrajobst]

The host process should probably deploy the necessary facades and binding redirects for .NET Framework 4.6.1, 4.6.2, and 4.7. Starting with .NET 4.7.1 you no longer need that many files but due to a bug on our end it seems there are still two files necessary (System.Net.Http and System.IO.Compression). Let me know if you need more details for any of this.

[rkeithhill]

So PowerShell, as the host process, should be updated to deploy the appropriate facades and binding redirects. This doesn't sound like a "recompile" of PowerShell is required. I wonder if an update pkg can be created to add these to an existing Windows PowerShell 5.1 installation?

I'm guessing recompiling and shipping an updated Windows PowerShell (5.2) would be a much bigger deal given the team is focused primarily on PowerShell Core atm.

[terrajobst]

So PowerShell, as the host process, should be updated to deploy the appropriate facades and binding redirects. This doesn't sound like a "recompile" of PowerShell is required. I wonder if an update pkg can be created to add these to an existing Windows PowerShell 5.1 installation?

Technically yes. Practically, I wouldn't mess with the program files directory as this is owned by the application (and its setup).

[rkeithhill]

@terrajobst Agreed. I wasn't suggesting that folks outside of Microsof attempt this. I was just hoping that it would be easier (and therefore much more likely to get done) if Microsoft could issue a Windows PowerShell 5.1 patch to add this stuff. I figured if Microsoft had to recompile and issue a new WMF 5.2, that would take a long time to happen. :-)

[terrajobst]

Maybe :-) That's for @joeyaiello's team to decide. I just had to share my two cents ;-)

[jherby2k]

The host process should probably deploy the necessary facades and binding redirects for .NET Framework 4.6.1, 4.6.2, and 4.7. Starting with .NET 4.7.1 you no longer need that many files but due to a bug on our end it seems there are still two files necessary (System.Net.Http and System.IO.Compression). Let me know if you need more details for any of this.

By a bug on your end, do you mean that this can be fixed in PowerShellStandard.Library and/or PowerShell Core 6 before RTM?

I'm wondering if i'll be able to ship my cmdlet library on Windows with .NET 4.7.1 and have it work with PowerShell 5.1, or if i'm going to need to ship .NET Core and PowerShell 6 with it as well. I was under the impression this would be more seamless...

[rkeithhill]

Good news. I just tried this experiment on the Windows 10 FCU 16299.15 build which I think has 4.7.1 on it. The Release reg val is 461308 which is higher than the one for 4.7. Anyway, the above scenario works without having to run Add-Type -Path <path>\netstandard.dll.

I'll be submitting a PR tonight for a doc page on a command-line version of creating a simple, portable binary module. Of course, the proviso is that you have to have .NET 4.7.1 installed or be on Windows 10 FCU or higher. I think this can live side-by-side with the PR for a version that uses Visual Studio. Certainly folks that are on Linux, won't be able to use Visual Studio. Later we can put up a page that shows how to do this with Visual Studio Code on Linux/macOS.

[rkeithhill]

@terrajobst re:

deploy the necessary facades and binding redirects for .NET Framework 4.6.1, 4.6.2, and 4.7.

Do you have a link to a resource that describes this process in depth?

Nevermind. Found this -
https://www.youtube.com/watch?v=vg6nR7hS2lI&index=4&list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY

[rkeithhill]

OK, got the PR submitted for creating a simple, portable binary module using the dotnet CLI - #5117

[rkeithhill]

I'm wondering if i'll be able to ship my cmdlet library on Windows with .NET 4.7.1 and have it work with PowerShell 5.1

FYI, this scenario appears to work in my limited testing. Plus that is one of the issues 4.7.1 was designed to rectify.

[iSazonov]

Can we close the Issue?

[SteveL-MSFT]

I think we can close this and any new issues should be new issues.