Repository navigation
Regression: NuGet package System.Management.Automation stopped supporting projects that targets netstandard2.0 since 6.1.3 #10372
Description
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.2Expected 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(!)
Activity
[-]Regression: NuGet package System.Management.Automation stopped supporting projects that targets netstandard2.0[/-][+]Regression: NuGet package System.Management.Automation stopped supporting projects that targets netstandard2.0 since 6.1.3[/+]iSazonov commentedon Aug 17, 2019
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 Aditya Patwardhan (@adityapatwardhan) could add more information.
bergmeister commentedon Aug 17, 2019
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 commentedon Aug 17, 2019
It was added by Dongbo Wang (@daxian-dbw) in 1264a00
In any case Aditya Patwardhan (@adityapatwardhan) and Dongbo Wang (@daxian-dbw) could clarify.
daxian-dbw commentedon Aug 19, 2019
I think changing the target framework of the packaging
.csprojfromnetstandard2.0tonetcoreappxxxwas fixing a bug because PowerShell Core NuGet packages never really targetnetstandard2.0-- it won't work if the application that references the PowerShell Core NuGet packages targets other .NET runtimes (.NET desktop, Xamarin and etc.).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.Libraryshould be used instead.bergmeister commentedon Aug 19, 2019
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 commentedon Aug 19, 2019
SMA depends on
System.Reflection.Emitsfor PowerShell classes, which is not innetstandard2.0as far as I know. It may also have other dependencies that are not included innetstandard2.0.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.0when it's actually not targetingnetstandard.Maybe the right move is to have new version of reference-assembly-only
PowerShellStandard.Librarythat exposes the new APIs available in PowerShell Core.bergmeister commentedon Aug 19, 2019
Yes, something like a
PowerShellStandard.Libraryor version6.2containing the union of APIs of PS 6.2.x and 7.0.x would be a good solution.vexx32 commentedon Aug 19, 2019
I think I and others have brought this up to Steve Lee (@SteveL-MSFT) on Twitter a couple months ago, that we need newer reference libs.
SteveL-MSFT commentedon Aug 19, 2019
Rain Sallow (/u/ta11ow) (@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 (Christoph Bergmeister (@bergmeister), please open an issue in the PowerShellStandard repo if one isn't there already!).
iSazonov commentedon Aug 20, 2019
For reference PowerShell/PowerShellStandard#61