The PowerShell Pro Tools extension for VS Code now provides a new tree view in the activity bar to view and update modules. It will list all the modules that are currently installed and flag any modules that are out of date. You can then upgrade the module directly from VS Code.
If you wish to hide the Module Explorer, just change the Module Explorer Visibility setting.
Improved Performance of VS Code Extension
Previously, the VS Code extension would execute all the PowerShell script necessary for its functions in the terminal window. Not only was this slow but it would pollute the history of the terminal. With the 4.4.0 release, the VS Code extension now uses a background runspace for operation. This improves performance and ensures a clean terminal history.
Improved Dependency Check Warnings
The packager requires both .NET Core and the .NET Framework Developer Pack installed to function. Previously, the warning messages were cryptic. These messages have been improved and contain links to where to download the missing dependencies.
Fixed an issue with the Form Designer Licensing
The form designer would reprompt for a license even after it had been installed in VS Code.
Fixed an issue with detecting .NET Reference Assemblies
The packaging feature requires the .NET Framework Developer Pack to be installed. The packager was incorrectly determining where the installation was. This resulted in package failures without any error message. The packager will now warn when it does not find the proper .NET Developer Pack installed.
Fixed an issue with licensing in VS Code
The licensing change in the previous release broke the license check in the packager.
You can now generate Windows Forms from PowerShell functions. In Visual Studio Code, if you execute the Generate Windows Form command from a ps1 file with a function defined in it, a form will be generated based on the parameters for the function. Check out the below video to see it in action.
The previous functionality is also exposed as a PowerShell cmdlet in the PowerShell Pro Tools module. You can pass in files, function definition, and cmdlet definitions to generate Windows Forms.
Fixed an issue with parameters passed to packaged scripts
A change made to the $PSScriptRoot support broke the ability to use a param() block in a packaged script. This has been resolved and you should be able to pass parameters to a packaged script again.
Fixed an issue with the installer cmdlets missing dependencies
The Wix binaries were not being installed with the PowerShell Pro Tools module. When attempting to run New-Installer, it would fail and complain about missing candle.exe or light.exe.
Improved the First Time User Experience with the VS Code Forms Designer
The VS Code forms designer will now insert code into the primary form file to help get started with running the form. This includes loading the System.Windows.Forms assembly, dot-sourcing the designer file and calling ShowDialog() on the form.
All the PowerShell Pro Tools and PowerShell Tools for Visual Studio versions are now the same. The reason for this change is the same underlying code is found in each of the tools and having separate version numbers makes it confusing to tell what is in each build. All tools are now on version 4.1.7 and will increase in version with each other. This also means a single set of release notes.
Fixed an Issue where $PSScriptRoot would be $null after packaging
Due to the way that the packager executes bundled scripts, it would result in $PSScriptRoot being $null. A change has been made to ensure that when running a bundled executable that the scripts will have $PSScriptRoot defined to the current directory of the assembly that is executing. This means you should be able to load other resources easier with packaged scripts.
Fixed an Issue where file properties would not be honored by Merge-Script
When packaging an executable you can define properties such as file version and product name. When using a Merge-Script configuration, these options were not being honored and the resulting executable would not have these properties set.
Correctly Enforce Visual Studio 2017 Version
A change was made that required Visual Studio 2017 version 15.8 or later to be installed when using PowerShell Tools for Visual Studio. This was done to support VS 2019. The extension’s manifest was not updated to support this change so it could be installed into VS 2017 versions before 15.8 which would result in an error when attempting to load the extension.