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.