This post was originally published on this site

Version 3 previews of PowerShellGet will begin shipping in PowerShell 7.4 previews in June (preview 5) with the following updates. These changes include important plans to address migration and compatibility, and we would like to request feedback.

• The module name “PowerShellGet” for version 3 (-PSResource cmdlets) will change to “Microsoft.PowerShell.PSResourceGet” begining with the next release (beta22).
• PowerShell v7.4 (LTS) will ship PowerShellGet v2.2.5 and PSResourceGet v3.0.x, side-by-side. This will help us get telemetry about usage of PSResourceGet. No compatibility layer will be shipped, meaning we will not wrap version 3 commandlets with version 2 names. This allows current scripts to work as-is, with or without fully qualified cmdlet names, while still allowing customers to test the new commandlets.
• Customers can use -PSResource cmdlets for perf improvements and new features. No new feature work will be done in -Modulecmdlets.
• In the first preview of PowerShell v7.5 we will include CompatPowerShellGet renamed as PowerShellGet v3.0.0, in addition to publishing the latest PSResourceGet module. In PowerShell v7.5 we will not ship PowerShellGet v2.2.5.
• In PowerShell v7.5 we plan to ship PowerShellGet v3.0.0 and the latest stable version of PSResourceGet, side-by-side.
• We will get community feedback about the compatibility layer that will help use decide on the final plans for PowerShell v7.5.
• We plan to ship PSResourceGet in addition to current PowerShellGet 1.0.0.1 in future builds of Windows so PSResourceGet can be made available by default in Windows PowerShell 5.1.
• We also plan to improve the experience of updating PowerShellGet/PSResourceGet in prior releases of Windows.
• We will update the PowerShellGet repository name on GitHub to reflect the new PSResourceGet name.

We would greatly appreciate your thoughtful feedback on these plans while there is still time to consider changes. Please comment on this github issue.

Considerations for this decision

We appreciate the feedback we have already been given by the community, at PowerShell events, by MVP’s, and by our peers. Some of the key factors that played into this decision were

• PowerShell 7.4 is an LTS release. We are merging releases later in the preview cycle than we wanted. We now need to be especially cautious about breaking changes that could impact existing scripts/automation.
• Using telemetry to track adoption of PowerShellGet v3 (now PSResourceGet) will help inform when we have an appropriate level of usage relative to feedback, to confirm public validation before release.
• In the future, we would like to be able to end new feature work for PowerShellGet v2 due to support difficulties with OneGet(PackageManagement) and focus on PSResourceGet. We recognize it will take time for mass adoption of PSResourceGet, so we will be moving cautiously.
• For a deeper look into other options we explored please refer to this github issue.

We look forward to reviewing community feedback!

Sydney PowerShell Team

The post PowerShellGet in PowerShell 7.4 Updates appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

How to Install PowerShellGet 3.0 Preview 21

Prerequisites

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

What to expect in this update

This update moves local repositories off of the NuGet APIs, this change was made to enable future improvements such as parallelization. This update also includes a number of bug fixes.

In this update we also made the decision to hold off on merging PowerShellGet previews into PowerShell 7.4 previews until June. This decision was made because we want to be really intentional about our decision making process with merging, or not merging, the compatibility module into PowerShellGet. At this point in time we are exploring a number of different options regarding module compatilibity to participate in this converation please refer to this issue.

Features of this release

New Features

• Move off of NuGet client APIs for local repositories

Bug Fixes

• Update properties on PSResourceInfo object to Remove PackageMangementProvider property and make PowerShellGetFormatVersion property private
• Rename cmdlets
  • Get-PSResource -> Get-InstalledPSResource
  • New-PSScriptFileInfob -> New-PSScriptFile
  • Test-PSScriptFileInfo -> Test-PSScriptFile
• Fix ValueFromPipelineByPropertyName on Save, Install
• add Help message for mandatory params across cmdlets
• Fix version range bug for Update-PSResource
• Fix attribute bugfixes for Find and Install params
• Correct Unexpected spelling of Unexpected
• Resolve bug with Find-PSResource -Type Module not returning module

Features to Expect in Coming Preview Releases

This module is feature complete but we are continuing to make bug fixes. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

Timeline/Road Map

