Repository navigation
Groundwork for PowerShell Standard - #3095
Jason Shirk (lzybkr) wants to merge 4 commits into
Conversation
|
I think you should include some kind of deprecation mark in https://github.com/PowerShell/PowerShell/tree/master/docs/cmdlet-example#building-a-c-cmdlet Question: when you target netstandard1.3 (or 1.6) dotnet will make sure that all APIs you are using exists in both 4.5.1 and dotnet core 1.3, correct? Does it controvert with the passage about frontend assemblies that are not shipped in windows? |
|
You can see the The basic idea is to target the lowest version of |
There was a problem hiding this comment.
I think you should change this to:
Recommendation is to build modules that targets both Windows PowerShell and PoweShell Core.
There was a problem hiding this comment.
I can't recommend it yet - at least not until there is a good solution around facade assemblies.
There was a problem hiding this comment.
Maybe have a small blurb:
.Net Standard is a formal specification of .Net APIs available across all conforming .Net runtimes.
There was a problem hiding this comment.
What about downlevel?
There was a problem hiding this comment.
I don't know and don't have clean VMs handy that I can check.
It's relatively straight forward to enumerate assemblies in the GAC to see which are facade assemblies - I'd do that on a clean VM for each OS of interest - just make sure Visual Studio hasn't been installed - it might install some of these facade assemblies.
There was a problem hiding this comment.
Perhaps it makes sense to include a list of Open Issues which includes downlevel and facade assemblies which we can research later rather than block this PR
There was a problem hiding this comment.
This is a general problem for anyone developing against .Net Standard using CoreClr and wanting to deploy onto FullClr. Is there any guidance from dotnet?
There was a problem hiding this comment.
This is not a general problem for folks building libraries or most applications - it's really only a problem for folks building extensions to applications.
Libraries should target netstandard - then the library works on most runtimes.
Applications (.exe) deploy the facade assemblies they know they need - the build system actually copies the facade assemblies along side the application binaries.
The problem only exists for extensible applications. The extensions can depend on assemblies that didn't exist when the application was built - but it's more or less expected that the application has those assemblies (for sharing purposes).
This is why msbuild is including some common facade assemblies so task dlls just work.
|
Jason Shirk (@lzybkr) Is there an indicative timeline for when the netstandard version of System.Management.Automation will be made available? It doesn't appear to be on nuget.org, listed or otherwise. |
|
If it helps at all, I've found that it can be installed from |
|
Oops! Fat fingers :-/ <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<!-- .NET Core nightlies (required by Powershell Core) -->
<add key="netcore-nightlies" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
<!-- Powershell Core -->
<add key="powershell-core" value="https://powershell.myget.org/F/powershell-core/api/v3/index.json" />
</packageSources>
</configuration> |
|
Adam Friedman (@tintoy) Thanks! I think I'll wait for a release I can publish to the gallery with, though. |
Added a document describing the issues with portable modules and the need for facade assemblies. Also added the basis for a new reference assembly that can support cross platform modules that target V3 and up.
There was a problem hiding this comment.
Perhaps it makes sense to include a list of Open Issues which includes downlevel and facade assemblies which we can research later rather than block this PR
Steve Lee (SteveL-MSFT)
added
the
Review - Committee
|
@PowerShell/powershell-committee needs to review this to see what we would have in the reference assembly |
| // Methods | ||
| protected internal override bool ShouldRun(System.Management.Automation.CommandInfo commandInfo, System.Management.Automation.CommandOrigin origin, System.Management.Automation.Host.PSHost host, out System.Exception reason) { reason = default(System.Exception); return default(bool); } | ||
| } | ||
| #if SNAPINS |
There was a problem hiding this comment.
We should remove the SnapIn APIs as it's not forward compatible
| public static string XmlNodeList(System.Management.Automation.PSObject instance) { return default(string); } | ||
| } | ||
| } | ||
| namespace Microsoft.PowerShell.Cim { |
There was a problem hiding this comment.
CIM is primarily used by WMI and doesn't have much usage on Linux/Mac via OMI. I recommend we remove this to align with future direction of being CIM-less.
There was a problem hiding this comment.
Caveat: we want the first iteration of this to be the most minimal surface area. At a point in the future, if we were to add CIM support, we could re-add this to a later version of this API.
| // Methods | ||
| protected override void ProcessRecord() { } | ||
| } | ||
| [System.Management.Automa |
There was a problem hiding this comment.
Don't need MMI if we don't need CIM
|
Jason Shirk (@lzybkr) I know we're not finished here, but would you mind pushing what you've got so far to this branch? I'd like to pull it up during my presentation in a couple days. Thanks! |
Joey Aiello (joeyaiello)
changed the title
|
This doesn't need to be merged. Someone on the team will pick up the remaining work of creating the PowerShell Standard reference assemblies based on this work. |
Steve Lee (SteveL-MSFT)
removed
Review - Committee
9 participants
Added a document describing the issues with portable modules and the
need for facade assemblies.
Also added the basis for a new reference assembly that can support cross
platform modules that target V3 and up.