Tag Archives: Microsoft

Major update to the PowerShell Extension for Visual Studio Code

This post was originally published on this site

An updated version of our PowerShell extension is now available on the Visual Studio Code marketplace.

This update represents a complete overhaul of the core PowerShell engine of PowerShell Editor Services, intending to create a more reliable and stable user experience. This release represents nearly two years’ work, tracked in PSES #1295 and implemented in PSES #1459. It is our response to many issues opened by users over the last several years.

Thank you to all of the community members who opened issues which helped motivate this major update.

These major updates have also been tested over the last 6 months, in 13 releases of our PowerShell Preview extension for Visual Studio Code. A huge thank you to all of the community members who have tested these changes to the extension and have worked with us to polish the extension before releasing it through our stable channel.

For information on getting started with the PowerShell extension for Visual Studio Code refer to our documentation.

Highlights of the release

  • Rewrite of PowerShell pipeline execution with cancellable and ordered tasks
  • Loads of debugger reliability improvements
  • ReadKey fix (including better pasting on macOS and Linux, and a whole bunch of other bugs!)
  • Revamped PSHost implementation that reuses PowerShell’s built-in functionality wherever possible
  • Improved testing (in VS Code repo and PSES repo)
  • Improved completion logic (and more icons!)
  • Modernized built-in snippets
  • Improved user interface with built-in Codicons
  • Improved settings editor experience
  • Support debugging without a workspace
  • Support to debug other PowerShell processes and runspaces
  • DictionaryEntry displayed as key/value pairs in debugger
  • Removed PackageManagement module update prompt
  • Enabled resolution of an alias to its function definition
  • Fix formatting handlers and PSScriptAnalyzer loading
  • Performance improvements with better cancellation logic

For a complete list of changes please refer to our changelog.

More about the update

We began our work for this update with the following goals for the release to our stable extension

  • More reliable/stable experience overall
  • All tests are enabled and improved in both client (extension) and server (PSES) repositories
  • Feature parity with previous extension experience (or intentional depreciation of features)
  • No new moderate to high impact bugs

To accomplish these goals we focused on the threading model for the extension.

Previously the Integrated Console, the shell that is provided by the PowerShell extension, was run by setting threadpool tasks on a shared main runspace, and where LSP, Language Server Protocol, servicing was done with PowerShell idle events. This lead to overhead, threading issues and a complex implementation intended to work around the asymmetry between PowerShell as a synchronous, single-threaded runtime and a language server as an asynchronous, multi-threaded service.

Now, PowerShell Editor Services maintains its own dedicated pipeline thread, which is able to service requests similar to JavaScript’s event loop, meaning we can run everything synchronously on the correct thread. This prevents an entire class of race conditions, leading to more reliable and bug-free code. We also get more efficiency because we can directly call PowerShell APIs and code written in C# from this thread, without the overhead of a PowerShell pipeline.

This change has overhauled how we service LSP requests, how the Integrated Console works, how PSReadLine is integrated, how debugging is implemented, how remoting is handled, and a long tail of other features in PowerShell Editor Services.

Also, in making it, while 6,000 lines of code were added, we removed 12,000, for a more maintainable, more efficient and easier to understand extension backend.

What’s next for the extension

Beyond this release our intention is to remain focused on incremental improvements to the stability, reliability, and consistency of the extension. These next work items are enumerated in our GitHub Projects.

In particular we plan to focus on known issues with debugging and start-up.

Feedback and Support

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 Major update to the PowerShell Extension for Visual Studio Code appeared first on PowerShell Team.

Announcing PowerShell Crescendo General Availability (GA)

This post was originally published on this site

We are pleased to announce the General Availability (GA) release of PowerShell Crescendo, a
framework to rapidly develop PowerShell cmdlets for common command line tools, regardless of
platform.

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

Making Cmdlets with PowerShell Crescendo

Crescendo is a development accelerator enabling you to rapidly build PowerShell cmdlets that
leverage existing command-line tools. Crescendo amplifies the command-line experience of the
original tool to include object output for the PowerShell pipeline, privilege elevation, and
integrated help information. A Crescendo module replaces cumbersome command-line tools with
PowerShell cmdlets that are easier to use in automation and packaged to share with team members.

