Powershell: Regression: NuGet package System.Management.Automation stopped supporting projects that targets netstandard2.0 since 6.1.3

[bergmeister]

Steps to reproduce

mkdir foo
cd foo
dotnet new classlib # make a .project that targets Net Standard 2.0
dotnet add package System.Management.Automation # adds a reference to SMA 6.2.2

Expected behavior

No errors, i.e. dotnet restore (which is done automatically as part of the dotnet add package command) works fine.

Actual behavior

Error, cannot build or even restore project:

error: Package System.Management.Automation 6.2.2 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package System.Management.Automation 6.2.2 supports: netcoreapp2.1 (.NETCoreApp,Version=v2.1)
error: Package 'System.Management.Automation' is incompatible with 'all' frameworks in project 'C:\Users\christoph.bergmeiste\git\psscriptanalyzer\foo\foo.csproj'.

Environment data

This has worked fine for the SMA NuGet package of version 6.1.0 but not for the latest supported versions 6.1.5 or 6.2.2. Going through the history, it stopped working at version 6.1.3 and does not work for any version of 6.2(!)

cc @felixfbecker

[iSazonov]

If I remember right we target NETCoreApp2.0 starting with first day after moving to .Net Core 2.0.
See dependencies here https://www.nuget.org/packages/System.Management.Automation/6.0.4
So I guess in 6.1.3 a targeting bug was fixed.

Perhaps @adityapatwardhan could add more information.

System.Management.Automation 6.0.4

PowerShell runtime for hosting PowerShell Core

[bergmeister]

I see that the team has a separate csproj for publishing to NuGet, which kind of makes sense because the actual SMA project targets .Net Core but for consumers of the NuGet package, it is only acting as a reference package (a bit like a C++ header) and therefore consumers do not need to target that same runtime (in fact the PS team has recommended for a long time to use .Net Standard, therefore this is a surprise to me that such a bug seems to have slipped in without anyone noticing). Because the file got moved, tracking it's history gets a bit complicated.
https://github.com/PowerShell/PowerShell/blob/master/tools/packaging/projects/reference/System.Management.Automation/System.Management.Automation.csproj
I am wondering if the bug is somehow caused by using a newer object type (e.g. Span?) being present in the references that is not part of .Net Standard?
Even if so, I'd expect the team to offer a NuGet package with multiple targets (which NuGet supports), so that the user has more or less PS APIs available depending on the user's target. Being able to target .Net Standard 2.0 (and in the future 2.1) is still quite important and useful, since .Net 5 (where everything should get united), is still a long time away.

[iSazonov]

It was added by @daxian-dbw in https://github.com/PowerShell/PowerShell/commit/1264a00a760fff885e2ed588387cfb8e634b2311

In any case @adityapatwardhan and @daxian-dbw could clarify.

[daxian-dbw]

I think changing the target framework of the packaging .csproj from netstandard2.0 to netcoreappxxx was fixing a bug because PowerShell Core NuGet packages never really target netstandard2.0 -- it won't work if the application that references the PowerShell Core NuGet packages targets other .NET runtimes (.NET desktop, Xamarin and etc.).

The actual SMA project targets .Net Core but for consumers of the NuGet package, it is only acting as a reference package (a bit like a C++ header) and therefore consumers do not need to target that same runtime

This is not exactly true. Whenever a project is run targeting a specific framework that is not netcoreapp, it's possible that the PowerShell Core NuGet packages won't work.
If the user truly uses the NuGet packages only as a reference package, then the PowerShellStandard.Library should be used instead.

[bergmeister]

If the user truly uses the NuGet packages only as a reference package, then the PowerShellStandard.Library should be used instead.

That is not always possible, PSScriptAnalyzer for example cannot even use PowerShell Standard only for the binary compiled for PowerShell Core because it misses types such as e.g. SementicVersion. The use case of PowerShell Standard is a completely different and much more restrictive one.
Even if there are APIs in SMA that are only available in netcoreapp2.1 (or 3.0), then I would expect that the SMA NuGet package does not contain them when targeting netstandard2.0 (but still offers them when targeting netcoreapp). NuGet has features to allow users of packages to have such a user experience, hence why I expect this behaviour from the SMA package, it might be that you need to include different DLLs in SMA's NuGet package for different targets but this is an implementation detail that an end user usually does not see. Whilst I understand that this might require quite a bit of work from the team, I'd think this is still a common and valueable use case for the SMA package to work when targeting netstandard2.0 or netstandard2.1. Because the 6.1.0 package works fine at the moment, I think most people have not spotted this problem yet. In theory one could tell people to keep referencing that package (although 6.1 generally goes out of support in about a month) but it doesn't sound right.

[daxian-dbw]

then I would expect that the SMA NuGet package does not contain them when targeting netstandard2.0

SMA depends on System.Reflection.Emits for PowerShell classes, which is not in netstandard2.0 as far as I know. It may also have other dependencies that are not included in netstandard2.0.

Because the 6.1.0 package works fine at the moment, I think most people have not spotted this problem yet.

It's probably because it hasn't been used for applications that target other dotnet runtimes. It's just a matter of time for people to find it's broken if we continue to use netstandard2.0 when it's actually not targeting netstandard.

PSScriptAnalyzer for example cannot even use PowerShell Standard only for the binary compiled for PowerShell Core because it misses types such as e.g. SementicVersion. The use case of PowerShell Standard is a completely different and much more restrictive one.

Maybe the right move is to have new version of reference-assembly-only PowerShellStandard.Library that exposes the new APIs available in PowerShell Core.

[bergmeister]

Maybe the right move is to have new version of reference-assembly-only PowerShellStandard.Library that exposes the new APIs available in PowerShell Core.

Yes, something like a PowerShellStandard.Library or version 6.2 containing the union of APIs of PS 6.2.x and 7.0.x would be a good solution.

[vexx32]

I think I and others have brought this up to @SteveL-MSFT on Twitter a couple months ago, that we need newer reference libs.

[SteveL-MSFT]

@vexx32 ref assemblies for PSCore M.n is different than PowerShellStandard.Library M.n as they are intended to solve different things. We should have both, but it's a matter of prioritizing time needed to get them out (unless someone else submits a PR!). We should have version specific ref assemblies for developers who are trying to target specific versions of PowerShell. We should also start thinking of a PowerShellStandard.Library 6 to have more APIs available (@bergmeister, please open an issue in the PowerShellStandard repo if one isn't there already!).

[iSazonov]

For reference https://github.com/PowerShell/PowerShellStandard/issues/61

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.