Use the same Get-Help command format that you would use to get help for any command in PowerShell. For more information, see Get-Help and Update-Help.
You might have to import a module or import a module file. You might also choose to import a module so that you can use the parameters of the Import-Module command, such as the Prefix parameter, which adds a distinctive prefix to the noun names of all imported commands, or the NoClobber parameter, which prevents the module from adding commands that would hide or replace existing commands in the session.
To import modules in a PSModulePath location into the current session, use the following command format. To import a module that is not in a default module location, use the fully qualified path to the module folder in the command.
To import a module file that is not contained in a module folder, use the fully qualified path to the module file in the command. For example, to add the TestCmdlets. For more information about adding modules to your session, see Import-Module. The Import-Module command imports modules into your current PowerShell session. To import a module into every PowerShell session that you start, add the Import-Module command to your PowerShell profile.
Removing a module reverses the operation of importing a module. Removing a module does not uninstall the module. For more information, see Remove-Module. User-specific modules: These are modules installed by the user in the user's scope. Install-Module has a Scope parameter that allows you to specify whether the module is installed for the current user or for all users.
For more information, see Install-Module. The specific path of that location varies by version of Windows and whether or not you are using folder redirection. Microsoft OneDrive can also change the location of your Documents folder. The PSModulePath environment variable is modeled on the Path environment variable and has the same format. The semi-colon ; in the command separates the new path from the path that precedes it in the list.
On Linux or MacOS, the colon : in the command separates the new path from the path that precedes it in the list. The value that you set affects only the current session. To make the change persistent, add the command to your PowerShell profile or use System in Control Panel to change the value of the PSModulePath environment variable in the registry. Also, to make the change persistent, you can also use the SetEnvironmentVariable method of the System.
Name conflicts occur when more than one command in the session has the same name. Importing a module causes a name conflict when commands in the module have the same names as commands or items in the session. A command is hidden when it is not the command that runs when you type the command name, but you can run it by using another method, such as by qualifying the command name with the name of the module or snap-in in which it originated.
A command is replaced when you cannot run it because it has been overwritten by a command with the same name. Even when you remove the module that caused the conflict, you cannot run a replaced command unless you restart the session. Import-Module might add commands that hide and replace commands in the current session. Also, commands in your session can hide commands that the module added. To detect name conflicts, use the All parameter of the Get-Command cmdlet. The All parameter gets all commands with the specific name in the session.
The Prefix parameter adds a prefix to the names of imported commands so that they are unique in the session. The NoClobber parameter does not import any commands that would hide or replace existing commands in the session.
You can also use the Alias , Cmdlet , Function , and Variable parameters of Import-Module to select only the commands that you want to import, and you can exclude commands that cause name conflicts in your session.
Module authors can prevent name conflicts by using the DefaultCommandPrefix property of the module manifest to add a default prefix to all command names. The value of the Prefix parameter takes precedence over the value of DefaultCommandPrefix. Even if a command is hidden, you can run it by qualifying the command name with the name of the module or snap-in in which it originated. The location depends on how the module is used. If you create your own module or get a module from another party, such as a Windows PowerShell community website, and you want the module to be available for your user account only, install the module in your user-specific Modules directory.
The user-specific Modules directory is added to the value of the PSModulePath environment variable by default. If you want a module to be available to all user accounts on the computer, install the module in the Program Files location. Their module installer creates a Modules subdirectory in the Fabrikam Manager product subdirectory. To enable the Windows PowerShell module discovery features to find the Fabrikam module, the Fabrikam module installer adds the module location to the value of the PSModulePath environment variable.
Note that each module resides in its own subdirectory in the Modules subdirectory. Then, the installer assures the value of the PSModulePath environment variable includes the path of the common files modules subdirectory.
To import a particular version of the module, the end-user can use the MinimumVersion or RequiredVersion parameters of the Import-Module cmdlet. For example, if the Fabrikam module is available in versions 8. The installer adds both of the module paths to the PSModulePath environment variable value. When these steps are complete, the ListAvailable parameter of the Get-Module cmdlet gets both of the Fabrikam modules. If both modules are imported into the same session, and the modules contain cmdlets with the same names, the cmdlets that are imported last are effective in the session.
Command name conflicts can occur when the commands that a module exports have the same name as commands in the user's session. When a session contains two commands that have the same name, Windows PowerShell runs the command type that takes precedence.
When a session contains two commands that have the same name and the same type, Windows PowerShell runs the command that was added to the session most recently. To run a command that is not run by default, users can qualify the command name with the module name.
To run the cmdlet, preface the command with the module name, such as:. To prevent name conflicts, module authors can use the DefaultCommandPrefix key in the module manifest to specify a noun prefix for all commands exported from the module. Users can use the Prefix parameter of the Import-Module cmdlet to use an alternate prefix. The value of the Prefix parameter takes precedence over the value of the DefaultCommandPrefix key. The [System. Path] class has static members that can be used to make your code work on any platform:.
Writing a Windows PowerShell Module. To find installed but not yet invoked modules, run the now known Get-Module -ListAvailable- command. To list only imported modules in the current session, simply run Get-Module. If you want to find specific commands in a module, you can achieve this by Get-Command -Module.
You can even find help for the commands in a module Get-Help. To function properly via the Get-Help -command after the import, the functions are required to have added. ExternalHelp -Help. Another way to seek help are external help files in some modules, identified by the file extension -Help. Importing Remote Modules or, as it is called, Implicit Remoting describes commands being executed on a remote machine, rather than locally. The vast majority of them connects to an Office server, followed by importing a module.
Or in other words, if one of the commands is run, they directly get forwarded to be run on the remote server and the output is being sent back to the current session. The next step is to import the module available on the remote device. To remove a module, the command Remove-Module does the job. Once removed, all commands that the module once added are deleted from the session, it works quite as the reversion of importing a module. Note that only the module will be removed from the local session, but without removing the module files.
Aside from the preinstalled modules of Windows PowerShell itself, there is an enormous amount of third-party modules out there. ScriptRunner, for example, provides with the so-called ActionPacks and ExtensionPacks a range of free and ready-to-use PowerShell script collections, which cover typical use cases in IT operations and are written according to Microsoft Best Practices.
For finding specific modules, we recommend the PowerShellGallery. It functions as a central repository for sharing and acquiring PoSh code, such as modules, scripts and more.
0コメント