Expect to see preview releases as bug fixes are made. User feedback will help us determine when we can have a Release Candidate version of the module which will be supported to be used in production. Based on user feedback, if we believe the 3.0 release is complete, then we will publish a 3.0 version of the module as Generally Available. Since these milestones are driven by quality, rather than date, we can not offer an exact timeline at this point.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 21 appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that an update to the PowerShell Extension for Visual Studio Code is now available in the extension marketplace.

In recent updates, we include a new “attach .NET debugger” debug configuration for binary PowerShell modules, better handling of start-up failures when the PowerShell version is unsupported, and have merged the PowerShell Preview extension and PowerShell “stable” extension into a single extension with a Prelease release channel.

The “PowerShell Preview” extension has now been officially deprecated, with “preview” releases now available via the “pre-release” option on the stable “PowerShell” extension in the marketplace. While you should be migrated automatically, feel free to just uninstall the preview and install the now one-and-only extension, but please keep testing our pre-releases! This change makes it much simpler to use, as you no longer have to switch between two different extensions and instead can use VS Code’s marketplace to install your choice of version!

Highlights in the March, April and May Releases

Note that these updates all shipped in our prelease channel for VS Code before shipping in our stable channel.

• vscode-powershell #4543 – Update startup logic to handle session failure reasons.
• vscode-powershell #4521 – Handle end-of-support PowerShell with error message.
• vscode-powershell #4517 – Fix attachDotnetDebugger with custom config. (Thanks @fflaten!)
•   vscode-powershell #4511 – Add additional debug configuration templates for Pester and binary modules. (Thanks @JustinGrote!)
•   vscode-powershell #4510 – Improve extension authoring experience with new Build Tasks and Launch Configs. (Thanks @JustinGrote!)
• vscode-powershell #4502 – Enable VS Code unit tests in Linux CI.
• PowerShellEditorServices #2016 – Add guide to configure Neovim. (Thanks @csc027!)
• vscode-powershell #3716 – Adopt the pre-release extension feature.
• vscode-powershell #4453 – Fix GenerateBugReport command to pre-fill template.
• vscode-powershell #3604 – Add document symbols for #region.
• vscode-powershell #3192 – Fix New-EditorFile adding content in current file. (Thanks @fflaten!)

For the full list of changes please refer to our changelog.

Getting Support and Giving Feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

If you encounter any issues with the PowerShell Extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney Smith
PowerShell Team

The post PowerShell Extension for Visual Studio Code Spring 2023 Update appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

This release includes a major refactor of the module to remove the dependency on the NuGet client APIs for remote repositories.

This version of the module, along with the PowerShellGet compatibility module, will be shipping in the next preview of PowerShell 7.4 (preview 3).

How to Install PowerShellGet 3.0 Preview 20

Prerequisites

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

What to expect in this update

This update moves off of the NuGet client APIs and uses direct REST API calls for remote repositories. It also includes the below bug fixes.

Bug Fixes

• Updates to dependency installation
• Update to retrieving all packages installed on machine
• PSResourceInfo version correctly displays 2 or 3 digit version numbers
• Using Find-PSresource with -CommandName or -DSCResourceName parameters returns an object with a properly expanded ParentResource member
• Find-PSResource no longer returns duplicate results
• Find-PSResource lists repository ‘PSGalleryScripts’ which does not exist for Get-PSResourceRepository

Features to Expect in Coming Preview Releases

This module is not yet complete. The focus for our next preview release is to move off of the NuGet APIs for local repositories. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

To track issues/features for the next release, please refer to this GitHub project.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 20 appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that the February update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.

In this update we rewrote all the symbol logic. Classes (and their properties and methods) are now proper symbols. We now have a single visitor that builds a cached dictionary of symbols for each file instead of a dozen similar-yet-different Abstract Symbol Tree (AST) PowerShell script visitors handling different parts of each symbol-related request. This was a massive simplification of the code that also leads to huge performance improvements across all the symbol related features.

Updates in the February Release

Note that these updates all shipped in our PowerShell Preview Extension for VS Code before shipping in our stable channel.

Some highlights of the February preview releases:

• Add WorkspaceFolders and use it when enumerating files vscode-powershell #2112
• Count ${Function:My-Function} as a function reference vscode-powershell #1481
• Strip scope from function references vscode-powershell #1089
• Keep only first assignment as declaration PowerShellEditorServices #1989

A number of performance improvements to the following:

• Go to Symbol in Workspace
• Go to Symbol in Editor
• Go to Definition
• Go to References / CodeLens
• Outline view

