Learning Windows PowerShell Names

Learning names of commands and command parameters is a significant time investment with most command-line interfaces. The issue is that there are very few patterns, so the only way to learn is by memorizing each command and each parameter that you need to use on a regular basis.

When you work with a new command or parameter, you cannot generally use what you already know; you have to find and learn a new name. If you look at how interfaces grow from a small set of tools with incremental additions to functionality, it is easy to see why the structure is nonstandard. With command names in particular, this may sound logical since each command is a separate tool, but there is a better way to handle command names.

Most commands are built to manage elements of the operating system or applications, such as services or processes. The commands have a variety of names that may or may not fit into a family. For example, on Windows systems, you can use the net start and net stop commands to start and stop a service. There is another more generalized service control tool for Windows that has a completely different name, sc, that does not fit into the naming pattern for the net service commands. For process management, Windows has the tasklist command to list processes and the taskkill command to kill processes.

Commands that take parameters have irregular parameter specifications. You cannot use the net start command to start a service on a remote computer. The sc command will start a service on a remote computer, but to specify the remote computer, you must prefix its name with a double backslash. For example, to start the spooler service on a remote computer named DC01, you would type sc \\DC01 start spooler. To list tasks running on DC01, you need to use the /S (for "system") parameter and supply the name DC01 without backslashes, like this: tasklist /S DC01.

Although there are important technical distinctions between a service and a process, they are both examples of manageable elements on a computer that have a well-defined life cycle. You may want to start or stop a service or process, or get a list of all currently running services or processes. In other words, although a service and a process are different things, the actions we perform on a service or a process are often conceptually the same. Furthermore, choices we may make to customize an action by specifying parameters may be conceptually similar as well.

Windows PowerShell exploits these similarities to reduce the number of distinct names you need to know to understand and use cmdlets.

How to: Enable Local Cache (Code) (Velocity)

To programmatically enable local cache when creating your cache client, you must make sure the localCache parameter in the DataCacheFactory class constructor is equal to true. For more information about the application configuration settings, see Application Configuration Settings (Velocity).

Note 
These procedures assume that you have already prepared your development environment and set references to the "Velocity" assemblies, and so on. For more information, see How to: Prepare the Development Environment (Velocity)

To create a cache client that has local cache enabled
Create an array of DataCacheServerEndPoint objects to specify the cache hosts for the client.

Configure your cache hosts by assigning the cache host array from the previous step to the servers parameter of the DataCacheFactory constructor. Note: For performance reasons, we recommend that you minimize the number of DataCacheFactory objects created in a cache-enabled application. Store the DataCacheFactory object in a variable available to all parts of the application that use cache clients.

Configure your cache client type by assigning a true or false value to the routingClient parameter of the DataCacheFactory constructor. Use the true value for a routing client, or a false value for a simple client.

Enable local cache by assigning a true value to the localCache parameter of the DataCacheFactory constructor.

(optional) Configure your cache client for cache notifications by using the DataCacheFactory constructor with the following additional parameters.

syncPolicy: Use the DataCacheLocalCacheSyncPolicy enumeration to choose how locally cached objects are invalidated. Use TimeoutBased to indicate that a time-out value should be used or NotificationBased to indicate that cache notifications will be used. For more information, see Cache Clients and Local Cache (Velocity).

localCacheTimeout: Use this parameter to specify the number of seconds that an object will remain in local cache before it is invalidated. This parameter is ignored if syncPolicy is set to NotificationBased.

pollInterval: Use this parameter to specify the interval of frequency, in seconds, that the cache client will check with the cache cluster for cache notifications. The default value is 300 seconds. Note: Local cache is not required for cache notifications. For more information, see Cache Notifications (Velocity).

Use the GetCache method to obtain an instance of the routing client.