This post was originally published on this site

We’re pleased to announce the release of PowerShell Crescendo 1.1.0-RC1. Crescendo is a
framework to rapidly develop PowerShell cmdlets for common command line tools, regardless of
platform. This release includes improved support for PSScriptAnalyzer, improvements to error
handling, and the addition of ExcludeAsArgument parameter property.

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 Release Candidate is now available for download on the PowerShell Gallery.

Installing Crescendo

Requirements:

• Microsoft.PowerShell.Crescendo requires PowerShell 7.2 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 -PreRelease

Highlighted features

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

• Using ScriptAnalyzer with exported module generates a ton of output (Thanks @DennisL68)
• Increase UX of Crescendo-generated cmdlets (Thanks @steviecoaster)
• CrescendoNativeErrorQueue and -ErrorAction Stop (Thanks @MTI-gh)
• Crescendo should probably set $PSNativeCommandUseErrorActionPreference = $false (Thanks
  JamesWTruher)
• Add the current version of the Crescendo module (Thanks @LaurentDardenne)

Using ScriptAnalyzer with exported module generates a ton of output

Using PSScriptAnalyzer on a Crescendo generated module could result in several violations of the
PSAvoidTrailingWhiteSpace rule. This was due to an additional trailing space after generated
commands. The code generator for Crescendo has been updated to remove the trailing whitespace.

Increase UX of Crescendo-generated cmdlets

Crescendo is designed to pass parameters defined in the configuration as arguments to the native
application. There are times when you may wish to pass a parameter to the output handler but not the
native application. To enable this, a new boolean parameter property ExcludeAsArgument set to
true prevents the argument from being sent to the native application. The default is false.

"Parameters": [
        {
            "Name": "P1",
            "ParameterType": "string",
            "ExcludeAsArgument": true,
            "Mandatory": false,
            "Description": "Variable not sent to native app"
        }
    ],

CrescendoNativeErrorQueue and -ErrorAction Stop

Handling errors using Pop-CrescendoNativeError may include multiple errors from the same
execution. This can happen when the cmdlet and the native command both emit an error that gets
enqueued by Crescendo. The architecture is modified so that the error queue is now local to the
cmdlet.

Crescendo should probably set $PSNativeCommandUseErrorActionPreference = $false

By default, $PSNativeCommandUseErrorActionPreference is set to true. This causes Crescendo to
produce an additional error record for every error. To prevent this, Crescendo changes the value to
false for each generated cmdlet.

Add the current version of the Crescendo module

Crescendo modules now include version and schema metadata at the top of the module.

# Module created by Microsoft.PowerShell.Crescendo
# Version: 1.1.0
# Schema: https://aka.ms/PowerShell/Crescendo/Schemas/2022-06
# Generated at: 07/13/2023 12:48:59

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-RC1 appeared first on PowerShell Team.

This post was originally published on this site

Desired State Configuration (DSC) Planning Update – August 2023

Hey DSC enthusiasts! We’re bursting with excitement to share new information about the plans for Desired State Configuration (DSC). First off, we’d like to extend a massive thank you to our amazing community for your feedback. Your input helps shape the future of DSC, and we’re grateful for your continued support.

A big shout-out to the Dev Home and WinGet teams for announcing new features at the recent Build conference. These new features, documented here, are the first solutions to leverage capabilities of the new DSC platform, and we plan for them to be the first of many.

We want to give you a sneak peek at the foundational tenets planned for the new DSC vision, and we’re looking forward to refining them with your help.

What’s in the Pipeline?

As we move forward, we want to focus on the following tenets as the foundation of our new DSC vision:

• Compatibility: We plan to ensure that existing community resources work without changes, including those written as PowerShell script and classes. Class-based resources are recommended but not required.
• Transparency: Our new project repo is now public on GitHub, allowing the community to view and submit issues. We are intentionally making the project open from an early stage of development so the community has opportunity to give early feedback.
• Cross-platform Support: In the open-source project, we plan to compile builds that work on Windows, Linux, and macOS.
• Language Flexibility: Resource authors can write DSC resources in any interpreted or compiled languages accessible by the command line, including PowerShell. MOF as a format for configurations is no longer supported and is being replaced with the industry accepted JSON and/or YAML. JSON schema replaces MOF schema for resources while existing PowerShell script based resources that have MOF schema will be supported as-is.
• Common Concepts: We aim to support or provide extensibility for concepts like composability, re-use, reboots, secrets, dependencies, and runas.
• Low Barrier To Entry: We plan to carry forward the concept of simple “one-liner” authoring previously used by Script/nxScript, while making it easier for newcomers to adopt best practices like test automation.
• Isolated Network Usability: We intend to make the command-driven platform usable in isolated networks. While we do not currently plan to reintroduce LCM, we will continue as an extensible platform that any configuration solution can leverage.
• Environmental Dependencies: Our plans include allowing users to express environmental dependencies as assertions when authoring configurations. Examples of assertions could be scenarios like detecting when a machine needs to be rebooted before taking action.
• Resource Input/Output: We’re working towards enabling users to pass output from one resource as input to another when authoring configurations.