For the full list of changes please refer to our changelog.

Getting Support and Giving Feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

If you encounter any issues with the PowerShell Extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShell Extension for Visual Studio Code February 2023 Update appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that the January update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.

This first stable release for the new year includes a multitude of fixes for the debugger! Expanding variables with properties that are inaccessible no longer causes a short-circuit preventing the rest of the properties from being expanded, variable values whose expansion results in PowerShell code being executed now works as expected, and in general all the correct properties are now present. We look forward to adding the ability to view static and private fields in a future update.

Updates in the January Release

Note that these updates all shipped in our PowerShell Preview Extension for VS Code before shipping in our stable channel.

Some highlights of the January preview releases:

• vscode-powershell #4329 – Automatically find “PowerShell Daily” at its common path.
• vscode-powershell #4343 – Update VS Code shell integration script.
• vscode-powershell #4357 – Fix @vscode/vsce dependency after its rename.
• PowerShellEditorServices #1981 – Make Set-ScriptExtent faster.
• vscode-powershell #4174 – Fix several bugs in the debugger.
• #⃣ PowerShellEditorServices #1973 – Update Microsoft.PowerShell.SDK.

For the full list of changes please refer to our changelog.

Getting Support and Giving Feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

If you encounter any issues with the PowerShell Extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShell Extension for Visual Studio Code January 2023 Update appeared first on PowerShell Team.

This post was originally published on this site

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

This release includes a number of bug fixes as well as Get-PSScriptFileInfo cmdlet.

How to Install PowerShellGet 3.0 Preview 18

Prerequisites

Please note that this preview release of PowerShellGet 3.0 does not support PowerShell 7.0, 7.1 or 7.2-preview1.

This is a temporary issue due to a dependency and should be resolved in future releases. This release does support Windows PowerShell 5.1, PowerShell 7.2 and 7.3.

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

What to expect in this update

This update fixes a number of bugs and adds support for the Get-PSScriptFileInfo cmdlet.

Features of this release

• Add Get-PSScriptFileInfo cmdlet
• Allow CredentialInfo parameter to accept a hashtable

Bug Fixes

• Publish-PSResource now preserves folder and file structure
• Fix verbose message for untrusted repos gaining trust
• Fix for Update-PSResource attempting to reinstall latest preview version
• Add SupportsWildcards() attribute to parameters accepting wildcards
• Perform Repository trust check when installing a package
• Fix casing of PSResource in Install-PSResource
• Update .nuspec ‘license’ property to ‘licenseUrl’

Features to Expect in Coming Preview Releases

This module is not yet complete. The focus for our next preview release is improving the performance of find/install by refactoring these cmdlets. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

To track issues/features for the next release, please refer to this GitHub project.

Timeline/Road Map

Expect to see preview releases as new functionality is added and bug fixes are made. User feedback will help us determine when we can have a Release Candidate version of the module which will be supported to be used in production. Based on user feedback, if we believe the 3.0 release is complete, then we will publish a 3.0 version of the module as Generally Available. Since these milestones are driven by quality, rather than date, we can not offer an exact timeline at this point.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 18 appeared first on PowerShell Team.

This post was originally published on this site

We’re pleased to announce the release of PowerShell Crescendo 1.1.0-preview01. Crescendo
is a framework to rapidly develop PowerShell cmdlets for common command line tools, regardless of
platform. This preview includes a new schema, support for argument value transformation, the ability
to bypass the output handler, and improved error handling.

This is a community driven release built from the many suggestions and requests received directly or
from our Github. Thank you PowerShell Community for your adoption and suggestions!

The preview release is now available for download on the PowerShell Gallery.

Installing Crescendo

Requirements:

• Microsoft.PowerShell.Crescendo requires PowerShell 7.0 or higher

To install Microsoft.PowerShell.Crescendo:

Install-Module -Name Microsoft.PowerShell.Crescendo -AllowPreRelease

To install Microsoft.PowerShell.Crescendo using the new PowerShellGet v3:

Install-PSResource -Name Microsoft.PowerShell.Crescendo -AllowPreRelease

Highlighted features

This preview release includes many fixes and suggestions. Here are just a few of the highlights
added for this preview.

