GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Public APIs missing in PowerShell 7.0.0-rc.2 since 6.2.3 · Issue #11619 · PowerShell/PowerShell

Public APIs missing in PowerShell 7.0.0-rc.2 since 6.2.3 #11619

New issue
Copy link
New issue
Copy link
Closed
#11836
Closed
Public APIs missing in PowerShell 7.0.0-rc.2 since 6.2.3#11619
#11836
Copy link
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-FixedThe issue is fixed.The issue is fixed.WG-DevEx-SDKhosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of moduleshosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of modules
Milestone
7.0-Consider

Description

@rjmholt
Rob Holt (rjmholt)
opened on Jan 17, 2020
Issue body actions

I've run an analysis comparing public APIs available in PowerShell 6.2.3 vs 7.0.0-rc.2 and there are some public APIs that are missing.

While this is in many cases intentional, and likely to not be an issue, some may affect programs and tools trying to link against multiple versions of PowerShell (modules and some hosts). Trying to reference such an API would cause a sudden crash in one of these tools (the hard part being that the point at which the crash occurs may be hard to control).

I'm still refining the analysis, but here is a list of classes and members that have been removed:

Types

  • System.Management.Automation.PSJobProxy [Workflow]
  • System.Management.Automation.PSChildJobProxy [Workflow]
  • System.Management.Automation.JobDataAddedEventArgs [Workflow]
  • System.Management.Automation.PowerShellStreamType (arguably workflow, but has generic name and namespace. Removed in Cleanup workflow - remove PSProxyJob #10083).
  • System.Management.Automation.WorkflowInfo [Workflow]
  • System.Management.Automation.Runspaces.PSSessionType (arguably workflow, but possibly worth restoring with single value depending on how it's used) Discussed with Dongbo Wang (@daxian-dbw) and Aditya Patwardhan (@adityapatwardhan) and decided that this is workflow-specific

Fields

  • System.Management.Automation.CommandTypes::Workflow [Workflow]
  • System.Management.Automation.PSEngineEvent::WorkflowJobStartEvent [Workflow]
  • System.Management.Automation.ModuleType::Workflow [Workflow]
  • System.Management.Automation.Internal.DebuggerUtils::SetVariableFunction [Internal]
  • System.Management.Automation.Internal.DebuggerUtils::RemoveVariableFunction [Internal]
  • System.Management.Automation.Internal.DebuggerUtils::GetPSCallStackOverrideFunction [Internal]
  • System.Management.Automation.Internal.PSMonitorRunspaceType::WorkflowInlineScript [Internal/Workflow]

Methods and constructors (captures events and properties)

  • Microsoft.PowerShell.DesiredStateConfiguration.Internal.DscClassCache::ImportClasses(System.String,System.Tuple`2[System.String,System.Version],System.Collections.ObjectModel.Collection`1[System.Exception]) [Internal]
  • Microsoft.PowerShell.DesiredStateConfiguration.Internal.DscClassCache::GetCachedClasses() [Internal]
  • Microsoft.PowerShell.Commands.NewModuleManifestCommand::get_ClrVersion() Fixed in Change name of ClrVersion parameter back #11623
  • Microsoft.PowerShell.Commands.NewModuleManifestCommand::set_ClrVersion(System.Version) Fixed in Change name of ClrVersion parameter back #11623
  • Microsoft.PowerShell.Commands.RegisterPSSessionConfigurationCommand::get_SessionType() [Workflow]
  • Microsoft.PowerShell.Commands.RegisterPSSessionConfigurationCommand::set_SessionType(System.Management.Automation.Runspaces.PSSessionType) [Workflow]
  • Microsoft.PowerShell.Commands.InternalSymbolicLinkLinkCodeMethods::GetTarget(System.Management.Automation.PSObject) (arguably internal, but not internally namespaced. Return type changed in Removing Hardlink from Mode property in default file system format #8789) Discussed with Dongbo Wang (@daxian-dbw) and Aditya Patwardhan (@adityapatwardhan) and decided that this is ok to remove
  • System.Management.Automation.Debugger::SetBreakpoints(System.Collections.Generic.IEnumerable`1[System.Management.Automation.Breakpoint]) Fixed in Restore SetBreakpoints API #11622
  • System.Management.Automation.PowerShell::AsJobProxy() [Workflow]
  • System.Management.Automation.ScriptBlock::set_IsFilter(System.Boolean) Formerly threw InvalidOperationException. Should assess whether this is considered breaking. Changed in Code Cleanup: Tidy up scriptblock.cs #9732 Discussed with Dongbo Wang (@daxian-dbw) and Aditya Patwardhan (@adityapatwardhan) and decided that this is not a real breaking change
  • System.Management.Automation.ScriptBlock::set_IsConfiguration(System.Boolean) Formerly threw InvalidOperationException. Should assess whether this is considered breaking. Changed in Code Cleanup: Tidy up scriptblock.cs #9732 Discussed with Dongbo Wang (@daxian-dbw) and Aditya Patwardhan (@adityapatwardhan) and decided that this is not a real breaking change
  • System.Management.Automation.PSModuleInfo::get_ExportedWorkflows() [Workflow]
  • System.Management.Automation.Tracing.Tracer::EndpointRegistered(System.String,System.String,System.String) Removed in Remove Workflow from PSSessionType #9618 Discussed with Dongbo Wang (@daxian-dbw), Aditya Patwardhan (@adityapatwardhan) and James Truher (@JamesWTruher) and decided that being a workflow-oriented, Windows-only API, this break is ok
  • System.Management.Automation.Internal.DebuggerUtils::GetWorkflowDebuggerFunctions() [Internal/Workflow]

I'll continue this analysis to look into custom attributes

Activity

  1. Rob Holt (rjmholt)
    added
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on Jan 17, 2020
  2. Steve Lee (SteveL-MSFT)
    added this to the 7.0-Consider milestone on Jan 17, 2020

  3. SteveL-MSFT commented on Jan 17, 2020

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Jan 17, 2020
    Member
    More actions

    The workflow and related ones are deliberate and approved by committee. Internal ones should not be considered public.

  4. Rob Holt (rjmholt)
    added
    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif
    WG-DevEx-SDKhosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of moduleshosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of modules
    and removed
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on Jan 17, 2020

  5. rjmholt commented on Jan 17, 2020

    @rjmholt
    Rob Holt (rjmholt)
    on Jan 17, 2020
    CollaboratorAuthor
    More actions

    The only missing custom attributes are of type System.Management.Automation.Tracing.EtwEvent. I assume this is by design.

  6. rjmholt commented on Jan 18, 2020

    @rjmholt
    Rob Holt (rjmholt)
    on Jan 18, 2020
    CollaboratorAuthor
    More actions

    Ilya (@iSazonov) afa76de#diff-c347101d4edffbab7f8e3874da0d0671 changes the signature of System.Management.Automation.Tracing.Tracer::EndpointRegistered(System.String,System.String,System.String. Is that workflow related? Is that an API we should restore? (Easy to add it back as an overload)

  7. iSazonov commented on Jan 18, 2020

    @iSazonov
    Ilya (iSazonov)
    on Jan 18, 2020
    Collaborator
    More actions

    Rob Holt (@rjmholt) See the comment #9618 (comment)
    It is side effect from PSTypeSession type removing.
    It is not long discussed but Paul Higinbotham (@PaulHigin) and me did not find why we should keep this.

    My current thought is the we could replace huge in our code with ILogger. The change will a big break change but it is portable, well documemnted and promisingly.

  8. rjmholt commented on Jan 18, 2020

    @rjmholt
    Rob Holt (rjmholt)
    on Jan 18, 2020
    CollaboratorAuthor
    More actions

    Ilya (@iSazonov) I’m viewing on mobile so might not be seeing it, but I can’t find a comment there about this Tracing API. It doesn’t seem to be directly related to Workflow, but I assume that it is in some way.

    However, if that API is useful without workflow in some way, I would imagine we should keep it. But I don’t know that Tracing API, how it’s used, whether it’s relevant to SDK users or whether it makes sense without Workflow.

  9. iSazonov commented on Jan 18, 2020

    @iSazonov
    Ilya (iSazonov)
    on Jan 18, 2020
    Collaborator
    More actions

    Rob Holt (@rjmholt) Thoughts were that if we remove Workflow it makes no sense to keep the parameter too because it is unlikely that anybody uses something from the tracer API - very specific and complex API. That's why I shared the idea of ​​switching to ILogger API - more simple, standard and effective API.
    I do not mind strictly reverting the change. Yes, we could add new overload and mark old as obolete.

  10. iSazonov commented on Jan 18, 2020

    @iSazonov
    Ilya (iSazonov)
    on Jan 18, 2020
    Collaborator
    More actions

    PowerShellStreamType was removed as Workflow only related and that was approved.

  11. iSazonov commented on Jan 18, 2020

    @iSazonov
    Ilya (iSazonov)
    on Jan 18, 2020
    Collaborator
    More actions

    Microsoft.PowerShell.Commands.InternalSymbolicLinkLinkCodeMethods::GetTarget - names explicitly says that it is internal.

  12. adityapatwardhan commented on Jan 23, 2020

    @adityapatwardhan
    Aditya Patwardhan (adityapatwardhan)
    on Jan 23, 2020
    Member
    More actions

    I believe that Microsoft.PowerShell.Commands.InternalSymbolicLinkLinkCodeMethods::GetTarget was available publicly as it was referenced in the types XML, when we used to have an XML.

  13. Aditya Patwardhan (adityapatwardhan)
    closed this as completedin #11836on Feb 12, 2020
  14. Ilya (iSazonov)
    added
    Resolution-FixedThe issue is fixed.The issue is fixed.
    on Feb 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-FixedThe issue is fixed.The issue is fixed.WG-DevEx-SDKhosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of moduleshosting PowerShell as a runtime, PowerShell's APIs, PowerShell Standard, or development of modules

    Type

    No type

    Projects

    No projects

      Milestone

      • 7.0-Consider

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.