Откуда Powershell знает, где найти модули для импорта?

Я действительно на начальном уровне для работы с командлетами и PowerShell. Я вызываю командлеты из С# с помощью API PowerShell. Я видел странное поведение. В то время как в разных потоках на stackoverfow люди явно импортируют модули с помощью метода Import-Command или PSImportModule, я вижу, есть ли уже доступная сборка в $env:PSModulePath, она загружается автоматически. Это поведение по умолчанию или из-за конфигураций критериев, которые я пропускаю. Я запускаю модульный тест в тестовой среде ms.

Я использую следующий код.

 System.Management.Automation.PowerShell _powerShellInstance
 _powerShellInstance.AddCommand("Connect-AzureRmAccount", false);
 var output = _powerShellInstance.Invoke();

 // Invoking my commandlets

 _powerShellInstance.AddCommand("Get-LinkParameter", false);

Приведенная выше команда автоматически загружает сборку из C:\Windows\system32\WindowsPowerShellModules\v1.0\Modules\. Я не создавал ни пространства выполнения, ни наборов конфигурации. Чуть выше автоматическая загрузка вещей. Мне нужно подтвердить, как именно ведет себя powershell и run space. Потому что мне нужно прояснить, как мне нужно установить мои команды на производственную машину. Как модульные тесты на производственной машине будут получать доступ к моим командам для идеальной загрузки.


c# powershell cmdlets runspace
person Usman    schedule 06.07.2018    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Хотя рекомендуется явно загружать нужные модули с помощью Import-Module, начиная с Powershell 3.0, если модуль доступен в одном из мест, возвращаемых $env:PSModulePath, он автоматически загружается по умолчанию, если вызывается один из его командлетов. Ниже приведена разбивка различных путей:

Пользовательские модули

$modulePath = "${env:UserProfile}\Documents\WindowsPowerShell\Modules" Установленные здесь модули доступны только для сеанса Powershell текущего пользователя, и по умолчанию модули, установленные с помощью Install-Module, сохраняются здесь.

Все пользовательские модули

$modulePath = "${env:ProgramFiles}\WindowsPowerShell\Modules" Установленные здесь модули доступны для сеанса Powershell любого пользователя.

Системные модули

$modulePath = "${env:SystemRoot}\system32\WindowsPowerShell\v1.0\Modules" Установленные здесь модули доступны для всей системы для любого сеанса Powershell, но их следует содержать в чистоте, чтобы Windows могла ими управлять. Как правило, вы не хотите устанавливать здесь свои собственные модули.

Добавление дополнительных путей к модулям

Вы можете добавить дополнительные пути к $env:PSModulePath аналогично тому, как вы изменили бы переменную $env:PATH для разрешения путей к исполняемым файлам. Это просто разделенная точками с запятой строка каталогов, в которых находятся модули, и если модуль доступен по любому пути в $env:PSModulePath, Powershell будет знать, где его найти. И на самом деле вы можете видеть, что другие установленные инструменты могли добавить свои собственные пути к $env:PSModulePath. Вот несколько примеров программ/наборов инструментов, которые делают это: Microsoft SQL Studio, Microsoft System Center - Operations Manager и Chef Development Kit.

Импорт модуля не по пути

Насколько я знаю, вы не можете загрузить модуль Powershell, который не является частью $env:PSModulePath. Однако вы можете временно отредактировать $env:PSModulePath, чтобы он содержал каталог с модулем, который вы хотите загрузить. Например, если вы хотите импортировать модуль с именем TestModule по произвольному пути:

$env:PSModulePath += ';C:\Path\To\Temporary\ModuleDirectory'
Import-Module TestModule

где TestModule существует как подпапка C:\Path\To\Temporary\ModuleDirectory

Вам не нужно отменять изменение пути к модулю, когда вы будете готовы завершить сеанс Powershell, поскольку указанное выше изменение является временным. Следовательно, вам нужно будет изменять $env:PSModulePath в каждом сеансе, поэтому, если TestModule было чем-то, что вы хотели бы иметь всегда доступным для использования, вы можете либо скопировать его в один из других каталогов в $env:PSModulePath, либо навсегда добавить C:\Path\To\Temporary\ModuleDirectory в переменную окружения PSModulePath. .

Примечание о путях UNC

Вы также можете добавить пути UNC (сетевые) к $env:PSModulePath. Тем не менее, я считаю, что любые сценарии удаленных модулей по-прежнему будут подчиняться Powershell ExecutionPolicy, установленному в системе.

И еще немного об установке модулей

По умолчанию Install-Module устанавливает модуль в каталог User Modules, но вы можете немного контролировать это с помощью параметра -Scope. Например, следующие команды изменят место установки модуля:

# Install to the current user location (default behavior if scope unspecified)
Install-Module -Scope CurrentUser $moduleName

# Install to the all users location (requires elevated permissions)
Install-Module -Scope AllUsers $moduleName

К сожалению, это единственные два места, куда PowerShell поможет вам установить ваши модули. Системные модули имеют решающее значение для работы PowerShell и не должны изменяться конечными пользователями, а дополнительные пути, добавленные в $env:PSModulePath, вероятно, управляются программным обеспечением вне PowerShell, обычно MSI или другими установщиками.

Кроме того, если вы пишете программное обеспечение, которое поставляется с одним или несколькими модулями PowerShell, рекомендуется, чтобы ваш установщик добавил новый каталог в системный каталог %PSModulePath% и поместил туда модуль, а не устанавливал по стандартному пути AllUsers или CurrentUser, так как они действительно предназначен для конечного пользователя, чтобы управлять по своей прихоти. В этом случае пусть ваш процесс обновления программного обеспечения обновит модуль. Преимущество этого заключается в предотвращении случайного изменения или удаления модуля до несовместимой версии.

person Bender the Greatest    schedule 06.07.2018