• Allow for module manifest adaptations (Thanks @tbergstedt)
• Crescendo should offer a way to bypass the output handler (Thanks @potatoqualitee)
• Generated commands cannot handle output written to the error stream (Thanks @draproctor)
• Allow for Parameter values to be translated via key/value pair (Thanks @EmeraldFlame)
• Conversion of input parameter values (Thanks @cdhunt)

New schema version

The Crescendo schema has been updated to include support for two new members to the Parameter
class, ArgumentTransform and ArgumentTransformType. The schema works with supported tools like
Visual Studio Code to provide intellisense and tooltips during the authoring experience.

URL location of the always-available Crescendo schema:

{
   "$schema": "https://aka.ms/PowerShell/Crescendo/Schemas/2022-06",
   "Commands": []
}

Prevent overwriting of the module manifest

Crescendo creates both the module .psm1 and the module manifest .psd1 when
Export-CrescendoModule is executed. This can create problems when you have customized the module
manifest beyond the scope of Crescendo. The Export-CrescendoModule cmdlet now provides a
NoClobberManifest switch parameter to prevent the manifest from being overwritten.

Export-CrescendoModule -ConfigurationFile .myconfig.json -ModuleName .Mymodule -NoClobberManifest

Bypass output handling entirely

Some native commands respond with different output depending on whether the output is sent to the
screen or the pipeline. Pastel is an example of a command that changes its output
from a graphical screen representation to a single string value when used in a pipeline. Crescendo
output handling is pipeline based and can cause these applications to return unwanted results.
Crescendo now supports the ability to bypass the output handler entirely.

To bypass all output handling by Crescendo:

"OutputHandlers": [
    {
        "ParameterSetName": "Default",
        "HandlerType": "ByPass"
    }
]

Handling error output

Previously, native command errors weren’t captured by Crescendo and allowed to stream directly to
the user. This prevented you from creating enhanced error handling. Crescendo now captures the
generated command error output (stderr) and is now available to the output handler. Error messages
are placed in a queue. You can access the queue in your output handler using a new function,
Pop-CrescendoNativeError.

If you don’t define an output handler, Crescendo uses the default handler. The default output
handler ensures that errors respect the -ErrorVariable and -ErrorAction parameters and adds
errors to $Error.

Adding an output handler that includes Pop-CrescendoNativeError allows you to inspect errors in
the output handler so you can handle them or pass them through to the caller.

"OutputHandlers": [
    {
        "ParameterSetName": "Default",
        "StreamOutput": true,
        "HandlerType": "Inline",
        "Handler": "PROCESS { $_ } END { Pop-CrescendoNativeError -EmitAsError }"
    }
]

Argument value transformation

You may find situations where the input values handed to a Crescendo wrapped command should be
translated to a different value for the underlying native command. Crescendo now supports argument
transformation to support these scenarios. We updated the schema to add two new members to the
Parameter class, ArgumentTransform and ArgumentTransformType. Use these members to transform
parameter arguments inline or invoke a script block that takes the parameter value as an argument.
The default value for ArgumentTransformType is inline.

Example: Multiplication of a value.

"Parameters": [
    {
        "Name": "mult2",
        "OriginalName": "--p3",
        "ParameterType": "int",
        "OriginalPosition": 2,
        "ArgumentTransform": "param([int]$v) $v * 2"
    }
]

Example: Accepting an ordered hashtable.

"Parameters": [
    {
        "Name": "hasht2",
        "OriginalName": "--p1ordered",
        "ParameterType": "System.Collections.Specialized.OrderedDictionary",
        "OriginalPosition": 0,
        "ArgumentTransform": "param([System.Collections.Specialized.OrderedDictionary]$v) $v.Keys.ForEach({''{0}={1}'' -f $_,$v[$_]}) -join '',''"
    }
]

Example: Argument transformation with join.

"Parameters": [
    {
        "Name": "join",
        "OriginalName": "--p2",
        "ParameterType": "string[]",
        "OriginalPosition": 1,
        "ArgumentTransform": "param([string[]]$v) $v -join '',''"
    }
]

Example: Calling a script based transformation.

"Parameters": [
    {
        "Name" : "Param1",
        "ArgumentTransform": "myfunction",
        "ArgumentTransformType" : "function"
    }
]

More information

To get started using Crescendo, check out the documentation.

Future plans

We value your ideas and feedback and hope you give Crescendo a try. Stop by our
GitHub repository and let us know of any issues you find or features you would like added.

The post Announcing PowerShell Crescendo 1.1.0-preview01 appeared first on PowerShell Team.