The GA release includes the following features and benefits:

  • Ability to define cmdlets from simple key/value statements in a JSON file
  • Support for modular design – cmdlet definitions can be in a one or more JSON files
  • A JSON schema that helps you create your Crescendo configuration using IntelliSense and tooltips
  • Three styles of output handling code allowing you to separate your code from the cmdlet
    definitions for easier debugging and development
  • Privilege elevation mechanisms in Windows, Linux, and macOS
  • Crescendo generates a PowerShell script module ready for deployment
  • While Crescendo requires PowerShell 7 or higher for authoring configurations, the generated module
    can run on Windows PowerShell 5.1 and higher
  • Example configurations for you to copy and reuse
  • Experimental Help parsers that provide proof-of-concept examples for auto-generating cmdlet
    configurations

Installing Crescendo

Requirements:

  • Microsoft.PowerShell.Crescendo requires PowerShell 7.0 or higher

To install Microsoft.PowerShell.Crescendo:

Install-Module -Name Microsoft.PowerShell.Crescendo

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

Install-PSResource -Name Microsoft.PowerShell.Crescendo

More information

To get started using Crescendo, check out the
documentation.

Future plans

We value your ideas and feedback and hope you will 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 General Availability (GA) appeared first on PowerShell Team.

When PowerShellGet v1 fails to install the NuGet Provider

This post was originally published on this site

Recently there’s been a number of users who have encountered a particular bug with PowerShellGet 1.0.0.1 in Windows PowerShell.
This bug occurs when you try to to use a PowerShellGet cmdlet that is dependent on PackageManagement,
including cmdlets such as Find-Module, Install-Module, Save-Module, etc. Running any of these cmdlets will prompt you to install
the NuGet provider that both PowerShellGet and PackageManagement are dependent on. Even though the prompt offers two ways to
install the provider– you can run ‘Y’ to have PowerShellGet automatically install the provider, or you can run
‘Install-PackageProvider’ yourself– both of these suggestions fail.

Unable to find package provider

But, again, even when attempting to explicitly install the package provider, the process command fails.
Unable to install package provider

The earliest version of PackageManagement (version 1.0.0.1) did not ship with the NuGet provider, so any use of PowerShellGet also required that the NuGet provider be bootstrapped or explicitly installed. Understandably, it can be a source of deep frustration when the tool you use to install packages is dependent on a package that it cannot install.

The underlying issue here is that the remote endpoint used to bootstrap the provider requires TLS 1.2 and the client may not have it enabled. The two options below should help you resolve any issues encountered when attempting to install the NuGet provider and get back up and running again with PowerShellGet!

How to find the versions you’re using

You can find out what version of PowerShellGet and PackageManagement you’re using by running:

Get-Module PowerShellGet, PackageManagement -ListAvailable

The output will be order by priority, so if multiple paths are displayed, the top first path will be the one that gets referenced during an import.

If the version of PackageManagement you’re using is 1.0.0.1 then this issue will likely apply to you.

Option 1: Change your TLS version to 1.2

The easiest thing to do here is to update the TLS version on your machine. It’s highly recommended to use this option, but if necessary you can manually install PackageManagement as outlined under Option 2.

If you only want to update the current PowerShell session you can run:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

After running this command you can run

[Net.ServicePointManager]::SecurityProtocol

To validate that TLS12 is being used.
Once TLS 1.2 is enabled, you can successfully run the original command.

If you prefer to update your client so that you don’t need to run the command above in every PowerShell session, you can follow the instructions laid out here.

Option 2: Manually update PackageManagement

You can also update PackageManagement to a version that ships with the NuGet provider– that is PackageManagement 1.1.0.0 or later.

Simply go to the PackageManagement package page on the PowerShell Gallery and under “Installation Options”, click on the “Manual Download” tab and then “Download the raw nupkg file”.

Manual Download Options

You can then go to your downloads folder and unzip the .nupkg.

You can then move the folder into your modules path. To find out what this specific path is, follow the steps specified in “How to find the versions you’re using” above. Use the first path listed.

Get-Module PackageManagement

Create a folder under the PackageManagement directory listed here. This new folder should have the same name as the PackageManagement version that was downloaded. For example, in the case above, under “C:Program FilesWindowsPowerShellModulePackageManagement” you would create a directory named “1.1.0.0”. You can then place the contents of the unzipped nupkg into this newly created version directory.

After doing this, start a fresh session of PowerShell or run:

Import-Module PackageManagement -Force

You’re good to go

After completing either option 1 or 2 you should find your issue resolved. If not feel free to reach out via GitHub or Twitter.

The post When PowerShellGet v1 fails to install the NuGet Provider appeared first on PowerShell Team.

PowerShellGet 3.0 Preview 12 Release

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 more parameters, additional pipeline support, more wildcard support and a number of other features detailed below.

How to Install PowerShellGet 3.0 Preview 12

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 adds wildcard and pipeline support for some cmdlets, adds a number of parameters and parameter sets, and includes many bug fixes. Some of the key features and breaking changes are listed below, for the full list of changes please refer to the Changelog.

