Share via

Here Comes the Update of Script Browser & Script Analyzer 1.1

  • Article

Update: Version 1.2 of the Script Browser is out. Check out the announcement here: https://blogs.technet.com/b/onescript/archive/2014/05/11/what-s-new-in-script-browser-amp-script-analyzer-1-2.aspx

The Script Browser for Windows PowerShell ISEhas received thousands of downloads since it was released a week ago. Based on your feedbacks, today we release the 1.1 update to respond to the highly needed features. The team is committed to making the Script Browser and Script Analyzer useful. Your feedback is very important to us.

Download Script Browser & Script Analyzer 1.1  
(If you have already installed the 1.0 version, you will get an update notification when you launch Windows PowerShell ISE.)

 

1. Options to Turn on / Turn off Script Analyzer Rules

You can either select to turn on or turn off the rules in the Settings window of Script Analyzer.

image

You can also suggest a new Script Analyzer rule or vote for others’ suggestions. Our team monitors the forum closely. Based on your suggestions and votes, we will provide the corresponding Script Analyzer rules in future updates. We are also looking into the capability for you to write your own Script Analyzer rules and plug into the Script Analyzer.

 

2. Refined Script Analyzer Rules with Detailed Description

Thanks to your feedback, we refined the Script Analyzer rules that were released in the version 1.0. We also fixed all rule issues that you reported. Each rule comes with a detailed description, good/bad examples, and supporting documents. Here are the 5 refined rules released in this update. We look forward to learning your feedback.

Invoke-Expression use should be carefully considered

Invoke-Expression is a powerful command; it’s useful under specific circumstances but can open the door for malicious code being injected. This command should be used judiciously.

https://blogs.msdn.com/b/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx

Cmdlet alias use should be avoided

Powershell is a wonderfully efficient scripting language, allowing an administrator to accomplish a lot of work with little input or effort. However, we recommend you to use full Cmdlet names instead of alias' when writing scripts that will potentially need to be maintained over time, either by the original author or another Powershell scripter. Using Alias' may cause problems related to the following aspects:

Readability, understandability and availability. Take the following Powershell command for an example:

Ls | ? {$_.psiscontainer} | % {"{0}`t{1}" -f $_.name, $_.lastaccesstime}

The above syntax is not very clear to the novice Powershell scripter, making it hard to read and understand.

The same command with the full Cmdlet names is easier to read and understand.

Get-ChildItem | Where-Object {$_.psiscontainer} | ForEach-Object {"{0}`t{1}" -f $_.name, $_.lastaccesstime

Lastly, we can guarantee that an alias will exist in all environments.

For more information, please see the linked Scripting Guy blog on this topic.

https://blogs.technet.com/b/heyscriptingguy/archive/2012/04/21/when-you-should-use-powershell-aliases.aspx

Empty catch blocks should be avoided

Empty catch blocks are considered poor design decisions because if an error occurs in the try block, the error will be simply swallowed and not acted upon. Although this does not inherently lead to undesirable results, the chances are still out there. Therefore, empty catch blocks should be avoided if possible.

Take the following code for an example:

try
{
        $SomeStuff = Get-SomeNonExistentStuff
}
catch
{
}

If we execute this code in Powershell, no visible error messages will be presented alerting us to the fact that the call to Get-SomeNonExistentStuff fails.

A possible solution:

try
{
         $SomeStuff = Get-SomeNonExistentStuff
}
catch
{
        "Something happened calling Get-SomeNonExistentStuff"
}

For further insights:

https://blogs.technet.com/b/heyscriptingguy/archive/2010/03/11/hey-scripting-guy-march-11-2010.aspx

Positional arguments should be avoided

Readability and clarity should be the goal of any script we expect to maintain over time. When calling a command that takes parameters, where possible consider using Named parameters as opposed to Positional parameters.

Take the following command, calling an Azure Powershell cmdlet with 3 Positional parameters, for an example:

Set-AzureAclConfig "10.0.0.0/8" 100 "MySiteConfig" -AddRule -ACL $AclObject -Action Permit

If the reader of this command is not familiar with the set-AzureAclConfig cmdlet, they may not know what the first 3 parameters are.

The same command called using Named parameters is easier to understand:

Set-AzureAclConfig -RemoteSubnet "10.0.0.0/8" -Order 100 -Description "MySiteConfig" -AddRule -ACL $AclObject -Action Permit

Additional reading:

https://blogs.technet.com/b/heyscriptingguy/archive/2012/04/22/the-problem-with-powershell-positional-parameters.aspx

Advanced Function names should follow standard verb-noun naming convention

As introduced in Powershell 2.0, the ability to create functions that mimic Cmdlet behaviors is now available to scripters. Now that we as scripters have the ability to write functions that behave like Cmdlets, we should follow the consistent nature of Powershell and name our advance functions using the verb-noun nomenclature.

Execute the Cmdlet below to get the full list of Powershell approved verbs.

Get-Verb

https://technet.microsoft.com/en-us/magazine/hh360993.aspx

 

3. Issue Fixes

  • Fixed a locale issue “Input string was not in a correct format..” when Script Browser launches on locales that treat double/float as ‘## , ####’. We are very grateful to MVP Niklas Akerlund for providing a workaround before we release the fix.
  • Fixed the issues (including the error 1001, and this bug report) when some users install the Script Browser.
  • Fixed the issues in Script Analyzer rules

 

We sincerely suggest you give Script Browser a try (click here to download). If you love what you see in Script Browser, please recommend it to your friends and colleagues. If you encounter any problems or have any suggestions for us, please contact us at onescript@microsoft.com. Your precious opinions and comments are more than welcome.

Comments