Windows PowerShell Provider Overview
A Windows PowerShell provider allows any data store to be exposed like a file system as if it were a
mounted drive. For example, the built-in Registry provider allows you to navigate the registry like
you would navigate the c drive of your computer. A provider can also override the Item cmdlets
(for example, Get-Item, Set-Item, etc.) such that the data in your data store can be treated
like files and directories are treated when navigating a file system. For more information about
providers and drives, and the built-in providers in Windows PowerShell, see
about_Providers.
Providers and Drives
A Provider defines the logic that is used to access, navigate, and edit a data store, while a drive specifies a specific entry point to a data store (or a portion of a data store) that is of the type defined by the provider. For example, the Registry provider allows you to access hives and keys in a registry, and the HKLM and HKCU drives specify the corresponding hives within the registry. The HKLM and HKCU drives both use the Registry provider.
When you write a provider, you can specify default drives-drives that are created automatically when the provider is available. You also define a method to create new drives that use that provider.
Type of Providers
There are several types of providers, each of which provides a different level of functionality. A provider is implemented as a class that derives from one of the descendants of the System.Management.Automation.SessionStateCategory CmdletProvider class. For information about the different types of providers, see Provider types.
Provider cmdlets
Providers can implement methods that correspond to cmdlets, creating custom behaviors for those cmdlets when used in a drive for that provider. Depending on the type of provider, different sets of cmdlets are available. For a complete list of the cmdlets available for customization in providers, see Provider cmdlets.
Provider paths
Users navigate provider drives like file systems. Because of this, they expect the syntax of paths to correspond to the paths used in file system navigation. When a user runs a provider cmdlet, they specify a path to the item to be accessed. The path that is specified can be interpreted in several ways. A provider should support one or more of the following path types.
Drive-qualified paths
A drive-qualified path is a combination of the item name, the container and subcontainers in which
the item is located, and the Windows PowerShell drive through which the item is accessed. (Drives
are defined by the provider that is used to access the data store. This path starts with the drive
name followed by a colon (:). For example: get-childitem C:
Provider-qualified paths
To allow the Windows PowerShell engine to initialize and uninitialize your provider, the provider
must support a provider-qualified path. For example, the user can initialize and uninitialize the
FileSystem provider because it defines the following provider-qualified path:
FileSystem::\\uncshare\abc\bar.
Provider-direct paths
To allow remote access to your Windows PowerShell provider, it should support a provider-direct path
to pass directly to the Windows PowerShell provider for the current location. For example, the
registry Windows PowerShell provider can use \\server\regkeypath as a provider-direct path.
Provider-internal paths
To allow the provider cmdlet to access data using non-Windows PowerShell application programming
interfaces (APIs), your Windows PowerShell provider should support a provider-internal path. This
path is indicated after the "::" in the provider-qualified path. For example, the provider-internal
path for the filesystem Windows PowerShell provider is \\uncshare\abc\bar.
Overriding cmdlet parameters
The behavior of some provider-specific cmdlets can be overridden by a provider. For a list of parameters that can be overridden, and how to override them in your provider class, see Provider cmdlet parameters
Dynamic parameters
Providers can define dynamic parameters that are added to a provider cmdlet when the user specifies a certain value for one of the static parameters of the cmdlet. A provider does this by implementing one or more dynamic parameter methods. For a list of cmdlet parameters that can be used to add dynamic parameter, and the methods used to implement them, see Provider cmdlet dynamic parameters.
Provider capabilities
The
System.Management.Automation.Provider.Providercapabilities
enumeration defines a number of capabilities that providers can support. These include the ability
to use wildcards, filter items, and support transactions. To specify capabilities for a provider,
add a list of values of the
System.Management.Automation.Provider.Providercapabilities
enumeration, combined with a logical OR operation, as the
System.Management.Automation.Provider.Cmdletproviderattribute.Providercapabilities*
property (the second parameter of the attribute) of the
System.Management.Automation.Provider.Cmdletproviderattribute
attribute for your provider class. For example, the following attribute specifies that the provider
supports the
System.Management.Automation.Provider.Providercapabilities
ShouldProcess and
System.Management.Automation.Provider.ProviderCapabilities
Transactions capabilities.
[CmdletProvider(RegistryProvider.ProviderName, ProviderCapabilities.ShouldProcess | ProviderCapabilities.Transactions)]
Provider cmdlet help
When writing a provider, you can implement your own Help for the provider cmdlets that you support. This includes a single help topic for each provider cmdlet or multiple versions of a help topic for cases where the provider cmdlet acts differently based on the use of dynamic parameters. To support provider cmdlet-specific help, your provider must implement the System.Management.Automation.Provider.Icmdletprovidersupportshelp interface.
The Windows PowerShell engine calls the
System.Management.Automation.Provider.Icmdletprovidersupportshelp.Gethelpmaml*
method to display the Help topic for your provider cmdlets. The engine provides the name of the
cmdlet that the user specified when running the Get-Help cmdlet and the current path of the user.
The current path is required if your provider implements different versions of the same provider
cmdlet for different drives. The method must return a string that contains the XML for the cmdlet
Help.
The content for the Help file is written using PSMAML XML. This is the same XML schema that is used
for writing Help content for stand-alone cmdlets. Add the content for your custom cmdlet Help to the
Help file for your provider under the CmdletHelpPaths element. The following example shows the
command element for a single provider cmdlet, and it shows how you specify the name of the
provider cmdlet that your provider. supports
<CmdletHelpPaths>
<command:command>
<command:details>
<command:name>ProviderCmdletName</command:name>
<command:verb>Verb</command:verb>
<command:noun>Noun</command:noun>
<command:details>
</command:command>
<CmdletHelpPath>