It is important to note that this is an early preview of the next generation DSC, so we expect breaking changes to occur based on feedback during development.

Next Steps

We know this blog post raises many questions, and we’re eager to address them! We have requested an agenda item during the next DSC community call on August 9th, 2023, to discuss the vision and answer questions. Details about DSC community calls are published on the DSC community website.

For detailed how-to information, visit our GitHub repository. The project repository is where we plan to publish builds for testing as releases. Keep in mind that this is an ‘alpha’, akin to a ‘developer preview’ and not ready for production.

Please submit issues in GitHub to send feedback, even if it’s a request or idea. To get started, we would love to hear your requirements around:

• Resource authoring experiences and tools
• Ease of integration with your favorite configuration management solution
• The new configuration syntax

Together, we’ll shape the future of Desired State Configuration.

Make it so!

The post Desired State Configuration (DSC) Planning Update appeared first on PowerShell Team.

This post was originally published on this site

TextUtility module gets new functionality

We have recently released another preview of the TextUtility module. This module is a collection of tools that
are meant to help with working with text content.

Installing the module

You can install this module from the PowerShellGallery with PowerShellGet via:

Install-Module -Name Microsoft.PowerShell.TextUtility -AllowPrerelease

Or you can install it with PSResourceGet via:

Install-PSResource -Name Microsoft.PowerShell.TextUtility -Prerelease

ConvertFrom-TextTable

The most recent pre-release of Microsoft.PowerShell.TextUtility
has some new exciting functionality.
The new ConvertFrom-TextTable cmdlet allows you to take tabular text
and convert it into objects.
Also, there is a way to convert some of types of those objects into something other than a string.
Using the -ConvertPropertyValue parameter will change the value of the property to a strongly typed value.
This means you can do the following:

PS> df | select -first 6 | convertfrom-texttable -ConvertPropertyValue |Ft                       

Filesystem     512-blocks     Used  Available Capacity  iused      ifree %iused Mounted_on
----------     ----------     ----  --------- --------  -----      ----- ------ ----------
/dev/disk4s1s1 3907805752 17699080 1242895000 2%       355382 4291123926 0%     /
devfs                 462      462          0 100%        800          0 100%   /dev
/dev/disk4s3   3907805752  3676600 1242895000 1%         3745 6214475000 0%     /System/Volumes/Preboot
/dev/disk4s5   3907805752  4194376 1242895000 1%            2 6214475000 0%     /System/Volumes/VM
/dev/disk4s6   3907805752    19992 1242895000 1%           19 6214475000 0%     /System/Volumes/Update

PS> df | select -first 6 | convertfrom-texttable -ConvertPropertyValue |?{$_.available -lt 10}|Ft

Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted_on
---------- ---------- ---- --------- -------- ----- ----- ------ ----------
devfs             462  462         0 100%       800     0 100%   /dev

ConvertFrom-TextTable also allows you to specify where the header line is defined, or skip lines until you get to where the data starts.
Additionally, it is possible to take the text output and explicitly create properties by defining where a column starts.

PS> $string = $("a".."z";"A".."Z";0..9) -join ""                                                      
PS> 1..10 | %{$string}|convertfrom-texttable -noheader -columnoffset 0,15,23,40,55 | ft

Property_01     Property_02 Property_03       Property_04     Property_05
-----------     ----------- -----------       -----------     -----------
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789

Finally, you can also emit the data as JSON with the -AsJson parameter:

PS> who -p | %{$_.trim()} | convertfrom-texttable -noheader -AsJson  
{ "Property_01": "james", "Property_02": "console", "Property_03": "Jun", "Property_04": "22", "Property_05": "08:34" }
{ "Property_01": "james", "Property_02": "ttys016", "Property_03": "Jun", "Property_04": "22", "Property_05": "10:00" }
{ "Property_01": "james", "Property_02": "ttys017", "Property_03": "Jun", "Property_04": "22", "Property_05": "14:42" }
{ "Property_01": "james", "Property_02": "ttys004", "Property_03": "Jun", "Property_04": "22", "Property_05": "22:08" }
{ "Property_01": "james", "Property_02": "ttys025", "Property_03": "Jun", "Property_04": "23", "Property_05": "00:38" }