Features

  • Wildcard support for Find-PSResource -Name
  • Support searching for and returning packages found across multiple repositories when using wildcard with Repository parameter (i.e Find-PSResource “PackageExistingInMultipleRepos” -Repository “*” will perform an exhaustive search).
  • Parameter set for Find-PSResource -Tag
  • Parameter set for Find-PSResource -Type
  • Parameter set for Find-PSResource -CommandName
  • Parameter set for Find-PSResource -DSCResourceName
  • -DestinationPath parameter for Publish-PSResource
  • -NoClobber functionality to Install-PSResource
  • Pipeline support for Install-PSResourceUninstall-PSResourceSave-PSResourceFind-PSResourceGet-PSResourcePublish-PSResourceGet-PSResourceRepositorySet-PSResourceRepositoryRegister-PSResourceRepositoryUnregister-PSResourceRepository
  • Consistent pre-release version support for cmdlets, including Uninstall-PSResource and Get-PSResource. For example, running Get-PSResource “MyPackage” -Version “2.0.0-beta” would only return MyPackage with version “2.0.0” and prerelease “beta”, NOT MyPackage with version “2.0.0.0” (i.e a stable version).
  • -AsNupkg and -IncludeXML parameters for Save-PSResource
  • -PassThru parameter for Install-PSResourceSave-PSResource,Update-PSResource and Unregister-PSResourceRepository
  • -SkipDependencyCheck parameter for Install-PSResourceSave-PSResource and Update-PSResource cmdlets.
  • Progress Bar for Install-PSResourceUpdate-PSResource and Save-PSResource
  • -Quiet parameter for Install-PSResourceSave-PSResource and Update-PSResource (This suppresses the progress bar display when passed in)
  • -AsNupkg and -IncludeXML parameters for Save-PSResource
  • Improved error handling
  • Restore package if installation attempt fails when reinstalling a package.

Breaking Changes

This release reverts the cmdlet name from Get-InstalledPSResource to Get-PSResource.

This release also removes the DSCResource from PowerShellGet, with the intention to continue shipping the DSCResource on the PowerShell Gallery separately from the PowerShellGet module. If the DSCResource is critical for your workload we recommend staying on preview 11 until the resource is available on the Gallery. Currently the DSCResource can also be found in its own GitHub repository. If you are impacted by this change please open an issue in our GitHub repository to ensure your scenario is covered as we move towards GA for this major update.

Features to Expect in Coming Preview Releases

This module is not yet feature complete.
Below is a list of features that we are still in the process of implementing which you can expect to see in future preview releases.

  • We will introduce a New-RequiredResourceFile cmdlet which will create a template file. If the switch -AsPSD1 is used it will create a psd1 file, otherwise it will default to JSON.
  • New-ScriptFileInfo cmdlet
  • Test-ScriptFileInfo cmdlet
  • Update-ScriptFileInfo cmdlet
  • Update-ModuleManifest cmdlet
  • Dependency management. In future releases, Install-PSResource will accept a path to a psd1 or JSON file (using -RequiredResourceFile), or a hash table or JSON (using -RequiredResource) where the key is the module name and the value is either the required version specified using Nuget version range syntax or a hash table where repository is set to the URL of the repository and version contains the Nuget version range syntax.
Install-PSResource -RequiredResource @{
  Configuration = "[1.3.1,2.0]"

  Pester        = @{
    version = "[4.4.2,4.7.0]"
    repository = "https://www.powershellgallery.com"
    credential = $cred
    allowPrerelease = $true
  }
}

In this case the modules named “Configuration”, and “Pester” will be installed. The JSON format will be the same as if this hashtable is passed to ConvertTo-Json:

{
  "Configuration": "[1.3.1,2.0]",

  "Pester": {
    "version": "[4.4.2,4.7.0]",
    "credential": null,
    "repository": "https://www.powershellgallery.com",
    "allowPrerelease": true
  }
}
  • Save-PSResource -Type Library will download nupkgs that have a lib folder in order to make it easier to use arbitrary libraries with PowerShell scripts. The dependent native library in runtimes matching the current system runtime will be copied to the root of the destination specified. An -IncludeAllRuntimes can be used to explicitly retain the runtimes directory hierarchy within the nupkg to the root of the destination.
  • Native credential management/credential persistence for registered PSRepositories
  • For cmdlets with a –URL parameter, the parameter will be renamed to -Uri.

Using the CompatPowerShellGet module

CompatPowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and above) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. New PowerShell scripts that only leverage PowerShellGet v3 cmdlets do not need to use this compatibility module. For example, if a user has the CompatPowerShellGet module installed and runs the command:

Install-Module PowerShellGet -MinimumVersion 1 -MaximumVersion 2 -AllowPrerelease

the CompatPowerShellGet module will get autoloaded into the PowerShell Session and will map the command to PowerShellGet 3.0 syntax:

Install-PSResource PowerShellGet -Version "[1,2]" -Prerelease" 

The command will then be executed by the PowerShellGet 3.0 implementation. The user will also get a warning to update their script to the new cmdlet interface:

WARNING: The cmdlet 'Install-Module' is deprecated, please use 'Install-PSResource.

This module is designed so that users will not need to immediately update their scripts in order to update to the latest version of PowerShell or to begin taking advantage of the performance improvements already available in PowerShellGet 3.0. We still do recommend that authors begin making the minimal changes required to update their scripts to the new cmdlet interface.

This compatibility module is designed so that it takes precedence over legacy versions of PowerShellGet. If you have this compatibility module installed and would not like it to be used, you can remove it from the PowerShell session using the Remove-Module command.

Please note that this flow is only possible if the user has both the CompatPowerShellGet module installed and the PowerShellGet 3.0 preview module installed. Once PowerShellGet 3.0 is generally available it will be a dependency of CompatPowerShellGet.

Please also note that this compatibility module will not be called if you use fully qualified cmdlets. For example, if you use PowerShellGetInstall-Module this will call a legacy version of PowerShellGet. If this is a common scenario for you, and will be a barrier to migrating to PowerShellGet 3.0 we would appreciate that feedback in our GitHub repository.

Improvements we are Considering post-GA

One important goal of PowerShellGet 3.0 is to improve the supportability of the module. As a result, once this work is complete we will iterate more quickly, and tackle other top customer issues. This list represents issues we are considering tackling, but have not committed to yet.

To track the full list of issues we are considering we are using the vNext milestone in our GitHub Repository.

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/Roadmap

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 cannot 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, Amber Erickson, Anam Navied, Paul Higinbotham, Steven Bucher PowerShell Team

The post PowerShellGet 3.0 Preview 12 Release appeared first on PowerShell Team.

Announcing PowerShell Crescendo Release Candidate (RC)

This post was originally published on this site

Announcing Crescendo 0.9.0 Release Candidate (RC)

We are pleased to announce the Release Candidate (RC) of PowerShell Crescendo, a framework to
rapidly develop PowerShell cmdlets for native commands, regardless of platform.

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

To install Microsoft.PowerShell.Crescendo:

Install-Module Microsoft.PowerShell.Crescendo -AllowPrerelease

Crescendo Release Candidate Updates

Crescendo 0.9.0 Release Candidate adds support for a versioned schema and fixes scenarios
suggested by the community.

  • Added versioned schema to support future updates.
    Issue #112
  • Fixed quoting empty string parameter values.
    Issue #100
  • Fixed showing OriginalCommand in help example unless specified.
    Issue #57

Schema versioning

With this release of Crescendo, the JSON schema for the configuration is now versioned. While we
don’t expect there to be any changes, supporting a versioned schema makes is easier to support
changes in future releases.

The URL for the current version of the schema is: https://aka.ms/PowerShell/Crescendo/Schemas/2021-11.

Support for empty string parameter values

Crescendo now supports parameters that accept empty strings as argument values. The proxy cmdlet
created by Crescendo now recognizes an empty string provided as parameter value and ensures that the
empty string is passed as "" to the native executable.

For a more detailed example use case, see
Issue #100.

Displaying OriginalCommand in Help

The OriginalCommand property of a cmdlet definition is intended to contain the original native
command and parameters invoked by the proxy cmdlet. This information is display by Get-Help. With
this release, if the OriginalCommand property is empty, no placeholder is written to the
comment-based help when the module is exported.

More information

For more information about Microsoft.PowerShell.Crescendo, check out the previous posts on the
PowerShell Team blog.

For more information using Microsoft.PowerShell.Crescendo, check out this excellent blog series
by Sean Wheeler on the
PowerShell Community blog.

Future plans

The plans for the general availability (GA) release will be based on community feedback. Our goal is
to make it easier to convert your native commands to PowerShell cmdlets and receive the benefits
that PowerShell provides.

We value your ideas and feedback and hope you will 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 Release Candidate (RC) appeared first on PowerShell Team.

New release of PowerShell Preview for Visual Studio Code!

This post was originally published on this site

An updated version of our PowerShell Preview extension is now available on the Visual Studio Code marketplace.

