Как загрузить классы в модуль PowerShell глобально?

Я не до конца понимаю проблему, связанную с виртуальной машиной, но, возможно, следующий подход обходит проблему:

• Определите свой класс es как часть корневого модуля вашего скрипта (*.psm1, на который ссылается запись RootModule манифеста модуля) вместо текущего подхода с использованием файла *.ps1, который загружается в область вызывающего объекта через запись ScriptsToProcess манифеста.

  • Другими словами: тогда вам не понадобится запись ScriptsToProcess (по крайней мере, для экспорта ваших class и enum).

• Само по себе это делает ваши классы доступными только для вызывающих абонентов, которые импортируют модуль с помощью оператора с использованием модуля, но обратите внимание на следующее:

  • Примечания к связанной документации (выделено нами):

    [using module] не всегда импортирует классы или перечисления, определенные во вложенных модулях или в скриптах, которые находятся в корневом модуле через точечный источник. Определите классы и перечисления, которые вы хотите сделать доступными для пользователей за пределами модуля, непосредственно в корневом модуле.

  • Только импортер и его дочерние области видят class (и перечисления) импортированного модуля.

  • Поскольку using module является оператором времени анализа, путь к целевому модулю не должен содержать переменных, но на модули, обнаруживаемые с помощью $env:PSModulePath, можно ссылаться только по имени (например, using module MyModule); относительные пути разрешаются по местоположению собственной файловой системы вызывающего объекта (а не по текущему каталогу).

  • Если модуль импортирован с помощью using module в данном сеансе, его нельзя принудительно повторно импортировать; то есть, если вы хотите изменить свои определения class и/или enum, вам нужно будет начать новый сеанс, чтобы увидеть изменения.

• Однако в разделе Экспорт классов с ускорителями типов раздела справки about_Classes описан обходной путь, который делает классы по вашему выбору доступными для сеанса глобально, во всех областях видимости и пространствах выполнения, а также работает с автозагрузкой модуля . и Импорт-Модуль

• Пример кода ниже демонстрирует этот подход, но со следующими оговорками:

  • Как и в случае с подходом на основе using module, вы не сможете перезагрузить измененные определения class в данном сеансе — вместо этого начните новый сеанс.

  • В отличие от подхода на основе using module (который вы все равно можете комбинировать с предлагаемым подходом), импортер (возможно, неявный) не должен полагаться на то, что class будут доступны во время синтаксического анализа, т. е. не должен пытаться ссылаться на них через тип. литералы в class собственном определении - подробности см. в этом ответе.

    • Хотя подход с ускорителем типов технически позволяет вам размещать определения class и enum во вложенном модуле или файле *.ps1, полученном из корневого модуля, этого лучше избегать, если вы хотите, чтобы ваш модуль также поддерживал технику импорта using module для синтаксического анализа. -время наличия занятий.

  • Поскольку предлагаемый подход (потенциально) открывает доступ к classes и другим пространствам выполнения, их следует украсить атрибутом [NoRunspaceAffinity(), который доступен только в версии 7.4+. Тем не менее, этот подход безопасно использовать в более ранних версиях, если используется только одно пространство выполнения (пространство выполнения по умолчанию).

  • Связанный раздел справки также включает основанный на событиях код для попытки удалить экспортированные class определения при выгрузке модуля (Remove-Module), однако это не работает (начиная с PowerShell 7.4.1) и поэтому опущено в приведенном ниже коде. .

Обратите внимание, что при любом из описанных выше подходов class и enum не будут доступны до тех пор, пока ваш модуль не будет импортирован в данный сеанс. То есть, в отличие от функций и командлетов в модулях автоматической загрузки, их невозможно обнаружить до импорта.

Пример *.psm1 содержимого корневого модуля:

# Since the quasi-exported class will be available *process-wide*
# and therefore also in *other runspaces*, be sure to define it with
# the [NoRunspaceAffinity()] attribute.
# Caveat: **v7.4+ only**
[NoRunspaceAffinity()]
class SomeClass { # Note: 'SomeClass' is both its .Name and .FullName.
  [int] Get() { return 42 }
}

# Define the types to export with type accelerators.
# Note: Unlike the `using module` approach, this approach allows
#       you to *selectively* export `class`es and `enum`s.
$exportableTypes = @(
  [SomeClass]
)

# Get the non-public TypeAccelerators class for defining new accelerators.
$typeAcceleratorsClass = [psobject].Assembly.GetType('System.Management.Automation.TypeAccelerators')

# Add type accelerators for every exportable type.
$existingTypeAccelerators = $typeAcceleratorsClass::Get
foreach ($type in $exportableTypes) {
  # !! $TypeAcceleratorsClass::Add() quietly ignores attempts to redefine existing
  # !! accelerators with different target types, so we check explicitly.
  $existing = $existingTypeAccelerators[$type.FullName]
  if ($null -ne $existing -and $existing -ne $type) {
    throw "Unable to register type accelerator [$($type.FullName)], because it is already defined with a different type ([$existing])."
  }
  $typeAcceleratorsClass::Add($type.FullName, $type)
}

Любой (возможно, неявный) импортер модуля, связанного с этим *.psm1, будет иметь класс [SomeClass], доступный ему во время выполнения.

То есть [SomeClass]::new().Get() в области вызывающего абонента и любая последующая область должна давать 42