Windows PowerShell Handles Console Input and Display
When you type a command, Windows PowerShell always processes the command-line input directly. Windows PowerShell also formats the output that you see on the screen. This is significant because it reduces the work required of each cmdlet and ensures that you can always do things the same way regardless of which cmdlet you are using. One example of how this simplifies life for both tool developers and users is command-line help.
Traditional command-line tools have their own schemes for requesting and displaying help. Some command-line tools use /? to trigger the help display; others use -?, /H, or even //. Some will display help in a GUI window, rather than in the console display. Some complex tools, such as application updaters, unpack internal files before displaying their help. If you use the wrong parameter, the tool might ignore what you typed and begin performing a task automatically.
When you enter a command in Windows PowerShell, everything you enter is automatically parsed and pre-processed by Windows PowerShell. If you use the -? parameter with a Windows PowerShell cmdlet, it always means "show me help for this command". Cmdlet developers do not have to parse the command; they only need to provide the help text.
It is important to understand that the help features of Windows PowerShell are available even when you run traditional command-line tools in Windows PowerShell. Windows PowerShell processes the parameters and passes the results to the external tools.
Note:
If you run an graphic application in Windows PowerShell, the window for the application opens. Windows PowerShell intervenes only when processing the command-line input you supply or the application output returned to the console window; it does not affect how the application works internally.
Posted in: Internet Topic| Tags: PowerShell Windows Application Console Handle command cmdlet output help display window inputHow to: Remove a Cache Notification Callback (Velocity)
Use the RemoveCallback method to remove a cache notification callback. To identify the notification, this method requires the DataCacheNotificationDescriptor object that was returned when you added the callback. To facilitate this requirement, declare your DataCacheNotificationDescriptor object at a scope that is accessible to the code in your application and that adds the callback and the code in the application that removes the callback. The DataCacheNotificationDescriptor object returned to the method invoked by the cache notification can also be used to remove a callback.
Note
In order for your application to use notifications, you need to enable them on a named cache. Use the notificationsEnabled parameter with the New-Cache or Set-CacheConfig commands. For more information, see Cache Administration with PowerShell (Velocity).
How to remove a callback cache notification
Declare the DataCacheNotificationDescriptor object you use to add a callback at a scope that is accessible to the code that will remove the callback.
Use the RemoveCallback method to remove the cache notification callback. Use the appropriate DataCacheNotificationDescriptor object for the nd parameter.
Posted in: .Net Programming| Tags: .net 4.0 Application CTP CTP 3 Microsoft Velocity cache code use notification method callback remove datacachenotificationdescriptorHow 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.
Posted in: .Net Programming| Tags: .net 4.0 parameter Application Configuration CTP CTP 3 Microsoft Velocity cache code enable client local localcacheDeployment Options (Velocity)
Security Considerations
The "Velocity" distributed cache system is designed to be operated in the corporate datacenter within the perimeter of the corporate firewall. The servers described in this topic are the server hosting the cache configuration storage location, the cache servers, the cache-enabled application servers, the development servers, and the primary data source server. All servers should be co-located on the same corporate domain.
Because cached data and the TCP/IP communications between the cache servers is not encrypted, the distributed cache system is vulnerable to malicious "sniffing" and "replay" attacks.
Note
The "Velocity" cache client is meant to reside in the application tier of your application ecosystem. End users inside or outside your corporate domain should not have direct network access to the cache servers.
When decommissioning a cache server, the "Velocity" installation program may not remove all firewall port exceptions. After "Velocity" has been uninstalled, we recommend that you reapply the corporate standard firewall configuration.
Deployment Scenarios
To simplify the discussion of deployment options, this topic will focus on three distinct examples:
-
Developer deployment: A single-computer deployment used by to develop cache-enabled applications.
-
Mid-sized deployment: A multi-computer installation that does not use SQL Server, with lead hosts performing the cluster management role.
-
Enterprise deployment: A multi-computer installation that uses SQL Server for storing cluster configuration settings and performing the cluster management role.