This update represents a complete overhaul of the core PowerShell engine of PowerShell Editor services, with the intention of create a more reliable and stable user experience. This release represents over a year’s work, tracked in PSES #1295 and implemented in PSES #1459, and is our response to many issues opened by users over the last few years. Thank you to all of the community members who opened issues which helped motivate this major update.

For information on getting started with the PowerShell extension for Visual Studio Code refer to our documentation.

More about the update

Previously the Integrated Console, the shell that is provided by the PowerShell extension, was run by setting threadpool tasks on a shared main runspace, and where LSP, Language Server Protocol, servicing was done with PowerShell idle events. This lead to overhead, threading issues and a complex implementation intended to work around the asymmetry between PowerShell as a synchronous, single-threaded runtime and a language server as an asynchronous, multi-threaded service.

Now, PowerShell Editor Services maintains its own dedicated pipeline thread, which is able to service requests similar to JavaScript’s event loop, meaning we can run everything synchronously on the correct thread. This prevents an entire class of race conditions, leading to more reliable and bug-free code. We also get more efficiency because we can directly call PowerShell APIs and code written in C# from this thread, without the overhead of a PowerShell pipeline.

This change has overhauled how we service LSP requests, how the Integrated Console works, how PSReadLine is integrated, how debugging is implemented, how remoting is handled, and a long tail of other features in PowerShell Editor Services.

Also, in making it, while 6,000 lines of code were added, we removed 12,000, for a more maintainable, more efficient and easier to understand extension backend.

We also want to thank Patrick Meinecke for his help and knowledge as we’ve made this migration.

For an overview of the specific work items please refer to the changelog.

What’s next for the extension

With help from the community we’ve already found and fixed several bugs, and intend to move this preview to stable once we have fixed all the new bugs and covered them with regression tests. This will require a bit of work as our existing tests need to be migrated to use the new pipeline code, so please continue to run the Preview if you’re able and help us test!

Once that release is complete our intention is to remain focused on incremental improvements to the stability and reliability of the extension. These next work items are enumerated in our GitHub Projects.

In particular we plan to focus on known issues with debugging and start-up.

Feedback and Support

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.

The post New release of PowerShell Preview for Visual Studio Code! appeared first on PowerShell Team.

Announcing PowerShell Crescendo Preview.4

This post was originally published on this site

Announcing Crescendo 0.7.0-Preview.4

We are pleased to announce the fourth preview of PowerShell Crescendo, a framework to rapidly
develop PowerShell cmdlets for native commands, regardless of platform.

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

To install Microsoft.PowerShell.Crescendo:

Install-Module Microsoft.PowerShell.Crescendo -AllowPrerelease

Crescendo Preview 4 Updates

Crescendo 0.7.0-Preview.4 adds global schema support and experimental help parsing for modern
native commands. Read the full list of changes below:

  • Added global schema support
  • Added experimental native command help parser. Issue #99
  • New-CrescendoCommand should include an OriginalName parameter.
    Issue #82
  • Added Export-CrescendoCommand to create a configuration file.
    Issue #80
  • Added support for the ConfirmImpact CmdletBinding() argument.
  • Default parameter values are not used.
    Issue #101

Global Schema support

In preview 4, we’ve published the authoring schema for PowerShell Crescendo at a well-known URL.
This URL can be referenced instead of a local file path as in previous preview versions. 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/Crescendo/Schema.json",
   "Commands": []
}

Experimental native command Help parsers

Modern commands that produce structured help output may be parsed for parameter and argument
information to build a PowerShell Crescendo configuration file. This reduces the time to
discover and handle changes, making maintaining Crescendo modules that contain complex native
commands easier to maintain.

The Preview 4 release includes several help parsers for native commands. These parsers are
experimental and have limitations. For a full discussion about the design and limitations of help
parsers as well as how to use them, see the help parser
README
file.

The experimental help parsers can be found in the
HelpParsers
folder in the GitHub repository.

The experimental help parsers may also be found locally in the module folder <PathToModule>/Microsoft.PowerShell.Crescendo/src/experimental/HelpParsers/.

New-CrescendoCommand now includes the OriginalName parameter

The cmdlet New-CrescendoCommand includes the OriginalName parameter that specifies the name
and location of the native command to be wrapped by Crescendo.

New-CrescendoCommand -Verb Get -Noun MyFeature -OriginalName "<Path><Command>"

Creating a command configuration with Export-CrescendoCommand

PowerShell Crescendo users may choose to start a configuration file with a partially populated
template. New-CrescendoCommand can create the command object that can be converted to JSON using
the Export-CrescendoCommand cmdlet.