Next Steps

This is still in pre-release and we know that there is still work to be done.
For example, the parser will create an object out of the header/data separator.
This is a little trickier than at first it would seem.
The text is inspected and columns width is decided based on the inspected text.
These header/data separator lines help the parser understand where the columns are separated.
This means we can’t just toss them out as the text is being read.
I’m sure you’ll find more things that we can do,
and we would love to get your feedback on this new cmdlet so please give this module a try.
Please submit your feedback to the repo directly via the issues tab, here.

Thanks so much!

Jim Truher

PowerShell Team

The post Microsoft.PowerShell.TextUtility module updates appeared first on PowerShell Team.

This post was originally published on this site

JSON Adapter Feedback Provider Release

We are excited to announce the first release of our JSON Adapter Feedback Provider! If you are
unfamiliar with what feedback providers are, check out this blog describing them, here.

Installing JSON Adapter Feedback Provider

The release is available from the PowerShell Gallery.

Use the following command to install JsonAdapter using PowerShellGet v2.x:

Install-Module -Name Microsoft.PowerShell.JsonAdapter -AllowPrerelease 

If you are using PSResourceGet, you can use the following command:

Install-PSResource -Name Microsoft.PowerShell.JsonAdapter -AllowPrerelease

To use it you will need to import the module into your session via:

Import-Module Microsoft.PowerShell.JsonAdapter

We encourage you to include the import message in your $PROFILE so it can persistently be loaded
in every PowerShell session you start. If you have Visual Studio Code installed, type
code $PROFILE to edit your profile or use your choice of editor.

What are JSON Adapters?

A JSON adapter is a script that can parse the text output of a native executable and convert it to
JSON. Once the output is in a machine readable format like JSON, you can use ConvertFrom-JSON
cmdlet to make any native executable behave like a PowerShell object. JSON adapters can be made for
any command, it is just required to use the exact name of the command as the prefix to the script.
The script will have to be named like so <name of command>-json.ps1 to be identified by the JSON
adapter utility. This script’s file location must also be added to your $env:PATH variable to be
found.

Creating a JSON Adapter

For example, say you are on a Mac and want to use the command vm_stat like a PowerShell object. If
you add the following to a file called vm_stat-json.ps1 and add the location of this file to your
$env:PATH variable, the JSON Adapter feedback provider will identify it as a possible suggestion
for vm_stat.

[CmdletBinding()]
param ( [Parameter(ValueFromPipeline=$true)][string]$inputObject )
BEGIN {
    $h = @{}
}

PROCESS {
    if ( $inputObject -match "^Mach Virtual") {
        if ($inputObject -match "page size of (d+) ") {
            $h['PageSize'] = [int]$matches[1]
        }
    }
    else {
        $k,$v = $inputObject -split ":"
        $AdjustedK = ($k -replace "[ -]","_").trim() -replace '"'
        $AdjustedV = "$v".Trim() -replace ".$"
        $h[$AdjustedK] = [int64]$AdjustedV
    }
}

END {
    [pscustomobject]$h
}

 

This is what the experience looks like in the shell.

JC

JC or JSON Converter, is a command line utility that can convert text to JSON for variety of command
line tools. You can find instructions on how to install jc and a full list of supported commands
on the repo of jc. It can be a great tool to use to convert the outputs without writing a JSON
Adapter yourself. The JSON Adapter module supports using jc as a JSON Adapter if the user has it
installed. This means if you have the jc utility installed and use a command that is supported by JC, the JSON
Adapter feedback provider will suggest using JC piped to ConvertFrom-JSON.

It is important to note that not all jc supported utilities are supported. The list of supported commands is:

"arp", "cksum", "crontab", "date", "df", "dig", "dir", "du", "file", "finger",
"free", "hash", "id", "ifconfig", "iostat", "jobs", "lsof", "mount", "mpstat",
"netstat", "route", "stat", "sysctl", "traceroute", "uname", "uptime", "w", "wc",
"who", "zipinfo"

Additionally, you will need to use the appropriate parameters that jc requires to work properly. For
example, if you want to use jc with uname, you will need to use uname -a as that is what jc
requires to properly convert the output to JSON.

