To reuse script samples on the Internet, the following steps seem quite familiar to IT Pros: wandering through different script galleries, forums and blogs, switching back and forth between webpages and scripting environment, and countless download, copy and paste operations. But all of these will drive one as dizzy as a goose. Need a simpler way of searching and reusing scripts? Try out the new Script Browser add-in for PowerShell ISE!

Download Here

Script Browser for Windows PowerShell ISE is an app developed by Microsoft Customer Services & Support (CSS) with assistance from the PowerShell team and the Garageto save IT Pros from the painful process of searching and reusing scripts. We start from the 9,000+ script samples on TechNet Script Center. Script Browser allows users to directly search, learn, and download TechNet scripts from within PowerShell ISE – your scripting environment. Starting from this month, Script Browser for PowerShell ISE will be available for download. If you are a PowerShell scripter or are about to be one, Script Browser is a highly-recommended add-in for you.

Nearly 10,000 scripts on TechNetare available at your fingertips. You can search, download and learn scripts from this ever-growing sample repository.

· We enabled offline searchfor downloaded script samples so that you can search and view script samples even when you have no Internet access.

You will get the chance to try out another new function bundled with Script Browser - ‘Script Analyzer’. Microsoft CSS engineer managed to use the PowerShell Abstract Syntax Tree (AST) to check your current script against some pre-defined rules. In this first version, he built 7 pilot PowerShell best practice checking rules. By double-clicking a result, the script code that does not comply with the best practice rule will be highlighted. We hope to get your feedback on this experimental feature.

It is very essential that an app satisfies users’ requirements. Therefore, feedback is of prime importance. For Script Browser, Microsoft MVPs are one of the key sources where we get constructive feedback. When the Script Browser was demoed at the 2013 MVP Global Summit in November and 2014 Japan MVP Open Day, the MVP community proposed insightful improvements. For instance, MVPs suggested showing a script preview before users can decide to download the complete script package. MVPs also wanted to be able to search for script samples offline. These were great suggestions, and the team immediately added the features to the release. We have collected a pool of great ideas (e.g. MVPs also suggested that the Best Practice rules checking feature in Script Analyzer should be extensible). We are committed to continuously improving the app based on your feedback.

We have an ambitious roadmap for Script Browser. For example, we plan to add more script repositories to the search scope. We are investigating integration with Bing Code Search. We are also trying to improve the extensibility of Script Analyzer rules. Some features, like script sample sharing and searching within an enterprise, are still in their infancy.

The Script Browser was released in mid-April and

has 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.

http://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.

http://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:

http://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:

http://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

http://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.

John Marlin
Senior Support Escalation Engineer
Microsoft Global Business Support