To create a JSON configuration file for a single command:

New-CrescendoCommand -Verb Get -Noun MyFeature -OriginalName MYCommand.exe |
    Export-CrescendoCommand -TargetDirectory C:MyConfig

For this example, Export-CrescendoCommand creates the file C:MyConfigGet-MyFeature.config.json.

Support for the ConfirmImpact argument

When you define a cmdlet that alters the system state you should include the
SupportsShouldProcess argument in the CmdletBinding() attribute for the cmdlet. The Crescendo
JSON schema includes SupportsShouldProcess. Preview 4 adds the ConfirmImpact argument.
Supported values for ConfirmImpact are: Low, Medium, or High.

Default parameter values are not used

In previous previews, specifying the default value of a parameter was not recognized and respected
in the generated Crescendo module. This resulted in a cmdlet parameter without the expected default
value. Starting in Preview 4, parameters defined with default values will now use those default
values unless overridden by the user.

{
  "ParameterSetName": ["Default"],
  "Name":"ProductName",
  "OriginalName": "-pn",
  "ParameterType": "string",
  "DefaultValue": "WinGet",
  "Description": "This switch provides product name for display"
}

In the example above, the argument default value “WinGet” will be applied to the parameter
ProductName when the user executes the cmdlet.

More information about Microsoft.PowerShell.Crescendo

For more information about Microsoft.PowerShell.Crescendo, check out these previous blog posts:

For more information using Microsoft.PowerShell.Crescendo, check out this excellent blog series
by Sean Wheeler posted to the
PowerShell Community.

Future plans

The plans for the general release will be based on community feedback and include improved tooling
and guidance for Crescendo cmdlets. Our goal is to make it easier to convert your native commands to
PowerShell cmdlets and receive the benefits that PowerShell provides.

We value your ideas and feedback and hope you will 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 Preview.4 appeared first on PowerShell Team.

Announcing PowerShell Crescendo Preview.3

This post was originally published on this site

We are pleased to announce the third preview of PowerShell Crescendo, a framework to rapidly
develop PowerShell cmdlets for native commands, regardless of platform.

Warning


Preview.3 includes a change to the schema to support
multiple command configurations. This is a breaking change from previous previews. To enjoy the new
multi-command JSON format, please upgrade to the latest preview.

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

To install Microsoft.PowerShell.Crescendo:

Install-Module Microsoft.PowerShell.Crescendo -AllowPrerelease

For more information on Microsoft.PowerShell.Crescendo, check out these previous blog posts:

Crescendo Preview 3 Updates

Crescendo 0.6.1-Preview.3 adds support to handle multiple command definitions per JSON
configuration and additional output handling options. Read the full list of changes
below:

  • Added support for multiple commands per JSON configuration.
    Issue #49
  • Added additional output handler options inline, function, and script.
    Issue #33
  • Added additional proxy generation code cleanup

Support multiple command definitions per JSON configuration

To improve the development and distribution of Crescendo wrapped commands, the schema for Crescendo
has been extended to support multiple command definitions in a single JSON file. A new keyword
Commands creates an additional tier to the hierarchy, followed by single or multiple command
definitions. This is a breaking change from previous previews.

In the example below, each command definition is located inside the Commands keyword.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Commands": [
         {
             "Verb": "New",
             "Noun": "Command1",
             "OriginalName":"<path><command>"
         },
         {
            "Verb": "New",
            "Noun": "Command2",
            "OriginalName":"<path><command>"
         },
         {
            "Verb": "New",
            "Noun": "Command3",
            "OriginalName":"<path><command>"
         }
    ]
}

Additional per command features such as parameter definitions and administrative elevation may be
added to single or multiple command definitions. Check out these blogs for more information about
parameters
and
elevation.

Support additional OutputHandlers