Predictive IntelliSense Support

We have also added predictive IntelliSense support for the JSON Adapter feedback provider. This
means after a JSON Adapter feedback provider is triggered, as you type the command name again,
Predictive Intellisense will suggest the feedback command to you. This is a great way to easily try
the suggestion after a JSON Adapter feedback provider is triggered.

Feedback

As this is our very first release, we know there may be issues that arise. We definitely look
forward to your feedback and suggestions! You can provide feedback on the repo for this project
here.

Jim Truher and Steven Bucher

PowerShell Team

The post JSON Adapter Feedback Provider appeared first on PowerShell Team.

This post was originally published on this site

We introduced a new experimental feature back in PowerShell v7.4.0-preview.2+ called
PSFeedbackProvider. This blog outlines what this experimental feature is, how to use it and
describes different feedback providers we have already created.

Installing the PowerShell Preview and enabling Feedback Providers

You can install the latest 7.4 preview via our GitHub page here. If you are on Windows you can
download via the Microsoft store here.

Unless configured differently, the previews should have all experimental features enabled by deafult
but in case they are not enabled you can check and enable them by using the following commands:

Checking experimental features enabled:

Get-ExperimentalFeature

Enabling experimental feature:

Enable-ExperimentalFeature -Name PSFeedbackProvider

You will also have to enable the experimental feature PSCommandNotFoundSuggestion to get enable
the built in feedback provider.

Enable-ExperimentalFeature -Name PSCommandNotFoundSuggestion

Why have we created Feedback Providers

After we created PowerShell Predictive IntelliSense, we realized that no matter how hard we can try
to be “preventative” of errors, they will still occur. This made us think there was a better way to
give the users more feedback to their errors so they could recover quicker from them.

After prototyping and seeing how great it could work for errors, we got thinking that maybe we can
help inform and teach users better practices to the shell and thus we expanded feedback providers to
successful executions and comments.

What are Feedback Providers?

Feedback Providers are PowerShell modules that utilize the IFeedbackProvider interface to give
feedback and suggestions after the shell users have attempted to execute something. Feedback
providers can trigger upon three different interactive scenarios:

• Errors
• Success
• Comments

This means after the user has hit enter, Feedback Providers can trigger and know what scenario the
user has faced.

Built in Feedback Provider

We have created a built in feedback provider named General. This triggers on the CommandNotFound
exception error and gives the user suggestions on what command they may have meant to type from list
of commands already installed in the users $env:PATH. Both native commands and PowerShell cmdlets
will be suggested if they are installed.

You have may seen something similar to this before in previous versions of the
PSCommandNotFoundSuggestion experimental feature. We have given the UX an upgraded and turned this
into a feedback provider!

This is the old PSCommandNotFoundSuggestion experience:

This is the same feature but with the new feedback provider model:

Command-Not-Found Feedback Provider

We have created an additional feedback provider that we call the command-not-found feedback
provider. This utilizes the command-not-found utility tool that is defaulted on Ubuntu systems.
This feedback provider will trigger when the user has attempted to execute a command that is not
installed on the system but will give the user suggestions on how to install the command on their
system using apt. This is only compatible with Linux systems where the command-not-found utility
tool has been installed.

 

Another thing we did with this feedback provider is that we have it subscribed to the
ICommandPredictor interface so that it can give it suggestions directly to PowerShell Predictive
IntelliSense. This way as you start typing a suggestion, you can more quickly accept the suggestion.

We have open sourced this feedback provider so you can take a look at how we have implemented it
here. You can install this feedback provider from the PowerShell Gallery via this command:

Install-Module -Name command-not-found

Or if you are using the latest version of PSResourceGet, you can use this command:

Install-PSResource -Name command-not-found

You will need to import the module to enable the feedback provider:

Import-Module -Name command-not-found

We recommend you save this in your PowerShell $PROFILE so that it is always available to you.

What’s next with Feedback Providers?

We are still under rapid development with feedback providers so there may be changes to them in the
future! Due to the changes we are doing to the feedback provider, we will be publishing
documentation on how to create your own once we have finalized some design changes for creating the
providers.

In the meantime if you have any ideas on how we can make this experience best work for your
PowerShell workflow, please let us know in the issues tab of our PowerShell repo!

We are excited to be sharing more about feedback providers in the near future.

Thanks

Steven Bucher

The post What are Feedback Providers? appeared first on PowerShell Team.

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.