killonetwork.blogg.se - Sapien powershell studio review

SAPIEN POWERSHELL STUDIO REVIEW CODE
SAPIEN POWERSHELL STUDIO REVIEW WINDOWS

SAPIEN POWERSHELL STUDIO REVIEW CODE

Let's make this faster! After reading Aaron Jensen's ( registry code in the awesome Carbon module, I replaced the original Get-ItemProperty calls with calls to the getValue() method of registry keys ( ), like the ones that Get-ChildItem returns in the registry.

Searching the registry isn't fast, but at ~5 seconds, it's much faster than the CIM/WMI query. (Get-ItemProperty -Path $entryName -Name InstallLocation).InstallLocation If ((Get-ItemProperty -Path $entryName -Name DisplayName).DisplayName -like $ProgramName) $entryName = $entry.Name -replace 'HKEY_LOCAL_MACHINE', 'HKLM:' $inst = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\*\Products\*\InstallProperties" Same with all registry values, including InstallLocation.

SAPIEN POWERSHELL STUDIO REVIEW WINDOWS

(Get-ItemProperty -Path $entryName -Name DisplayName).DisplayName), but the Windows PowerShell registry provider returns a custom object for the DisplayName registry value, so you need to get the DisplayName property of the DisplayName custom object. The Get-ItemProperty commands look repetitive (e.g. When you find a match for the program name, use Get-ItemProperty on the same registry key to get the data in the InstallLocation registry value. Because DisplayName is a registry value, not a key, use the Get-ItemProperty cmdlet to get it. Then, look for the InstallProperties key whose DisplayName property matches the program name (or a name pattern with wildcards). Use the Get-ChildItem cmdlet to get all of the InstallProperties registry keys. Let's use PowerShell get the installation directory in that InstallLocation registry value. Here's the InstallProperties key for my current version of PowerShell Studio in Regedit. The InstallProperties registry key for the program has an InstallLocation value that stores the installation path. You can also search the registry for the installation directory. There's really not much you can do to speed this up when the base operation is so slow. Here's the comparative graph of the three commands in sequence. In each case, I copied the performance data from the Output tab and placed it in comments before the command. Here are variations of the command with filtering to get the InstallationLocation property of the CIM object. In a 30-second operation, the filtering time is negligible and well within the margin of error. CIM must be caching and dumping in the middle of the operation. Here's the performance graph from the Performance tab. Here's the performance data from the Output tab: Getting the class without any filtering takes an average 30 seconds. PS C:\> (Get-CimInstance -ClassName Win32_Product | Where-Object Name -Like "*PowerShell*Studio*").InstallLocationĬ:\Program Files\SAPIEN Technologies, Inc\PowerShell Studio 2016\ Thanks to Liviuįor example, this command uses the Win32_Product class to get the installation directory of my current copy of PowerShell Studio 2016. The installers, potentially changing installer settings: Why-win32_product-is-bad-news. NOTE: Darren Mar-Elia ( warns not to use Win32_Product because accessing it updates You need to include the program name, but you can take it from a parameter and use wildcards to hedge your bet. The Win32_Product class returns an object that contains the path to the installation directory for a program. I used the new performance monitoring report graph in PowerShell Studio and PrimalScript to test them. How do you find the path to a Windows program dynamically at run time? There are a few different techniques, but they really perform differently. Reliable techniques for finding the installation directory

Place the path variable at the top of a script (in script scope), so it's very obvious to anyone who is maintaining the script.

Get the path at run time from a reliable location.

If you need to use a file path or URL in a script, here are a few guidelines: It doesn't change often and it is very unlikely to change without a version change that you can check in your script. So, instead of hard-coding a file system path, the best way to find an installation directory is to use the same technique that Windows uses. That doesn't seem like a particularly risky thing, but paths change and, in this case, we changed a path to conform to an updated Windows standard. This issue arose in a SAPIEN forum post (thanks for posting!) in which someone hard-coded the path to program that a PowerShell Studio installer file (.msi) installs.

New-Variable pi -Value ::Pi -Option Constant So, wherever you can, use variables and wildcards for variable values and use constants for the few things in life that don't change, e.g.

Using constants or "hard-coding" variable values is prone to error and requires continual maintenance. One of the important best-practice rules in scripting (and programming) is to avoid using constant values for things that can vary.