Output handlers take the text output (string) from a native command and convert those strings to
objects. Crafting custom output handlers is complex unless the native commands produce structured
output such as XML or JSON. To provide authors with development and deployment flexibility,
Crescendo supports three types of output handlers: inline, script, and function.

  • Inline – Authors construct the output handler code inside the cmdlet definition. When
    Crescendo generates the module, the output handler code is written directly into the proxy
    function for the new cmdlet.
  • Script – Authors may choose to develop the output handler in a separate script to isolate
    troubleshooting. The Handler keyword supports the path and script name to be included. Crescendo
    generates the module (.psm1) containing the proxy cmdlet, the manifest (.psd1), and includes the
    specified script as an additional asset.
  • Function – Authors may already have written output handlers that have been imported into
    PowerShell as functions. Crescendo adds the imported function to the generated module outside of
    the proxy cmdlet.
{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Commands": [
         {
             "Verb": "New",
             "Noun": "Command1",
             "OriginalName":"<path><command>",
             "OutputHandlers": [
                {
                  "ParameterSetName": "viaInline",
                  "HandlerType": "Inline",
                  "Handler": "$args[0] | ConvertFrom-Json"
                }
             ]
         },
         {
            "Verb": "New",
            "Noun": "Command2",
            "OriginalName":"<path><command>",
            "OutputHandlers": [
                {
                  "ParameterSetName": "viaScript",
                  "HandlerType": "Script",
                  "Handler": "Convert-GetDate.ps1"
                }
            ]
         },
         {
            "Verb": "New",
            "Noun": "Command3",
            "OriginalName":"<path><command>",
            "OutputHandlers": [
                {
                  "ParameterSetName": "viaFunction",
                  "HandlerType": "Function",
                  "Handler": "Convert-GetDate"
                }
            ]
         }
    ]
}

information


Both script and function use Get-Command
to determine the availability of the handler. Be sure that the handler may be found by Get-Command
before using Export-CrescendoModule.

For an example of working with an inline output handler, including parameters, see
Announcing PowerShell Crescendo Preview.1

Future plans

Next/Future plans for preview.4 will be based on feedback and include a few items under investigation:

  • Improved tooling for discovery of Crescendo generated modules
  • Improved cmdlet support including New-CrescendoCommand and Export-CrescendoModule

Our goal is to make it easier to convert your native commands to PowerShell cmdlets and receive the
benefits that PowerShell provides. We value your ideas and feedback and hope you will give Crescendo
a try, then stop by our GitHub repository and let us know of any issues or features you would like
added.

For more information about PowerShell Crescendo issues and features, see:
Crescendo on GitHub

The post Announcing PowerShell Crescendo Preview.3 appeared first on PowerShell Team.

Preview updating PowerShell 7.2 with Microsoft Update

This post was originally published on this site

Updating PowerShell 7 with Microsoft Update

Today, we’re happy to announce that we’re taking the first steps to making PowerShell 7 easier than ever to update on Windows 10 and Server. In the past, Windows users were notified in their console that a new version of PowerShell 7 is available, but they still had to hop over to our GitHub release page to download and install it, or rely on a separate package management tool like the Windows Package Manager, Chocolatey, or Scoop. But with Microsoft Update, you’ll get the latest PowerShell 7 updates directly in your traditional Windows Update (WU) management flow, whether that’s with Windows Update for Business, WSUS, SCCM, or the interactive WU dialog in Settings. With today’s announcement, you’ll soon be able to try this new update process for yourself
on the latest PowerShell 7.2 previews.

How updates will work

Because of the large changes and validation required to get this to work, we will publish updates only for future releases. We have already been working on a release that updates 7.2 preview 5 or newer to 7.2 preview 7. We will begin the Microsoft Update publishing process once we release an update to GitHub.

How you can opt-in and help test the upgrade

First, you’ll need to have Windows 10 RS3 (10.0.16299) or newer installed, as well as PowerShell 7.2 preview.5 or preview.6 installed. You’ll also need to ensure that your machine is set up to receive Microsoft Update updates. (On Windows 10, this is done by going to Settings -> Windows Update -> Advanced options and checking “Receive updates for other Microsoft products when you update Windows.” Next, you’ll need to make sure not to update to the latest 7.2 preview.7 or greater using the MSI. Finally, you’ll need to add a specific registry key to opt-in to Microsoft Update usage for PS7. Running the following script from an elevated PowerShell session will setup the registry for this scenario:

$pwshRegPath = "HKLM:SOFTWAREMicrosoftPowerShellCore"
if (!(Test-Path -Path $pwshRegPath)) {
    throw "PowerShell 7 is not installed"
}

Set-ItemProperty -Path $pwshRegPath -Name UseMU -Value 1 -Type DWord

About a week after PowerShell 7.2 preview.7 update is released, @PowerShell_Team will tweet that the Microsoft Update release is available. At this point, you should be prompted to update PowerShell 7.2-preview in your standard Windows Update workflow.

Test new installs of PowerShell 7.2 preview

If you don’t already have PowerShell 7.2 preview installed, you can still help us try out a new install method! Again, you’ll need to have Windows 10 RS3 (10.0.16299) or newer installed and Microsoft Update enabled. Then, run the following script from an elevated PowerShell session to setup the registry in such a way that Microsoft Update will install and update the latest version of PowerShell 7 preview. Running the following script from an elevated PowerShell session, will setup the registry for this scenario:

$pwshRegPath = "HKLM:SOFTWAREMicrosoftPowerShellCore"
$previewPath = Join-Path -Path $pwshRegPath -ChildPath "InstalledVersions39243d76-adaf-42b1-94fb-16ecf83237c8"
if (!(Test-Path -Path $previewPath)) {
    $null = New-Item -Path $previewPath -ItemType Directory -Force
}

Set-ItemProperty -Path $pwshRegPath -Name UseMU -Value 1 -Type DWord
Set-ItemProperty -Path $previewPath -Name Install -Value 1 -Type DWord

Note: due to an issue with the installer, make sure to uninstall any previously installed version of the PowerShell Preview MSI.

Also, as noted in the previous section, this will not work until @PowerShell_Team tweets that the 7.2 preview.7 MU release is live.

If you want to disable either scenario

If you hit an issue that is bad enough you want to disable MU-based install or updates, run the following script from an elevated PowerShell session:

$pwshRegPath = "HKLM:SOFTWAREMicrosoftPowerShellCore"
$previewPath = Join-Path -Path $pwshRegPath -ChildPath "InstalledVersions39243d76-adaf-42b1-94fb-16ecf83237c8"
if (!(Test-Path -Path $previewPath)) {
    throw "PowerShell 7 Preview is not installed"
}

Set-ItemProperty -Path $pwshRegPath -Name UseMU -Value 0 -Type DWord
Set-ItemProperty -Path $previewPath -Name Install -Value 0 -Type DWord

Final words

Going forward we are working to remove the need to manually add the UseMU registry value.

If you try either scenario and it works, please upvote the Microsoft Update discussion. If you have any issue, please file an issue and link it in the discussion above.

Thanks for all your help,

Travis Plunk

The post Preview updating PowerShell 7.2 with Microsoft Update appeared first on PowerShell Team.

PowerShell for Visual Studio Code May 2021 Update

This post was originally published on this site

We are excited to announce that an update to our PowerShell extension is now available on the Visual Studio Code Marketplace. This blog will explain what is new in this release as well as what you can expect from the extension in the coming months.

What’s new in the PowerShell Extension release

This incremental release incorporates a major update to OmniSharp, the Language Server Protocol library we use (like many other VSCode extensions). Behind the scenes there has also been a concerted effort to improve our build and release processes, with the intention of accelerating our release cadence.

Some highlights of the release include:

Since we have disabled semantic highlighting by default now, if you wish to re-enable it, use:

"[powershell]": {
    "editor.semanticHighlighting.enabled": true
}

The intention of this change is to reduce issues while the semantic highlighting backend is improved.

We now also remove - and $ from the word separators by default for PowerShell files. To add them back, use:

"[powershell]": {
    "editor.wordSeparators": "`~!@#$%^&*()-=+[{]}|;:'",.<>/?"
}

The intenion of this change is to increase predictability, as double-clicking PowerShell variables now selects the same portion that the extension highlights (with the exception of scoped variables due to the continued inclusion of : as a word separator).

For the full list of updates please refer to the changelog.

More about the OmniSharp update

The most significant change is the update to OmniSharp v0.19.2, from the previous version v0.18.3, released in November 2020. OmniSharp is the underlying Language Server Protocol (LSP) and Debug Adapter Protocol (DAP) server library, and as such is our biggest dependency. This update brings us to the LSP 3.16 and DAP 1.48.x specifications, enabling us to start incorporating all the latest LSP changes, and it includes numerous bug fixes and enhancements resulting in a faster and more stable server and extension experience.

After our initial upgrade to OmniSharp v0.19.0, as early adopters we encountered two major bugs in the library. Rob and Andy spent a month identifying and solving a serialization bug in the Debug Adapter Protocol which would have broken the extension’s debugger, and a race condition which temporarily impacted startup reliability in the preview extension. As our fixes went upstream, we improved the OmniSharp library not only for the PowerShell extension, but also for several other Visual Studio Code extensions similarily relying on OmniSharp.

What’s next for the extensions

Over the coming months we plan to continue work on the Editor Services pipeline stability (intellisense, formatting, etc.), work to maintain compatibility with changes to Visual Studio Code, and improve testing infrastructure (to allow for more community contribution and more predictability with preview releases). You can track the progress on all of these projects, and others on our roadmap, in our GitHub repository.

Getting support and giving feedback

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, Andy Schwartzmeyer, Rob Holt

PowerShell Team

The post PowerShell for Visual Studio Code May 2021 Update appeared first on PowerShell Team.